A final, short gentle comment..

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> >>> 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.
> 
  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?

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

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

> >   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.  About the only thing
said about such things (ANSI C here) are:

	an integer is the natural word size of the CPU, with a minimum size
	of 16 bits.

	a short is an integral value, with a minimum size of 16 bits.

	a long is an integral value, with a minimum size of 32 bits.

	a short can be shorter than, or equal to, an integer.

	an integer can be short than, or equal to, a long.

	a pointer is a pointer, and NOT an integer.  Also, pointers between
	different types do not have to be represented the same way.  The
	only pointer type compatible with everything is void *.

  Forth is a bit more precise with the definitions, and yes, the
implimentation is different from CPU to CPU (and maybe from compiler to
compiler on the same system), but code can be written (and I've written such
code) that will compile cleanly under a system with 16 bit integers, 32 bit
longs and 16 bit pointers, to systems with 32 bit integers, 64 bit longs,
and 39 bit pointers.

  At that end, C isn't THAT different from CPU to CPU.

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

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

  The HLL has always confused me, and still does.

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

  -spc (Or is this a case of "I'm not really sure what I want, but I know
	what I don't want, I think ... "?)