Changes between Version 6 and Version 7 of LoritoRoadmap

Timestamp:

05/27/10 01:34:23 (12 years ago)

Author:

cotto

Comment:

incoprorate feedback from allison++, other small changes

LoritoRoadmap

@@ -11 +11 @@
 === Lorito Design ===
  * Define Lorito ops and semantics (ffi, arg format, binary format, registers, ops, syscalls, text format, etc).
+   * Discuss the eventual PBC format and how to allow Lorito-based dynops and PIR ops while avoiding excessive bytecode bloat.
  * Implement some PMCs, ops and library bindings in Lorito to demonstrate that Lorito is sufficiently powerful.  Because Lorito is not intended to be written directly, this stage may involve some annoyance on the part of the implementors.
  * Identify and deal with blockers to implementing core PMCs and systems in Lorito.
@@ -26 +27 @@
 
 === opsc (full HLLs) ===
- * Make opsc able to process HLLs and spit out Lorito ops.  Implement some ops in terms of a HLL. [ANR: by "HLLs" you don't mean Perl/Python, but the mini-language that compiles down to Lorito ops?]
+ * Make opsc able to process HLLs and spit out Lorito ops.  Implement some ops in terms of an HLL, such as NQP, that compiles down to Lorito.
 
 === Lorito PMCs ===
@@ -34 +35 @@
 
 === Pervasive Lorito === 
- * Modify the current PIR compiler to emit Lorito.
+ * Modify the current PIR compiler (ideally [http://github.com/bacek/pir PIRATE], possibly imcc or pirc) to emit Lorito.
  * Implement core PIR ops in Lorito.  
- * Change the PBC to be Lorito-based instead of PIR-based. [ANR: this will hugely bloat our bytecode, a higher-level of abstraction has advantages here]
- * Make the final switch. All ops and PMCs get compiled into L1 during the normal build process (possibly using a bootstrapping step).
+ * Switch to a Lorito-centric PBC.
+ * Make the final switch. All ops and PMCs get compiled down to Lorito during the normal build process (possibly using a bootstrapping step).
 
 == Stage 3: Convert and Optimize ==