Changes between Version 1 and Version 2 of Lorito

Show
Ignore:
Timestamp:
11/17/09 06:25:22 (4 years ago)
Author:
cotto
Comment:

add some counterpoints and clarifications to the opcode proposition

Legend:

Unmodified
Added
Removed
Modified
  • Lorito

    v1 v2  
    33=== Opcodes === 
    44 
    5 Lorito is a sequence of opcodes which can be trivially converted to jit instructions. 
     5Lorito is implemented as a fixed set of low-level opcodes in 3-argument form which can be trivially converted to jit instructions.  All other ops (PIR, dynops, etc) are implemented in terms of these Lorito ops.  Once Lorito is implemented, much of Parrot's core code can be rewritten in something that gets compiled down to Lorito. 
    66 
    77==== Pro ==== 
    88 * easy to convert to JIT instructions 
    99 * easy to provide runtime code generation 
     10 * whole-program optimization is possible for all subsystems written in Lorito - cotto 
     11 * such ops would be easier to translate into C for non-jit-capable systems or builds - cotto 
     12 * security privileges can be implemented on a per-opcode basis, in case we ever get around to that - cotto 
     13 * bytecode validation is simpler - cotto 
    1014 
    1115==== Con ==== 
     
    1317   * likely inspired by features/mindsets provided by supported JITs 
    1418   * 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 
     19      * Counterpoint: This is an issue of API design.  If we understand the non-essential capabilities we want to support (e.g. optimization passes, etc), we can design the API so that such capabilities can be exploited but not required. - cotto 
     20   * if LLVM is the only supported JIT (initial plan), ops will tend to mirror LLVM ops, and likely be difficult to work with to support other JIT systems 
     21      * Counterpoint: This is an implementation detail.  Once we start designing and implementing Lorito, some of us can familiarize ourselves with other JIT systems to ensure that Lorito can also support them. - cotto 
    1622 * 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. 
    1723 * requiring people to write ops at all will create a pressure to add abstractions 
     24  * Counterpoint:  We don't want most people to write Lorito code directly.  We *want* those abstractions so that most of Parrot can be written in PIR, NQP or even a low-runtime HLL, since it'll all compile down to Lorito ops. - cotto 
    1825 
    1926=== CLang === 
     
    3138=== Structured === 
    3239 
    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. 
     40The 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 specifically for the purpose. Supported execution strategies (C, various JIT systems, etc) are implemented as backends to the compiler. 
    3441 
    3542==== Probable language features ====