Changes between Version 7 and Version 8 of LoritoRoadmap

Show
Ignore:
Timestamp:
05/28/10 08:10:35 (12 years ago)
Author:
cotto
Comment:

incorporate suggestions from plobsing++

Legend:

Unmodified
Added
Removed
Modified
  • LoritoRoadmap

    v7 v8  
    1212 * Define Lorito ops and semantics (ffi, arg format, binary format, registers, ops, syscalls, text format, etc). 
    1313   * Discuss the eventual PBC format and how to allow Lorito-based dynops and PIR ops while avoiding excessive bytecode bloat. 
    14  * 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. 
     14   * If it's agreed that PBC should not store Lorito ops directly, a separate Lorito format should be discussed. 
     15   * Decide whether Lorito bytecode is something we expect to distribute or if it will exist only as a local caching optimization. 
     16 * Implement some PMCs, ops and library bindings in Lorito to demonstrate that Lorito is sufficiently powerful.   
     17   * Because Lorito is not intended to be written directly, this stage may involve some annoyance on the part of the implementors. 
     18   * An HLL may be suitable if it can be shown without excessive hand-waving how its code could be compiled to Lorito. 
    1519 * Identify and deal with blockers to implementing core PMCs and systems in Lorito. 
    1620 * Get a rough idea of how PIR -> Lorito translation will work.  The same goes for Lorito -> C code and Lorito -> C functions. 
     
    2630 * Define Lorito -> C function translation (similar to the current function-based runcore). 
    2731 
    28 === opsc (full HLLs) === 
     32=== Lorito Field Testing === 
    2933 * 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. 
    30  
    31 === Lorito PMCs === 
    3234 * Start implementing core PMCs in something that compiles to Lorito. 
     35 * Make it possible to implement core functionality in Lorito. 
    3336 
    3437== Stage 2: Implement and Bootstrap == 
     
    3740 * Modify the current PIR compiler (ideally [http://github.com/bacek/pir PIRATE], possibly imcc or pirc) to emit Lorito. 
    3841 * Implement core PIR ops in Lorito.   
    39  * Switch to a Lorito-centric PBC. 
     42 * Switch to a Lorito-centric PBC format. (maybe) 
     43    * If we want to change the PBC format, this would be a good time to do it. 
    4044 * Make the final switch. All ops and PMCs get compiled down to Lorito during the normal build process (possibly using a bootstrapping step). 
     45 * Start rewriting core systems in Lorito (strings, mmd, packfiles, pcc, whatever's feasible). 
    4146 
    4247== Stage 3: Convert and Optimize == 
    4348 
    44 === Core Functionality Implemented in Lorito === 
    45  * Start rewriting core systems in Lorito (strings, mmd, packfiles, pcc, whatever's feasible). 
    46  * When you see a bottleneck, kill it. 
    47  
    4849=== Lorito Translations === 
    49  * Implement translation from Lorito to LLVM IR, libjit, GNU Lightning, LOLCODE, etc.  Lorito to C will be the default fallback. 
     50 * Implement translation from Lorito to LLVM IR, libjit, GNU Lightning, LOLCODE, etc. 
     51 * Lorito to C will be the default fallback. 
    5052 * Work in earnest on Lorito-level optimizations. 
    5153