Changes between Initial Version and Version 1 of Lorito

Show
Ignore:
Timestamp:
11/17/09 01:49:08 (12 years ago)
Author:
plobsing
Comment:

initial thoughts

Legend:

Unmodified
Added
Removed
Modified
  • Lorito

    v1 v1  
     1== Possible Lorito Designs == 
     2 
     3=== Opcodes === 
     4 
     5Lorito 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 
     21The 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 
     33The 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)