Just some initial thoughts

[David E. Manifold]

On Sat, 6 Dec 1997, Fare Rideau wrote:
> >: Maneesh

> > I have a little piece of 80386 asm, for a parallel processing safe
> > linked list add item/remove item primitive, that (I think) is pretty
> > efficient.  I've always wanted to get it checked out to make sure the
> > algorithm works and opinions on it, now it wasn't brain surgery, but I
> > did derive it myself, but unfortunaltey I couldn't test it (I have but a
> > single CPU).
> The problem I see with parallel processing is that most code could/should
> be broken in modules that interact as little as possible one with the others.
> Current compiler technology priviledges monolithic program design.
> I'd like to promote modular design, with a higher-order concurrent model
> (see "actor" based designs). It would be the task of the back-end
> optimizers to "merge" conceptually fine-grained objects that are tightly
> interacting into a set of efficient monolithic processes (one per processor).
> This allows for a cleaner design, with replaceable components,
> and better scalability to a wide variety of platforms.

The implementation of Tunes on a system IS "merging conceptually
fine-grained objects that are tightly interacting..." onto a single
processor, to start with.  But in your multitasking model you meant the
system would be automatically insert Pause instructions in the code before
the code was run.  I extended this and I see the low-level model as
dynamically translating high-level objects into machine-specific
representation as it goes along.  In this model the LLL is simply the set
of translations that specify how to migrate objects (as well as function
combinations) onto a specific low-level computing system.  If this is all
the LLL is, we don't have to program it at all. 

> To sum up: parallelism should be deep inside the programming model;
> and efficiency would be granted through meta-programming.
> Let this long-term opinion not prevent anyone from coding.
> 
> 
> > I have some suggestion as for the use/disuse of selectors, TSS's,
> > privlege levels and the like for an Intel specific implimentation.  Are
> > we ready to discuss such things, or are we already past that?
> Yes, we're ready to discuss it, on the tunes-lll mailing list.

These things should be discussed, and they should be discussed to the goal
of specifying the entire low-level working of the processor--in precise,
high-level terms.

At the same time, we can work on specifying how high-level objects will be
migrated onto the processor specification.

Bootstrapping the system consists of a single, manual (but tool-assisted) 
iteration of these migration constraints. 

In other words: Writing a LLL in current system terms (Forth and Asm) is
unproductive!  Working Tunes from the bottom up will be disastrous, for
the same reasons current systems have been disastrous.  We should work in
high-level terms from the beginning. 

> Regards, 
> -- #f 
No offense (and sorry if these objections have already been raised and
answered),

David E. Manifold
tril@bespin.ml.org