The LL language. [arf6] [dpm7] [djg18]

[David Garfield]

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

I still am wondering why we need a Low Level Language?  I thought the
purpose of this group was to build an advanced operating system for
our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
from using the 386 segmented memory for the sake of making our OS more
portable to other architectures, but this group is begining to look
like an advanced operating system research project.  I don't think
that was the point.

As for a Low Level Language, what's wrong with a compiler to 386 
machine code?  I will admit that this requires writing assembly code 
to the compiler writers interfaces, but it means we don't need to 
write our own compilers and LLL interpreter.  

I will admit one thing, that having "object code compatibility 
*across* platforms" for selected executables would be a good thing, 
but this means, to me, that we have native mode executables and 
portable executables, and that we use native mode for the entire 
kernel, for most class implementations, most utilities, and many 
applications.  Some classes, utilities, and applications get done as 
portable executables.  General network distribution of applications is 
a reasonable use for portable executables.  

David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com