A final, short gentle comment..

[Francois-Rene Rideau]

> On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
>>> Me>> then you presumably have to
>>>  create a virtual machine on EACH system that
>>>  (a) uses Scheme as its "native" language;
>>>  (b) can perform ANY & EVERY O/S task in the context of (a);
>>> Fare>>  Of course I'll have to (even if it's not Scheme) anyway.
>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>> So this is your common level! Please note that there is then
>>> no "LLL" subproject. There are a zillion. I hope you can
>>> find a zillion "LLL" programmers to write them (and revise them
>>> IN CONCERT according to your ever-changing specifications)!
>>> I will watch with interest.
>> 1) There is not a ONE common level.
>> The more people have in common, the more they'll share.
>> You just can't ask an Alpha version and a MuP21 version
>> to share the same LLL, because they are too different architecture.
>> 3-regs RISC cpu implementations will share more together than
>> just what they will share with every implementation.
>> Perhaps it's hard for you to accept,
>> but a heterogeneous world requires heterogeneous solutions.
>
>   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.

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

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

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


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

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

--    ,        	                                ,           _ 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/"