Changes between Version 4 and Version 5 of LoritoDesignQuestions
- Timestamp:
- 07/21/10 18:34:37 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
LoritoDesignQuestions
v4 v5 3 3 === What are the main goals that Lorito should accomplish? === 4 4 5 We want Lorito to have the same capabilities as C in a form that is easy to parse, instrument, transform, analyze, etc. Much of the slowness in the current (circa 2.6.0) pre-Lorito Parrot comes from the impedance mismatch where C code and PIR code need to interact. By creating Lorito and using it to implement code that is currently written in C, we can eliminate that bottleneck and make Parrot more amenable to further optimization and analysis. 6 5 7 === How much of Parrot's current core do we want to eventually rewrite in Lorito? === 6 8 9 Ideally, everything. Some very low-level code such as GC's stack walking may need to be partially implemented in C or assembly, but the endgame is that almost all of Parrot is implemented in a HLL that compiles down to Lorito ops. 10 7 11 === Will PIR compile down to Lorito assembly or will it be a superset of Lorito assembly? === 12 13 We expect that current PIR code will continue to work unchanged on a Lorito-based Parrot. 8 14 9 15 === How many layers below PIR will exist in Lorito? === … … 11 17 === Will Lorito have the option of compiling to C? === 12 18 19 Yes. We will support transforming Lorito ops into equivalent snippets of C code as an alternative to the function-based runcore. 20 13 21 === Will Lorito use a different bytecode format from the existing PBC? === 14 22 23 This hasn't been decided yet. 24 15 25 === If there is a distinct LBC (Lorito bytecode) format, will instructions be fixed-length? === 26 27 Yes. All Lorito ops will take three arguments. 16 28 17 29 === Will Lorito have the same calling conventions as Parrot currently does? === … … 37 49 === Will Lorito have a single op that does method dispatch at the lowest level or it will be simulated using a series of ops? === 38 50 51 MMD will be implemented in terms of Lorito ops. 52 39 53 === Will Lorito have some declarative syntax at the lowest level for creating classes/types? === 40 54 … … 43 57 === Will PMCs and Objects be merged? === 44 58 59 Yes. 60 45 61 === Will Strings and PMCs/Objects be merged? === 62 63 This hasn't been decided yet. 46 64 47 65 === What requirements will Lorito impose on the memory layout of objects? === … … 54 72 55 73 === Should method dispatch use strings or [http://en.wikipedia.org/wiki/Symbol_(Lisp) symbols]? === 74 75 At this point symbols are likely but this design decision hasn't been discussed yet.
