LLL Re:many [far30]

[Michael David WINIKOFF]

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

Yes and no. 
Modifying an existing compiler to generate a slightly different object code
format is arguably less work then designing an LLL.
Bear in mind that we will have to live ith any deficiency in LLL.

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

This varies. Yes, parsing and lexing take time but linking also takes a fair
amount of time.


Besides, most of the compilation you do will be during development when you
HAVE to do the first step source->LLL, sure you save on the LLL->executable
and I think interpreting LLL will help in making a good debugger but you're
not saving on lexing/parsing -- rather on linking.

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

You don't need LLL for this. It can be done with the object code.

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

This will only be practicle if you have a caching mechanism so code is
not recompiled each time it is executed on a particular node.
THis implies some method of keeping track of when the LLL "source" changes
so we know that we do have to recompile.


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

Yes. The point is that once you've assembled (which for a commercial program
gets done once b4 distribution) you have speed at a possible increase in
size.

The main benefit of LLL is during development, slightly faster compilation,
easier to develop debuggers (although you really want source level debugging
anyway :-)

> - many programs whose author cannot (for some reason) write an optimized
> portable compiler may require (simple) run-time code generation (with

Run time code generation? Please NO! We are not going to have self modifying
code. Or if we are going to then you can debug it :-)

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

Yes and no.
I don't think ANSI has anything to do with it.
ANSI tends to come in on the action only ratherlate when the language/OS 
is allready popular.

Regards companies I agree with your point.
However these days there is a lot of talk on open-systems and people are 
actually moving in that direction.

One interesting idea which DEC has been working on in the context of their
Alpha project is the automatic translation between object code for different
OS/Machines.

Shalom,
Michael


--------------------------------------------------------------------------------
Shalom: Hi OR bye OR Peace
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.