The LL language. [arf6]

[Francois-Rene Rideau]

>>> About the LLL. I have been thinking on it for a while.
>>>
>>> As I see it, there are two ways of doing it if we consider the Fare' way.
>>>
>>> 1) Create a assembly like language, interpreted.
>>> Say with variables and a couple few commands as add, sub, mov etc.
>>>
>>> 2) Create a machine language like language, of course interpreted.
>>> Say 64bit wide to ease the stepping up to 64bit platforms.
>>>
>>
>> my proposition is
>> 3) Create a stack language, which is EASY to port and interpret, as well
>> as to simplify and compile, and which is near from the tree representation
>> obtained while parsing. Quick and efficient.
> 
> Yes, but you can do this in both case 1 and 2:-).
> 
 Method 2 is much slower and redundant. It should be excluded but for human
readability (using some kind of assembler/disassembler). Let's choose method 1.
 However, remember we define our LL up to a quickly computed isomorphism
(coding/decoding) so that each representation (host memory, disk, etc) may
choose a proper format (using numbers or pointers, etc). 

 BTW, there's an optimization problem: optimizations made for LLL code may be
bad choice for the compiled version, so that LLL code destined to be compiled and not
only interpreted should remember data about the source code that may allow better
optimization.


>>>         --Andreas Arff          andreasa@dhhalden.no--
>>
>>    ,
>> Fare

> Arff

   ,
Fare