LLL subproject

[Dan Moniz]

At 03:36 PM 1/26/2003 -0800, Brian T Rice wrote:

>Thanks, Dan, for bothering with this. It's not really my cup-of-tea to
>discuss systems-level stuff. Anyway...

No problem. I'm happy to help in whatever way I can. My time is pretty 
limited these days though, so please don't expect timely responses. I 
apologize up front for this, but until I complete more of my long-standing 
projects, and until my daily life can accommodate it, I'm drastically 
reducing the amount of time I allot to efforts outside that scope.

>The LLL project area is intended to cover both the initial implementation
>of the HLL as well as the subsequent bootstrap and eventually all
>low-level code within Tunes.
>
>I have been adjusting Fare's notes on this at http://tunes.org/new/LLL/

Just to be clear, I'm only commenting on what's found at that URL, and 
related topics.

>Generally, it should not be viewed as a language, but a set of utilities
>which in combination are very expressive. Once bootstrapped, the LLL would
>be somewhat similar to how I envision the HLL meta-architecture and its
>instances: there are a set of components which work together to provide a
>whole system that we think of as a "language". In the case of the LLL,
>there would be object types which deal with object-identification spaces,
>memory-management, code-generation, scheduling, device-drivers, and
>low-level implementation modules and encoding systems. These would be
>composed into a run-time-system instance, which may have several
>components in the same category running side-by-side.

Here's how I think of this. It's probably wrong.

The HLL is a set of semantics and a computable expression of those 
semantics (i.e. a programming language) with which the TUNES system is 
constructed.

The LLL is a set of semantics and a computable expression of those 
semantics (i.e. a programming language) which the HLL manipulates to get 
things done with the hardware layer (I'm obscuring the i386 and O'TOP 
abstractions underneath the LLL, which I have not studied).

>With that frame in mind, we need to develop a clear outline on the website
>that allows us to put together a code framework that does what we need.
>However, for the initial implementation of the HLL, any system is really
>allowed, although Common Lisp and Maude are my top choices. Also, a
>predecessor of Maude was written in CL, and may also be a good choice to
>implement with.

I'm not really familiar with Maude beyond a few papers I've read on it, so 
I'm not going to comment on it. I know you've been working with it some time.

Common Lisp may be a nice choice, but you'll have to write a Common Lisp 
that melds well with the LLL. If you're willing to do that, then great -- 
it's a pretty big project. I certainly think you'll have better adoption 
with Common Lisp over Maude, but I could be wrong. I would strongly suggest 
staying away from writing your own language for the purposes of either the 
LLL or HLL if at all possible. This warning can be ignored (to some extent) 
if you implement a language inside a suitable host language, as is commonly 
done with Common Lisp, Scheme, ML, etc. Maude may also apply.

>So, what are your first thoughts?

The LLL page mentions starting with the words of ANS Forth, except those 
related to I/O, parsing, and definition. This (by itself) creates a sort of 
virtual instruction set or p-code, analagous to a virtual machine. If the 
i386 and O'TOP layers sit underneath this LLL, and the HLL manipulates LLL 
objects (compiles down to LLL -- LLL code generation), then you have a nice 
isolation between the actual hardware interface layers and everything else, 
at what would seem to be a higher level than say x86 assembly. Forth has 
certainly been used in this space for a long time (Forth-on-a-chip, Forth 
as Chuck Moore would have it, etc.)

In general, I'm confused about the actual execution of the various stages, 
but this might just be due to lack of information about the rest of the 
project in general. I don't see anything that says something along the 
lines of "we're going to write this abstraction layer in X to get Y, which 
has the semantics of ANS Forth minus these bits. Then, we're going to build 
the HLL using Z which interfaces with Y". There is a mention of using 
Scheme to generate assembly and using C as a portable assembler. Does that 
mean you're going to be writing x86 assembly? Wouldn't that be at the x86 
level? Shouldn't you be using Scheme to generate the LLL? I don't know, 
it's not clear.

There's a number of issues mentioned dealing with relatively high-level 
concepts that are to some degree hardware dependent, like garbage 
collection. I think those could probably be dealt with elsewhere. Low level 
to me means things like bit-order, instruction set, chip architecture, 
execution, memory esoterica, etc.

Replies welcome, especially on places where I've grossly misunderstood 
something. I'll keep active on this thread as much as possible, keeping all 
other TUNES traffic under the caveat mentioned at the beginning of this email.

Congratulations on the new site launch!


-- 
Dan Moniz <dnm@pobox.com> [http://www.pobox.com/~dnm/]