Why a LLL

spc said:
>>>   You know, it suddenly "clicked".  What you are after, Fare, is a backend
>>> to the HLL.  That's it.  Nothing more and a technology that's been around
>>> for quite come time (even Microsoft was doing this in the mid 80s for all
>>> their languages).
>>
>> The LLL is *not* a backend to the HLL !
>> Sure, it will support the same memory model as the backend,
>> and be nicely interfaced to it;
>> But it will no more be the HLL's backend
>> than C is the backend of HLL compilers under Unix,
>> just because the two share the same memory model !
>> They share the same model, because role of the LLL is precisely
>> to do all the bit twiddling, IRQ handling, I/O port access, etc,
>> needed to bootstrap and debug the computer,
>> that are not worth doing (or easily done) in an HLL backend,
>> but that we need to have the computer running.
>> 
>   So, if that's the case, that the LLL is NOT the HLL backend, then why even
> come up with a new LLL?  If the LLL is supposed to be non-portable,
> efficient, difficult, yada yada, etc etc, free from the constraints of the
> HLL, then why not use C?  Or Assembly?  Or Forth?  Or all the above?
Can't you read ? I just said it !
BECAUSE IT MUST *CONSISTENTLY* IMPLEMENT THE SAME PERSISTENT MEMORY MODEL
AS THE HLL BACKEND DOES.
This eliminates C, Assembly (unless you preprocess with
something like m4 -- ugh), and ANS FORTH (though not a hacked FORTH thingy),
that cannot do it consistently: we'd spend all your time tracking bugs
related to not following the model.


>>>   I would have assumed something like this, had you, Fare, not made such a
>>> big production out of it, making it, in my view, into something so different
>>> that it needed discussion.  It doesn't.
>>
>> I don't think it needs the discussion some have made about it,
>> but it sure is more than what you say it is.
>>
>   Well, some of us are trying to pin down what the HLL is, and what the LLL
> is (and I feel I'm loosing the battle here).
   The HLL is a high-level system to consistently develop
the abstract specifications, concrete implementations, and user interfaces,
of computable objects, in a dynamically modular way;
the list of high-level requirements about it are listed in the WWW pages,
and though they do not perfectly define the HLL,
and are enough to define the constraints low-level model it will rely upon:
   The LLL is a low-level system to manage the low-level resources
in an efficient yet consistent way.
   The LLL may be any low-level language that
allows full control on the hardware, but should preferrably
make it easy to follow the strong constraints of persistence.


>>>   Or, at least not to the degree you think it might.
>>
>> I never thought it deserved a lot of discussion. A lot of coding, yes.
>> But nobody here talks about coding, and even less does it, it seems,
>> but utsl, Patrick, and me.
>>
>   One reason may be because the groundwork doesn't exist.  That the design
> doesn't exist.  That the goals aren't fully defined, and anything built upon
> such a foundation will be a hack job.
Surely we shall stop discussions, and publish a full descriptions as
possible of whatever we want.


>>>   Or, if the LLL is going to be so different from CPU to CPU, then why even
>>> bother with it?  You might as well go HLL -> assembly and be done with it.
>>
>> Because, as I already said
>> it will not be *that* different from CPU to CPU,
>> with *large* common parts (even C has different pointer and integer
>> models from CPU to CPU, not to talk about FORTH et al);
> 
>   I'm not sure what C compilers you've been using, but C doesn't have
> different pointer and integer models from CPU to CPU.

>[things undefined in C or FORTH]
>   At that end, C isn't THAT different from CPU to CPU.
In the same way, the initial LLL will not be THAT different from CPU to CPU,
especially for CPUs of similar design.
But again, the LLL is left implementation dependent in the OS specifications,
and the implementors have all the freedom to modify it as they like
(they are not forced to have a universally compatible pointer type,
for instance, like C's void*).
We will make it easy to port to reduce our work,
but compatibility is not a requirement (even less interoperability),
because it would result in a slow down without bringing anything,
for interoperability is to be achieved through the HLL, not the LLL.



>> my point is that compatibility should not be sought,
>> that the more a program requires efficiency,
>> the less it will have compatibility,
>> and that the LLL should specialize towards efficiency.
>>
>   So, does the HLL spit out LLL code, or what?
   No, it won't. It will spit out code trivially linkable to the LLL
(for a given implementation), but not (forcibly) LLL code:
optimized code will be directly binary code,
with an LLL-compatible interface for each entry point defined.
Spitting out LLL code is not forbidden, though, and may be
practical to trade time for space in non-time-critical parts
of programs.


>>>> 2) Yes, of course, the more platforms you'll support,
>>>> the more LLL programmers you'll have to find to support them.
>>>
>>>   Then why limit the LLL programmers in the tools required?  Why force the
>>> LLL to be so poor then?
>>
>>    They are not limited. Feel free to use assembly, C, etc.
>> However, we will provide a tool adapted to the memory model chosen.
>> Feel free to adapt other tools, though it will be very hard to
>> you if your programming language cannot help you consistently
>> managing the constraints of the model.
>>
>   Fare, the more I try to pin down the specifics of the HLL, the more fluid
> and ephemeral it becomes.
You mean the LLL, I think, as that's what you've been talking about so far.


> I feel as if there's nothing there.  What is the
> relationship between the HLL and the LLL and other langauges people may want
> to use?
>
>   I thought it went
>
> 		<other languages> --> HLL --> LLL --> binary code
>
>   But you just said that the LLL is not the back end of the HLL, so we now
> have:
>
> 		<other languages> --> HLL --> ???
> 		LLL --> binary code
>
>   So, what is it?
   What are those arrows ? Interpretation ? Compilation ?
Partial Evaluation ? You're not very clear yourself.
   What the system *specifies* is that the HLL will be the priviledged
way to talk to the system, in which all other implemented languages would be
translated/translatable (that is, the HLL dictates the memory model used
for everyday programming). This corresponds to your informal
	<other languages> --> HLL
notation, where the arrow would mean
semi-mechanical translation/translatability
which is more precise than compilation,
but at the same time lets language implementors free to bypass the HLL.
   Now, what the system *implements* is that the LLL will be
*at first* interpreted in assembler, but that further refinements
may have it compiled/optimized directly to binary code. This LLL
will be used to build a the low-level parts of the system
(bootstrap, device drivers, etc), so as to provide more and more
elaborate primitives for the HLL to use.
However, the HLL will also eventually bypass the LLL
to produce binary directly.
Possibly, the LLL will end-up as just a subset of the HLL,
and/or the HLL will end up as an extension to the LLL.


>   The HLL has always confused me, and still does.
The WWW pages are a good start about it.
But I admit they are only a start.


>>>   Personally, I feel you'd (Fare and the other HLL people) be better off
>>> defining the HLL, and maybe implimenting it under an existing system, and
>>> leave the OS portion till you've hashed out what you want in the HLL and the
>>> OS.
>>>
>>>   -spc (just my two zorkmids worth)
>>
>>    That sure is an effort to do, and Patrick and I have been doing it;
>> but the whole point of the dual HLL/LLL subprojects is to do it
>> in parallel, as we already know the low-level model used by the HLL
>> (persistent GC'ed memory with weak references),
>> and the LLL implementors are free for the rest
>> (use of VM, size and format of pointers, etc).
>> 
>   So, what is the HLL implimented in, and the HLL compiler spits out, what?
   The language definitions are independent from their implementation.
That being said, the HLL will be implemented as a compiler written
in a subset of itself, that may be interpreted;
I first though about the LLL to implement the interpreter,
but as Patrick pointed out, doing it in Scheme allows to decouple
the two projects, and to have an initial development system nearer
from the final one.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"