LLL Re:many [far30]

[Francois-Rene Rideau]

">>" is [far30]
">" is Michael's Apr 30 reply

>> - 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.
> 
If we have an OO late binding mechanism (=dynamic, run-time, object link),
which is I think basic for an OO system (what's an OO system if there's no
such thing ?), it will not be that easy at all including these mechanism
in the compiler; and there won't be anymore usable code/data portability.
Thus, from one platform to the other, you'll have to exchange some ASCII
text, as with unix, and recompile it, but keeping sources for further
exchange (which explains why unix eats so much disk space).

>> - 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.
> 
Yes, but there's no way to escape it. At least, _user_ compile time will have
been sped up by a two to five factor.
> 
> 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.
 Yes, but only the author will have to compile, not the user; moreover,
including info in LLL keeping track of what code corresponds to what source
part will allow partial compile; finally, if the parsed format is standard
(=commented unoptimized LLL), we can build parse-on-the-fly structured
editors. If you ever used something like GFA Basic on the Atari or the Amiga,
you'll know that structured editors are far more functional than linear text
editors; and GFA is limited by its Basic structure, whereas if we build our
HLL, we we're not, and we can improve the principle.
 I conceive the system as a huge structured relational code&data base. Of
course, ASCII source IS a possible and sometimes useful representation of it,
but it certainly isn't the only, and neither the best, nor the quicker, nor
the easiest to read/understand/modify for the human, nor the only portable
one. Let's just not be bound by the ASCII limitations of unix(tm).

>> - 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.
Yes, but LLL is portable, whereas object code is not. But signature is not
an essential point.

>> - 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.
>
Well, you know, this is only a particularization of the general problem of
distributed systems, i.e. keeping track of "copies" of different versions
of objects. If we have a distributed system, this will only be an
application of our more general solution (what will it be ?) to the one
big problem.


>> - 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.
>
If Moose is made portable, assembling won't be done b4 distribution, except
possibly for time-critical and/or unportable drivers.
>
> The main benefit of LLL is during development, slightly faster compilation,
> easier to develop debuggers (although you really want source level debugging
> anyway :-)
>
and portability across different (and/or future) architectures.
>
>> - 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 :-)
 Did you never have to write some application where the user had to/could
input functions and/or expressions ? (curve drawing programs and/or
small spreadsheet app, etc ?). Sometimes, you like it to be powerful, even
if the kernel is simple and you can't afford building something complex.
Then, a STANDARD LLL and/or semi-HLL (i.e. standard local entries to the
HLL compiler) can be more than just useful. Saves time, money, increases
power, allows easy inter-app high-level communication.

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

P.S.:
unix(tm) is a trademark of AT&T.

   ,
Fare