Cmpilr
| Paradigm(s) | not specified |
|---|---|
| Designed by | User:Grom |
| Appeared in | 2022 |
| Computational class | Optionally Turing complete |
| Major implementations | Unimplemented |
| File extension(s) | .txt |
Cmpilr is an acronym standing for (C)mpilr (M)anages to cm(P)ile (I)tself (L)argely (R)ecursively. It describes a class of virtual machines in which some number of opcodes compiles or assembles some input into an output of more opcodes.
ie: With an instruction set of: {Z, C}
C (the compiler opcode), provided with some input x, would output a list of instructions representing a partially or fully compiled form of x.
In the fully compiled form, the output contains only Z instructions, while in the partially compiled form, the output contains an arbitrary mix of Z and C instructions.
Full compilation
C = [ZZZZZZZZZZ]
Partial compilation
C = [ZCZZCZCCZZ]
Reflections
Future iterations of the idea
Ideally, the virtual machine would be a turing complete OISC, with the execution of the compilation instruction (as the sole instruction), would perform operations as side effects of the compilation.
- I will probably implement some form of this vm (probably not OISC) on an fpga in the future
Questionable boundaries for compilation and for recursive machines
There isn't a clear boundary between this and some arbitrary TC virtual machine, because there is not a specified limit to the number of opcodes that can take part in the recursive compilation.
- If you use a cardinality 4 instruction set for example, and 3 of those are considered compilation instructions (equivalent to C above), and 1 to be an operational instruction (equivalent to Z above), then where is the line between that and an x86 gcc compiler.
- Additionally, where is the line between what is considered compilation at all. The compilation instruction doesn't necessarily take in a string in some predefined language (even if it does, there exist arbitrary trivially compiled syntaxes).
- When does compilation stop being useful?