The LL language. [arf6] [dpm7]

[Dennis Marer]

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

One important thing to consider is portability - say machine A has a 64-bit
little endian word and machine B has a 32-bit big endian word...they aren't
going to be compatible.  This is assuming, of course, they need to!  You may
have heard that OSes like Conix have object code compatibility *across*
platforms...is this the intention here?

Dennis