The LL language. [arf6]

[Andreas Arff]

> >>> 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).

Even though it may be easier to use no. 1, I belive it would be slower.
The tree would have to do lots of "strcpm" to chose the path to the compiled
code, while an integer represenation as in no. 2 would only need a "cmp".

I'm no language guru so I don't actually now myself, but at least it seems
as no. 2. would be faster.


> Fare

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--