LLL subproject

[Brian T Rice]

Concerning your time constraints, I invite anyone else with an interested
opinion on the topic to join in. Massimo's MetaKit-style suggestion to me
last month is certainly still in my mind as a possibility, for example.

On Mon, 3 Feb 2003, Dan Moniz wrote:

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

That's fine. Something specific to that was what I was looking for.

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

Good so far.

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

Yes, Common Lisp is looking like a more attractive target, with more
software, particularly (for me) the implementation of Maude's sibling,
CafeOBJ (http://cliki.tunes.org/CafeOBJ), but also for the read-level
reflection, and obviously Maude's syntax, while totally reconfigurable, is
a pain up-front. Generally my use of CafeOBJ would be as a library to
learn from, rather than a direct usage. It's non-Free as such, free for
R&D usage basically, so we can build what we like based on having seen
its sources, but not re-use them directly; from a cursory look, I
wouldn't directly re-use its functions anyway.

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

Yes, although ideally even the class of architecture should not matter too
much to this LLL abstraction layer; alternatively, you might say that we
need LLL to be open, so that the evaluators could dig into whatever levels
are needed.

For example, I'm fairly sure that there's no object heap system with
automatied memory-management that is instantly portable across
architectures with different word-size. Does anyone know of some system or
evidence against this?

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

Your confusion is perfectly fine, because we haven't specified any of
that. Both the mention of Scheme and C are very tentative; actually, the
more I read them, the more ridiculous they appear. I should basically just
say "HLL" for "Scheme (or later our own HLL)". I'm surprised you didn't
gasp at seeing the word "meta-source"... it's such a vague word.

One problem with the LLL documentation is that there's a gap between what
the HLL specifies, which are basically language and semantics components
and some standard library issues like ways to arrange objects in terms of
data structures, and the LLL which provides some basic architectural
abstractions as a back-end, and not much in-between.

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

Well, garbage-collection *policies* are high-level; there's a paper on the
application of rewriting logic to describe all major families of
memory-management policy (not worked out to complete detail due to lack of
funding of course). However, the mechanisms to implement the policy
interact strongly with the low-level details like bit-encoding, etc.

I can see, however, that the GC can abstract over most things except for
what happens to the memory-abstraction between the hardware and "10^20 -
9^57" style expressions that a memory manager (and compiler and scheduler)
would have to fiddle with. This may be the decision point where the GC
topic must be moved to the Migration topic instead of the situation now
where the Migration documentation merely provides lip-service to the idea
that Migration encompasses GC.

At the same time, that just shifts the documentation burden rather than
solves it.

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

Sure, that's fine.

> Congratulations on the new site launch!

Thanks, although I'm still working out the CLiki bugs. :)

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/