Tunes

[Nathan Hawkins]

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

Yes, that's part of what I'm trying to deal with.

[what is LLL?]
>   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."  

Neither is s-exp...

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

Also, a question of who's going to do what. Do the people objecting 
propose to write everything in HLL? No, that's why there's an LLL, which 
must have a certain amount of functionality. I happen to want to do some 
other things with the LLL, possibly unrelated to the Tunes project, and 
for that, I need to have a usable language.

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

Not for me! LLL->cpu code, plus environment.

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

Good question. I don't really think C -> HLL will ever work, but that's 
not _my_ project. :-)

[process/thread model?]
> > 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).

I'm expecting that LLL, or at least what I'm writing ( ;-), will have the 
task of containing the lowest level OS code, as well, so I would need to 
know how much of the context switching will be dealt with at higher 
levels, and what model will work the best for the LLL.

[lexical scoping in LLL]
> > 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.

I've been operating under the assumption that the LLL would be both the 
bottom level language and environment, and most/all of the CPU specific 
parts of the OS, with decision making being concentrated in the HLL. The 
HLL would (eventually) become a superset of LLL, with the LLL mechanisms 
(such as the hypothetical vocabularies) being used by the HLL to build 
the higher level things.

At least, that's what I was thinking.

*utsl*