LLL Re:many [far30]

[Francois-Rene Rideau]

>>>> 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.
(yes, I was confused and exchanged the numbers; please excuse and see my reply)

>>>
         ,
>>>> 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
YES it is. But there's no problem possibly converting data endianness when
loading from disk to memory; as I previously said, LLL must be standard up
to a quick standard transformation.


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

> 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 !)
- A LLL interpreter is easy to write and maintain, so that we can start
using LLL immediately when we port the system.
- 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. 
- 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
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
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

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.

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