| 1 | == Possible Lorito Designs == |
| 2 | |
| 3 | === Opcodes === |
| 4 | |
| 5 | Lorito is a sequence of opcodes which can be trivially converted to jit instructions. |
| 6 | |
| 7 | ==== Pro ==== |
| 8 | * easy to convert to JIT instructions |
| 9 | * easy to provide runtime code generation |
| 10 | |
| 11 | ==== Con ==== |
| 12 | * how are ops defined? |
| 13 | * likely inspired by features/mindsets provided by supported JITs |
| 14 | * if the set of supported JITs is large, ops will cater to the lowest common denominator |
| 15 | * if LLVM is the only supported JIT (initial plan), ops will mirror LLVM ops, and likely be difficult to work with to support other JIT systems |
| 16 | * writing the entire VM in low-level ops is not desirable from both readability and writability perspectives. Most of the VM will be opaque to the JIT, which is bad for inlining. |
| 17 | * requiring people to write ops at all will create a pressure to add abstractions |
| 18 | |
| 19 | === CLang === |
| 20 | |
| 21 | The VM is exposed to the JIT system by compiling it to a JIT-visible form using a C-to-JIT compiler such as CLang. Code generation is defined separately. |
| 22 | |
| 23 | ==== Pro ==== |
| 24 | * exposes the VM to the JIT subsystem |
| 25 | * easy for Parrot. no special actions need be taken on source (the build system would need to be tweaked to support this) |
| 26 | |
| 27 | ==== Con ==== |
| 28 | * requires supported JIT systems to provide a C-to-JIT compiler. AFAIK, only LLVM has this |
| 29 | * does not address run-time code generation, the main purpose of JIT |
| 30 | |
| 31 | === Structured === |
| 32 | |
| 33 | The code defining important portions (potentially all, but at least in common hot-paths), including all code that does runtime code generation is defined in a new, structured language, defined specifcally for the purpose. Supported execution strategies (C, various JIT systems, etc) are implemented as backends to the compiler. |
| 34 | |
| 35 | ==== Probable language features ==== |
| 36 | * inline C sections to ease transition, also for when you really need C |
| 37 | * likely similar in capabilities to C, as it also needs to be translated to C |
| 38 | * similar type system |
| 39 | * similar memory access capabilities (eg: arrays, pointer arithmetic, etc) |
| 40 | * runtime generated sections |
| 41 | * templates to be populated at runtime (but compiled to JIT-internal form at compile time) |
| 42 | * types probably need to be values for this to work (eg: type_t x = short; ) |
| 43 | |
| 44 | ==== Pro ==== |
| 45 | * easier to work with than ops => more of the VM exposed to the JIT => better inlining |
| 46 | * possible to define runtime code generation behaviour (in a nice, declarative way, possibly) |
| 47 | * don't need to implement a C compiler to support another JIT system |
| 48 | * allows for working in a nicer language than C (for whatever values of nice we choose) |
| 49 | |
| 50 | ==== Con ==== |
| 51 | * requires defining, agreeing upon, a language |
| 52 | * requires implementing said language and integrating into the build system (possible bootstrapping) |