Tunes

[Patrick Premont]

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

"Our" '(add ...) is a syntax just as what you wrote "mov ...". Note that
we do have some higer-level functions but they generate stuff exactly
like what you wrote except for irrelevent details. What you wrote is
not executable just as what we generate is not executable. It is
assembly language. We just have a syntax which is easier to manipulate.
What we need is an assembler to generate executable code with it.
We are not expecting any magic.

But my point was to say that choosing specific registers was part of
the problem of choosing the machine representation or compiling the
LLL to machine code. I'm not saying it shouldn't be done. I'm just
asking if you agree with me that this is not defining the LLL but
implementing it. (To try to understand what we mean by LLL).

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

I meant programming in something like forth.

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

Well, the character-stream syntax is just trouble for the HLL which
tried to compile to it. So are modules/name-space. The compiler
already has unique identifiers. Only an abstact syntax is needed.

See below, how I would draw the system...

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

It has too much stuff for humans which only get in the way when trying
to compile to it.

>   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

Here how I see it :

      Forth---\
              V
      HLL -> INT -> MACHINE

Where INT is a possibly stack based, reasonably portable, intermediate
language. Forth is whatever language you want to write your
low/mid-level code in. Ideally, there would be no really distinct
"Forth" but a subset of the HLL could be used to program at a
low-level. When you start to write code in Forth, you will start to
want more and more complex stuff. You will long for higher-level
constructs and either suffer or duplicate work in the HLL.

I avoided showing where the LLL is. It can be many things. It can be
"Forth", "INT" or even the mapping towards MACHINE.

"Forth" is completely irrelevent to the HLL. It is just a nice
human interface to the low-level INT. You can add a lot of hot stuff
(scopes...) in there but you should realize that it will only be used
by humans which wish to write some low-level code.  The HLL just wants
to talk to INT. If "Forth" could accomplish its human-interface-to-INT
goal by using some HLL constructs, we'd save work and have a nice
integrated system. If you did happen to want more HL constructs that
you expected and "Forth" is only part of "HLL", you could just use
a few more HLL constructs. Now I'm not sure how to do this.
But at least the general strucutre should be as I outlined above.

If LLL is too abiguous, let's talk in terms of the above model, if
you agree with it.

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

Yeah, you are right for traditional terminology. But when I say HLL in
TUNES I mean to include the OS. I see the HLL as incorporating all
the OS stuff.

>   An OS is written in some language (or languages).  It's NOT the language. 

The OS is not the HLL because it is written in it; it is the HLL
because it is part of the HLL, a part with boundaries which are not
well defined.  Hence we won't talk about what is the OS and what
isn't, we'll just make everthing available in the HLL. Just as I don't
care when I code in C++ wheter the library I'm using comes with the OS
or not, I know its going to be painful either way :) We want it to be
enjoyable either way in Tunes. Having many HL languages would make
an ideal integration impossible. You end up with an object model in
the OS and a different one in the language (or no object model in the
OS at all).

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

Scheme lexical scoping is already defined. You could already use that.
But what I'd like it to unify "Forth" with a subset of the "HLL" (as
defined in my graph above). The HLL will proably have lexical scoping
like Scheme (like Dylan, ... lexical scoping is standard). It is not
difficult to implement. Since it will have to be in the HLL, IF you
can manage to use a HLL subset, you might as well not rethink and
reimplement a new scoping system in yet another language ("Forth") (in
which you will eventually want to have a lot of power already
available in the HLL).

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

Because that's a fundemental caracteristic of the project. To have
ideal OS/Language integration by not having an OS/Language
distinciton. Unless your multiple languages are all semantically very
similar, there will be mismatches in the interaction with the OS which
will eliminate a very important advantage of Tunes. The support for
other languages will be acheived "on top" of the HLL somehow. I'd
rather not get into that again now. I'm tired.

Oh but I did not exactly answer your question. I said why we should
have a comined OS/language. You ask why the OS should be written all
in the same language. (I Think) Well it doesn't have to be written in
only one language. In some sense it is not. At least part of the HLL
run-time won't be written in HLL (at first). There will be some LL
code written directly.

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

parts of the HLL which you shouldn't try do identify too precisely

> 		LLL

I don't know. I've suggested a model. If you want to call some part of
it the LLL go ahead. But I'm affraid it won't be an obvious choice and
will lead to more confusion unless it is precisely defined within a
model such as I have outlined.

> 		HLL

Everything will be available from there. This is all of Tunes except
implementaion details. It is the general interface to the system.
I'd say programmer interface but I don't want to overstate the
difference between the user and the programmer. The "user" interface
will probably be a specialisation of it, that doesn't required as much
thinking to "use/program".

>   and their relationships.
> 
>   -spc (Who's not holding his breath)

I hope I clarified the situation. Is it the case ?

Did I contradict other's views on how it should be ?

Patrick