LLL stack questions

[Mike Prince]

On Wed, 21 Dec 1994, Raul Deluth Miller wrote:
> The critical issue here is automatically generated code.  If we don't
> provide a decent mechanism for porting existing softwar, we'll never
> get off the ground.  That means we need to do something decent for a C
> compiler, and we need to deal with automatically generated C code
> (which is the way a lot of compilers and tools are implemented
> nowadays).

I know how to poorly implement C under our scheme; stuff the whole 
program into one obese cell.  But that solution is unacceptable.  I don't 
know how well we can mix creating a forward looking language (designed 
for a distributed environment) with a language that says "I must be able 
to see everything as if it were a flat address space and directly 
accessable to me".  I think DSM is really motivated by people (I hope I'm not
offending too many) that are stuck in a flat model.

> Currently, I'm thinking of treating the "cell stack" as a register
> set, and providing the illusion of a flat adress space using some sort
> of "annotated pointer" (which denotes the memory array as well as a
> virtual offset) -- I don't know if we can do better than this for
> arbitrarily large data objects without hurting performance for smaller
> objects or objects of "known size".

The model I'm currently working with has an upwards bound of 2^31 for 
data objects.  You have a nice big flat address space if you want it.  It 
would probably cripple the system you were using it on though, unless it 
had VM, something I'm staying away from.

> Remember, Ccode frequently manipulates pointers to "anonymous data" orr
> "anonymous code".

In my version of the LLL pointers can be manipulated to the point they 
are invalid, in which case they return garbage or would not work at all.  
Because cells are isolated from one another the only one hurt is the 
offending pointer mangler.

> I'm not sure how to treat arbitrarily large code objects (e.g. PERL's
> yacc parser).

If your talking backwards compatability, it more likely than not will be 
an obese cell.  For new software, it can be written properly factored (in 
our language of course).  As for developing compilers for arbitrary 
languages, it'll depend on the architecture of the language and the 
"smarts" of its compiler.  This is a vague answer, I know.

What I'd really like to see is our system fall into several markets;

1.  Provide telescript like abilities across the internet.
	Put a "server" deamon on each computer that intercepts e-mail encoded
	with LLL "messages".  This is going to be VERY easy to do.  This 
	should attract wide-spread attention.  This is an example of layering
	our OS on top of other systems.

2.  Cheap homegrown supercomputers.
	I'd like to port our OS to the IBM-PC family first (mostly 
	because that's what I have) and locate a manufacturer of inexpensive
	parallel processing cards (MuP21ish in cost).  Create a basic
	but useful programming environment for our HLL that'll let users
	play with fast number crunching.  We could be the Toaster people 
	of the 90's!

If we could penetrate those, then the issue of backwards language 
compatability diminishes, and we could stand on our own.  That's what I'd 
really like.  Eventually we could move into the big distributed market, 
databases and networking.  But those are less "glamorous" and I'd like to 
work on something fun.

Mike