Tunes

[spc@gate.net]

On some network somewhere in cyberspace, Patrick Premont transmitted:
> 
> That's one of the things optimizing compilers do, cache the top of the
> stack in the registers. I wrote parts of a simple Scheme compiler which
> did that.
> 
> Nathan, what does it mean for you the LLL ? It seems you are defining as
> some kind of Forth. But then the problem of choosing the registers etc...
> is part of the problem of compiling the LLL to machine code.
> 
  But at some point, the CPU has to execute code.  It's all fine and good to
say that something like '(add thisvar tothatvar withresulthere)', but
something somewhere is going to have to convert '(add thisvar tothatvar
withresulthere)' to 

		mov	eax,[thisvar]
		add	eax,[totharvar]
		mov	[withresulthere],eax

  or something eventually.  That's the one thing that has bugged me about
you Tunes guys, you seem to expect this stuff to happen automagically. 
Sorry, that ain't going to happen.

  Okay, there seems to be some fundamental communications problem here as to
what is what.  More on this later ... 

> If however by LLL you mean the set of low-level conventions that will
> be used in Tunes, you are talking about something different where the
> choice of registers is relevent.
> 
> LLL has been used to describe both so I'm not completely sure what you
> mean. The set of low-level conventions will have to fit in a nice theory
> which will make the HLL capable of choosing the low-level conventions.
> I'm working on that right now (first class representations). It's difficult
> to say at this point if/how you/we should take that into account. Hopefuly
> I'll have something usable before we have invested a lot of work
> in particular conventions... My system might not impose many modifications
> but I can't be sure at this point.
> 
> As for the LLL as a standard low-level language (not the set of
> low-level convetions), I think you should be clear about what you want
> it for. You seem to say that you like programing at the low-to-mid
> level. That's all right but what can Tunes bring to that level ?  I
> don't think that is where Tunes will be special. I think that in the
> finished product, the low-to-mid level programmer will either be
> enhancing the compiler/partial-evaluator or programming at the high
> level. Low level stuff is something to be generated automatically not
> written by hand in large quantity.
> 
  It depends upon what you consider low level.  I know Fare things LISP is
low level (!) whereas I tend to think of assemly as low level.

> Unless you want to write a lot of low-level code directly, you don't
> need a language like Forth with a syntax, modules, name-spaces
> (vocabularies),... These are considerations for the human writing the code.
> A intermediate stack language (as is often used in compilation) is enough.
> It does not need to have it own character-stream syntax, its programs can
> simply exist as a structure of (Scheme for now) objects in the compiler.
> Giving it a character-stream syntax CAN be done but you start to
> want a lot of language features for humans (name-spaces,...).
> 
  It might be anachronistic of me, but I tend to want to look at the low
level code sometimes, as that may be the only way to solve a particularly
nasty problem (in porting joe to QNX, I ended up having to look at the
generated machine code to see that the frame pointer was being trashed
somehow and tracking it back to the problem).  Have you ever SEEN code
output from a compiler (say, like GCC)?  It's not readable by any standards. 
The Unix weenies tend to say "Well, assembly isn't for humans."  

  As a result, the assemblers found on Unix systems tend to be pure trash
with a syntax that I find exceedinly offensive (and make MASM look beautiful
by comparrison).  You may find that the low level stuff doesn't need a
'character-stream syntax', but at what point is the cut-off made?

> If the LLL is to be the (portable) language to which the HLL compiles
> (when it wants to), then Forth would not be the LLL (I wouldn't want
> to compile to Forth) but another language that is compiled to the LLL
> in a straightforward way. But I'd rather have this language be (as
> much as possible) a subset or something similar to a subset of the HLL.
> 
  What's wrong with Forth (or a Forth-like lanaguage)?  You said yourself
that most compilers output something akin to a stack based language, with is
Forth.

  But what you are saying is you want:

		HLL -> (some other representation) -> LLL 

  But then isn't the LLL:

		LLL -> (some other representation) -> CPU code

  That's some five levels of compilation.  The more I think about this
HLL/LLL concept, the less I like it.  Because if I understand the end
results, you'l have something like:

		C -> HLL

	or

		Ada -> HLL

	or

		<insert your favorite nonHLLtype langauge here> -> HLL

  Then how is the HLL any different than the LLL (except for some vague
automagical stuff like DWIM)?

> >   Traditionally, a "process" owns resources.  A "thread" ("task" in
> > Amigaspeak) doesn't.  A "thread" is a resource.  Along with "devices",
> > "files", "memory".  A "thread" is a unit of execution, and in a loose sense,
> > "owns" the CPU, which is a resource, and some memory (out of which it is
> > executing), which is a resource. 
> 
> Unless absolutely necessary, I guess we shouldn't define this kind of
> thing in the LLL. It is the HLL which will guide the selection of
> these things. Hmm.. damn I don't like this LLL/HLL dichotimy at times.
> They are linked so tighly that idealy you'd have only one genius
> desing the whole thing in one piece. Since that's not going to happen,
> we'll need a lot of communication.
> 
  Technically, such definitions are beyond the scope of a language
definition and are defined in terms of the OS, which is independant of the
language (certain 68k Assemly, BCPL and C (all of which AmigaDOS is written
in) don't have 'process' or 'task' as part of the language).

  An OS is written in some language (or languages).  It's NOT the language. 
Now, part of the environment of the OS may be integration into an IDE with a
language (tradition Forth systems are like this), but there is a distinction
between what is done (OS) with how it's said (the language the OS is written
in).

> > > An alternative would be a design I've been told about, involving nestable
> > > word definitions, like this:
> > > 
> > > : foo : bar ; ;
> > > 
> > > where foo:bar or some related syntax would be used. I think this would be
> > > too complicated, although I as I recall, Pascal allows something like this for
> > > functions. I never used it.
> 
> Hmm... lexical scoping. I take that for granted. Scheme has it. The
> HLL will have it. Why redo it again for a Forth-like language ?
> 
  At some level, lexical scoping has to be defined.  It seems that the HLL
lexical scoping will be done in terms of the Scheme lexical scoping.  But
where is the Scheme lexical scoping defined?  The buck starts somewhere ...

  And again, I hate to interject hard concrete implimentation icky icky
details into this discussion, but WHAT IS THE LLL AND THE HLL?  I'd even go
so far as to ask WHY EVEN BASE THE OS ON A SINGLE LANGUAGE? but the last
time I asked that the consensus was to do it anyway, like every other OS
ever written.

  So, to kick things alongs, someone, please, define the following:

		OS

		LLL

		HLL

  and their relationships.

  -spc (Who's not holding his breath)