A final, short gentle comment..

[Nathan Hawkins]

On Wed, 10 Apr 1996 spc@gate.net wrote:
> > >   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?

As _I_ see it, it's more like an environment in which the HLL can be more 
comfortably implemented. I see it as being between a virtual machine and 
a backend. A true virtual machine wouldn't really handle IRQ's, it would 
virtualize them. Which would be no help at all. As for the backend for 
HLL, I'd say that it can do part of it, but the HLL will be doing it's 
own thing more than not.

As for why not use C, etc.: the plan is to build a LL environment that is 
more dynamic than that. Forth, with extensive modifications, is in fact, 
what we've been discussing. The reasons for not using Forth itself, have 
mostly to do with priorities; compatibility with Forth isn't very 
important, but doing things in a way that makes the LLL more usable for 
its intended purpose are.

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

Sigh. The point of the HLL escapes me to some extent. (duck) But the LLL 
is to be a foundation to the system. Hopefully, it won't be limited to 
that, though.
One problem in all this, is that it seems only Fare and I have even a 
similar view of the LLL/HLL idea. So I'll have a go at it.

As I see it:

HLL -> LLL -> binary.

That is, the HLL compiler will compile to LLL, and the LLL will either 
interpret or compile to binary. However, the HLL may become able to go 
directly to binary, if someone writes a compiler for a specific system 
that can do that. Regardless, that's not my problem. If someone does 
that, it will either replace the LLL, or hook into it. So the LLL would 
probably still be there, anyway.

The LLL is also a hardware interface layer. The LLL on the x86 will be 
the part that deals with all the oddities of the system architecture, or 
as many as can be dealt with there. So the HLL won't need to know about 
the cascading of IRQ's 9-15 through IRQ 2.

The point is to create a whole environment which the HLL will fit over 
top of, without major hacking on either the environment or the HLL. What 
mechanisms the LLL can reasonably provide, it should. (Not policies, 
mechanisms. Policies, other than LL implementation should be left at as 
much as possible.)

So LLL won't be exactly a back end, nor will it be the OS, either. Just a 
piece of the system, which deals with what it can.

Now I hope this helps end the confusion about the LLL. I can't help with 
your confusion about the HLL, since I've never understood it either.

One additional note: I hope to be able to use the LLL as the basis for 
other things, specifically my own OS project. This will be covered by the
GPL, of course. So, to me, it is important that the LLL actually be useful,
and provide reasonable functionality, by itself.
My whole involvement with Tunes, is to try and avoid duplicated work, and 
make a core LLL that can be used by both projects.

*utsl*