Changes between Version 13 and Version 14 of LoritoDesignQuestions
- Timestamp:
- 07/28/10 04:33:28 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
LoritoDesignQuestions
v13 v14 1 1 As [http://trac.parrot.org/parrot/wiki/Lorito 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. When adding answers, please ensure that there is some agreement among Parrot developers about the answer. 2 3 === How should I think about Lorito to understand its purpose and to answer these questions? === 4 5 At its lowest level a small set of primitives which could form the basis of a virtual machine to run code written in C without having to follow such features of C as its calling conventions and memory management. 6 7 Put another way, what if we had a small and fast virtual machine which supported CPS, multiple dispatch, PMCs, and garbage collection but gave us control over memory layout and let us compose more ops from a handful of simple ops? 2 8 3 9 === What are the main goals that Lorito should accomplish? === … … 15 21 === How many layers below PIR will exist in Lorito? === 16 22 23 PIR is currently syntactic sugar and parser magic layered over Parrot ops, which themselves are written in C. Lorito will replace C. Thus, PIR can remain unchanged at least at the architecture level. 24 17 25 === Will Lorito have the option of compiling to C? === 18 26 … … 29 37 === Will Lorito have the same calling conventions as Parrot currently does? === 30 38 39 Yes, at least from the PIR/PCC level. One of the goals of Lorito is to replace the C/PCC boundary, such that we can use PCC throughout the system. 40 31 41 === If Lorito's calling conventions differ from Parrot's current ones, what will they be? === 32 42 … … 37 47 === Will Lorito have a stack? === 38 48 49 Doubtful. 50 39 51 === Will Lorito distinguish between data types at the lowest level? === 52 53 Probably not. 40 54 41 55 === Will there be separate storage for different types of data at the lowest level? === … … 43 57 === Will Lorito have a object model built-in? === 44 58 59 Likely not. 60 45 61 === Will Lorito still have the same core object model as Parrot? === 62 63 Parrot's core object model will be implemented on top of Lorito. 46 64 47 65 === Will Lorito have a single op that does method dispatch at the lowest level or it will be simulated using a series of ops? === … … 51 69 === Will Lorito have some declarative syntax at the lowest level for creating classes/types? === 52 70 71 No. 72 53 73 === Will there be a declarative syntax at some level below HLLs for creating classes/types? === 74 75 Yes, though this is not a function of Lorito. 54 76 55 77 === Will PMCs and Objects be merged? === … … 63 85 === What requirements will Lorito impose on the memory layout of objects? === 64 86 87 Unknown; likely we can escape the tyranny of the C memory model (though we should keep in mind things like struct layout and padding where it matters on various architectures). 88 65 89 === Will objects have a static vtable in addition to method dispatch? === 66 90 … … 69 93 === How should method dispatch work? === 70 94 95 Not a question for Lorito. 96 71 97 === Should method dispatch be tied to classes, to objects, to some vtable/prototype object associated with each object? === 98 99 Yes, unless the system uses pervasive multidispatch at the lowest level. This needs more discussion, especially with regard to the needs of HLLs. 72 100 73 101 === Should method dispatch use strings or [http://en.wikipedia.org/wiki/Symbol_(Lisp) symbols]? === … … 77 105 === How will Lorito support native types? === 78 106 107 (Unknown; which native types?) 108 79 109 === How will Lorito support calling C functions in existing libraries? === 110 111 Lorito primitives at the lowest level will support building platform-specific call frames and calling C functions; this will be the basis of the new FFI/NCI. 80 112 81 113 === How will Lorito support advanced control flow constructs such as coroutines, continuations, exceptions and CPS in general? === … … 85 117 === What kind(s) of memory access will Lorito support? How will memory management (automatic and manual) work? === 86 118 119 Lorito will support direct memory access with its lowest level of primitives. 120 87 121 === Will Lorito allow direct memory access/pointer arithmetic? === 122 123 Yes/hopefully not. 88 124 89 125 === Will Lorito allow manual memory allocation/deallocation? ===
