|Version 7 (modified by cotto, 5 years ago)|
As Lorito seems to be a somewhat nebulous concept about which people seem to be certain about only a few specific details (not that the specific details are the same between any two people), this is a list of questions we need to consider when designing, planning, and implementing Lorito. Feel free to add more or offer your opinion on a possible answer to any of them.
What are the main goals that Lorito should accomplish?
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.
How much of Parrot's current core do we want to eventually rewrite in Lorito?
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.
Will PIR compile down to Lorito assembly or will it be a superset of Lorito assembly?
We expect that current PIR code will continue to work unchanged on a Lorito-based Parrot.
How many layers below PIR will exist in Lorito?
Will Lorito have the option of compiling to C?
Yes. We will support transforming Lorito ops into equivalent snippets of C code as an alternative to the function-based runcore.
Will Lorito use a different bytecode format from the existing PBC?
This hasn't been decided yet.
If there is a distinct LBC (Lorito bytecode) format, will instructions be fixed-length?
Yes. All Lorito ops will take three arguments.
Will Lorito have the same calling conventions as Parrot currently does?
If Lorito's calling conventions differ from Parrot's current ones, what will they be?
Will Parrot's calling conventions remain the same after Lorito?
PIR that works with Parrot now is expected to run without modification on a Lorito-based Parrot. This includes calling conventions.
Will Lorito allow direct memory access/pointer arithmetic?
Will Lorito allow manual memory allocation/deallocation?
Lorito will allow manual memory management through the same interface used to access other C-level functions.
Will Lorito have a stack?
Will Lorito distinguish between data types at the lowest level?
Will there be separate storage for different types of data at the lowest level?
Will Lorito have a object model built-in?
No. The object model will be implemented on top of Lorito.
Will Lorito still have the same core object model as Parrot?
Lorito will exist below the level of Parrot's object model.
Will Lorito have a single op that does method dispatch at the lowest level or it will be simulated using a series of ops?
MMD will be implemented on top of Lorito.
Will Lorito have some declarative syntax at the lowest level for creating classes/types?
Will there be a declarative syntax at some level below HLLs for creating classes/types?
Will PMCs and Objects be merged?
Will Strings and PMCs/Objects be merged?
This hasn't been decided yet.
What requirements will Lorito impose on the memory layout of objects?
Will objects have a static vtable in addition to method dispatch?
VTABLE functions and methods will be unified post-Lorito. The Parrot development community hasn't decided what this mechanism will be, but it is likely that the internal representation of vtable functions will change from its current form.
How should method dispatch work?
Should method dispatch be tied to classes, to objects, to some vtable/prototype object associated with each object?
Should method dispatch use strings or symbols?
Symbols are likely but this design decision hasn't been discussed yet.