LLL Re:many [far30] [djg19]

[David Garfield]

On Thu, 29 Apr 93 21:58:04 MET DST, "Francois-Rene Rideau" wrote:
...
> > 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.
> We use PC because we own them, and we own them because they are cheap and
> standard. Now, if we had a portable system, we could use better cheaper
> (but not standard) computers; we could also be sure that the system can be
> future architecture so that our work won't be lost.

But the only CPU feature particularly non-portable we might be using
on our 386 & up boxes is segmented memory.  I would actually PREFER to
make use of this to its fullest, even to using 48 bit pointers.  I AM
willing to give this up to make the system more portable.  ***And I
thought the original purpose of this group was to make a better OS for
our 386 boxes.***

> > 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.
> - We MUST write new compilers to fit the system object code format
> (unless you want to use DOS or linux compatible executable code !)

Or write a new linker that takes an existing object code produced by
existing compilers and produces an executable for our operating
system.  And actually, I believe GCC already has a standard object
module format, if we want to use GCC.

> - A LLL interpreter is easy to write and maintain, so that we can start
> using LLL immediately when we port the system.

Easy to write.  Easy to do wrong too.

> - interpreting will be done only when time is not critical, or at the
> beginning (before a compiler is available).
> - LLL (with comments added) can be used as source code for real-time
> compilation. Current compilers spend most of their time parsing; type
> checking and inter-procedural optimization also are very slow; all this
> can be done machine-independently and thus in the source->LLL compilation.
> Thus, LLL->machine code (or assembler) will be much quicker than source->
> the same.

It sounds like you want to have 4 non-OS products here:  HLL->LLL,
HLL->machine code, LLL->machine code, LLL interpreter.  Is this right?
Is this reasonable?

> - The main problem is optimization, which even is very machine dependent.
> If you need optimize some time critical routines, you may add info about
> the routine to mere interpretable code. You may rather choose to forget
> about some info, and preoptimize for best use on architectures you intend
> to use the program with, and/or include optimized version(s) of critical
> parts of the code, etc. However, you can't have something at the same
> time portable, immediate, compact and optimized: you must remove at least
> one of these features for a _given_ LLL program (but you may keep the
> three others).
> - LLL signatures can also be used to copyright/number software (didn't you
> Dennis talk about copy protection in the news ? well this at least allow
> identifying a program.

> > 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.
>
> - LLL can be a means to communicate code across a heterogeneous distributed
> version of the system. Each machine compiles or interprets the code portion,
> without having to globally recompile a possibly huge HLL program.
> - for high level tasks, LLL may be quicker and more compact than assembly,
> and/or assembling LLL before executing it may be slower than interpreting it
> (especially when there are many late object bindings).
> - many programs whose author cannot (for some reason) write an optimized
> portable compiler may require (simple) run-time code generation (with
??huh??
> sometimes optimization _wish_). Such programs are horrible/impossible to
> write properly with the given constraints in current systems, all the more
> if you want it both quick (or compact) and portable. The standard
Are you talking about a standard compiler back-end?  Like GCC is
[supposed to be]?
> inter-platform LLL solves this kind of problem: standardness ensure LLL
> optimal efficiency (both if interpreted or compiled), and saves the author
> from writing (=much development time) and including (=great increase of size
> for comparable performance) it in his code, not to speak about allowing
> interfacing the code with possible (and/or compulsory) external programs.
> Thus LLL is also a relief for the average programmer !
>
> > David
>
>    ,
> Fare

O.K.  What do you want to use this LLL for (Direct answer please)?  As
I said, I think it is reasonable for distribution of applications....
One thing I will point out is that adding a standard LLL to an OS can
really be done any time before the OS goes into wide distribution and
porting.  It really is a simple task, compared to building the OS.

> P.S.: I thought I had posted this message two days ago. Perhaps you received
> it or it was lost. This version of far30 includes some modifications.

You mailed it to me.  I thought you were just having mailer problems
again.  You want me to mail a copy back to you?

> P.P.S.: Michael fears that if a LLL had been a good idea, some would have
> been adopted; but the problem with LLL adoption is that there is too much
> people to have agree for the ANSI to publish something (moreover, the ANSI
> is so slow that when they manage to do the least thing, it already has
> become obsolete); to finish with, large companies (IBM,Microsoft,Apple,Sun,
> etc) for common user never want a portable (not to say quick/compact)
> system for they earn their (extremely high) profit by selling unportable
> architectures, together with software to exchange data and hardware to
> store converters (even microprocessor manufacturers don't want code
> portability FROM their products, do they, Dennis ? :-).

Actually, it HAS been done before!  They called it p-code.  It was
part of UCSD Pascal.  It ran on both PDP-11s and 8080s, after having
only a boot disk different between them.  Of course, it went
commercial at version 1.5, and didn't last long past the introduction
of the PC, but it was available for the PC.  It also ran on Apple ][s
as well, and I heard that someone built a CPU that ran it as machine 
code.  Who wants to try again?

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