Changes between Version 1 and Version 2 of Lorito

Timestamp:

11/17/09 06:25:22 (12 years ago)

Author:

cotto

Comment:

add some counterpoints and clarifications to the opcode proposition

Lorito

@@ -3 +3 @@
 === Opcodes ===
 
-Lorito is a sequence of opcodes which can be trivially converted to jit instructions.
+Lorito 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.
 
 ==== Pro ====
  * easy to convert to JIT instructions
  * easy to provide runtime code generation
+ * whole-program optimization is possible for all subsystems written in Lorito - cotto
+ * such ops would be easier to translate into C for non-jit-capable systems or builds - cotto
+ * security privileges can be implemented on a per-opcode basis, in case we ever get around to that - cotto
+ * bytecode validation is simpler - cotto
 
 ==== Con ====
@@ -13 +17 @@
    * 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
+      * 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
+   * 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
+      * 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
  * 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
+  * 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
 
 === CLang ===
@@ -31 +38 @@
 === Structured ===
 
-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.
+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 specifically for the purpose. Supported execution strategies (C, various JIT systems, etc) are implemented as backends to the compiler.
 
 ==== Probable language features ====