Created
March 11, 2010 22:00
-
-
Save cotto/329720 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
proposed Lorito roadmap | |
This roadmap proposes that Lorito be planned and implemented over the course of four stages. The tasks within a | |
stage should be more of less independent of each other, making division of labor easier for interested developers. | |
stage 0: prep | |
* get an nqp-rx-based ops compiler ("opsc") generating similar C code to ops2c | |
* check in generated C code for ops and PMCs for bootstrapping | |
* define Lorito ops and semantics (ffi, arg format, binary format, registers, ops, syscalls, text format, etc) | |
* implement some PMCs, ops and library bindings/PMCs in Lorito to demonstrate that Lorito is sufficiently powerful | |
* identify blockers to implementing core PMCs in Lorito* | |
stage 1: prototype | |
* implement Lorito as dynops | |
* modify PCT-based compilers to emit Lorito dynops, start running them once Lorito dynops work | |
* make opsc able to process other HLLs* in addition to C + macros | |
* define the translation from PIR to Lorito | |
* figure out how to make user-defined ops possible | |
stage 2: implement/bootstrap | |
* check in Lorito* versions of all ops and PMCs for bootstrapping | |
* convert all PIR ops to Lorito* | |
* convert all PMCs to Lorito* | |
* modify imcc/pirc to emit Lorito | |
* switch Lorito to the core ops, translate PIR code to Lorito at runtime | |
stage 3: convert/optimize | |
* start rewriting core features in Lorito* (strings, mmd, packfiles, pcc)** | |
* When you see a bottleneck, kill it. | |
* implement translation from Lorito to LLVM IR, libjit, GNU Lightning, straight C, LOLCODE, etc | |
stage 4: world domination | |
* ponies and rainbows may be involved | |
* Note: When I say Lorito* or HLL*, I mean anything that can compile to Lorito | |
without any additiona runtime requirements. This could be PIR, nqp, Close, | |
winxed or anything. As long as we can take the HLL and get PIR or Lorito from | |
it, we can use it. | |
** I'm not sure how many subsystems can possibly be implemented in Lorito. | |
The idea is that by the time we get to stage 3, having more subsystems written | |
in Lorito* will give us a speed boost by avoiding the C/PIR boundary and | |
allowing more of Parrot to be subject to analysis and optimization. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment