Changes between Version 9 and Version 10 of LoritoDesignQuestions
- Timestamp:
- 07/22/10 16:53:33 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
LoritoDesignQuestions
v9 v10 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.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 (inferior runloops, for instance). 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 6 7 7 === How much of Parrot's current core do we want to eventually rewrite in Lorito? === 8 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.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 an HLL that compiles down to Lorito ops. 10 10 11 11 === Will PIR compile down to Lorito assembly or will it be a superset of Lorito assembly? === … … 49 49 === Will Lorito have a object model built-in? === 50 50 51 No. The object model will be implemented on top of Lorito.52 53 51 === Will Lorito still have the same core object model as Parrot? === 54 55 Lorito will exist below the level of Parrot's object model.56 52 57 53 === Will Lorito have a single op that does method dispatch at the lowest level or it will be simulated using a series of ops? === … … 65 61 === Will PMCs and Objects be merged? === 66 62 67 Yes.63 [http://irclog.perlgeek.de/parrotsketch/2010-07-13#i_2551009 Yes]. 68 64 69 65 === Will Strings and PMCs/Objects be merged? === 70 66 71 This hasn't been decided yet.67 This idea has been mentioned but we [http://irclog.perlgeek.de/parrotsketch/2010-07-13#i_2551002 haven't reached] a decision. 72 68 73 69 === What requirements will Lorito impose on the memory layout of objects? === … … 75 71 === Will objects have a static vtable in addition to method dispatch? === 76 72 77 VTABLE functions and methods will be unified post-Lorito. The Parrot development community ha sn't decided what this mechanism will be, but it is likely that the internal representation of vtable functions will change from its current form.73 VTABLE functions and methods will be unified post-Lorito. The Parrot development community haven't decided what this mechanism will be, but it is likely that the internal representation of vtable functions will change from its current form. 78 74 79 75 === How should method dispatch work? === … … 83 79 === Should method dispatch use strings or [http://en.wikipedia.org/wiki/Symbol_(Lisp) symbols]? === 84 80 85 Symbols are likely but this design decision hasn't beendiscussed yet.81 [http://irclog.perlgeek.de/parrot/2010-07-13#i_2551081 Symbols are likely] but this design decision hasn't been widely discussed yet. 86 82 87 83 === How will Lorito support native types? ===
