|Version 1 (modified by plobsing, 4 years ago)|
Possible Lorito Designs
Lorito is a sequence of opcodes which can be trivially converted to jit instructions.
- easy to convert to JIT instructions
- easy to provide runtime code generation
- how are ops defined?
- likely inspired by features/mindsets provided by supported JITs
- if the set of supported JITs is large, ops will cater to the lowest common denominator
- 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
- 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.
- requiring people to write ops at all will create a pressure to add abstractions
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.
- exposes the VM to the JIT subsystem
- easy for Parrot. no special actions need be taken on source (the build system would need to be tweaked to support this)
- requires supported JIT systems to provide a C-to-JIT compiler. AFAIK, only LLVM has this
- does not address run-time code generation, the main purpose of JIT
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.
Probable language features
- inline C sections to ease transition, also for when you really need C
- likely similar in capabilities to C, as it also needs to be translated to C
- similar type system
- similar memory access capabilities (eg: arrays, pointer arithmetic, etc)
- runtime generated sections
- templates to be populated at runtime (but compiled to JIT-internal form at compile time)
- types probably need to be values for this to work (eg: type_t x = short; )
- easier to work with than ops => more of the VM exposed to the JIT => better inlining
- possible to define runtime code generation behaviour (in a nice, declarative way, possibly)
- don't need to implement a C compiler to support another JIT system
- allows for working in a nicer language than C (for whatever values of nice we choose)
- requires defining, agreeing upon, a language
- requires implementing said language and integrating into the build system (possible bootstrapping)