LLL stack questions

[Mike Prince]

Here's my newest hierarchy;

Locale (one CPU + some memory)
	Cell (code + data, see below)
		Method (the cell's code)
		Data (data only visible to cell)

An agent is still the execution primitive, having

Agent
	Stack (our working stack)
	Path (all the return addresses)
	*Method (this points to the method being executed)
	Data (data only visible to agent)

NOTE: Data is actually an index pointing to multiple memory blocks.  A 
memory block is accessed through an element number of the cell or agents 
index.

On Mon, 19 Dec 1994, Chris Harris wrote:

>     Do we support a fixed number of stacks (as in Forth), or as many 
> as the programmer wishes?
>     I'd tend to go with as many stacks as are necesary.  This raises the 
> question of how they are identified (number and/or name?), but this isn't 
> too difficult of a question.

I say only have one active "data" stack, but also have access to many 
data blocks.  At any time you can make any block your stack.

I'm for grouping code and data into units called Cells.  Each cell has an 
index (see above).  To access a data block you simply provide its offset 
into the index (an element number).

To make it more user friendly just have your favorite compiler alias the 
number with a name (they all boil down to numbers anyway, right?)  Or 
maybe your compiler will manage them enough that you never see them as 
parts of an index.

>     What data types should we support on our stacks?
>     This is currently being given enough attention, imho, and I'm yet to 
> formulate an opinion.
> 
>     Are all elements in a stack the same size, or do the instructions 
> specify what size their operands are?
>     The latter would be harder to impliment and possibly to program for, 
> but it might be more powerful.  (keyword: might)

Elements on the stack only occupy as much space as needed (chars get 8 
bits, floats 64, etc)  I think it will be marginally harder to 
implement.  Harder to program for at the low-level, but most of the time 
we'll be buffered by a medium or high-level language, and to them it 
doesn't matter.  I do think it would be more powerful.

>     Do we allow access to a stack only by pushing and popping, or do we
> permit accessing them at any point needed?

Absolutely for both ways.

>     Do the primitive operations (add, subtract, swap, etc.) require their 
> operands to be on or near the top of a stack (like Forth), or can they
> access anywhere inside the stack?

I'd say they have to be at the top of the stack, addressing is implicit.

>     Should we allow recursive stacks?  (Should we allow stacks to enclose 
> stacks to enclose stacks to enclose stacks, etc.?)

I'm against this because I don't see an efficient way of managing our 
resources while allowing this sort of complexity (please don't flame me 
for this, a little thing like recusrion can create a big set of 
headaches, just tell me how you'd solve it =)

NOTE: I'm not against a HLL compiler building those out of our 
primitives, just that we wouldn't support them in the LLL.

>     While this might be more difficult to support than single-level 
> stacks, it might make things easier and/or more efficient in the long 
> run.  Recursive stacks would allow us to break a problem down in a 
> fairly logical way, without having quite as much overhead on the next 
> level up.  (If I have a data structure that is represented as an enclosed 
> stack, the enclosing stack can look at it as one unit, rather than a 
> number of seperate elements.)

I'm scared of having to parse through a stack hierarchy to resolve simple 
memory references.

>     Should our primitive language provide VM for stacks?  (For example, 
> if a stack is larger than physical memory, the items near the bottom 
> could be paged to disk until required.)

I'm against this one too.  I have some blasphemous thoughts like dumping 
VM.  If our cells are fine grained enough we could swap them out, instead 
of adding another layer to our memory management.  We'd also be using 
just one algorithm for system optimization (least used stuff out!) and 
eliminating the necessity for file systems (view the hard disk as a slow big 
computer) or use a neighboring computer as a backing store.

>     Is code just a special type of stack, and thus agents can play with 
> the code they're able to execute?

Absolutely not.  Though they can build up some LLL code, and ask the 
kernel/linker to attempt to integrate it.

>     I'm also not clear as to how an agent/toolbox/program can communicate 
> with the outside world.  Is there a language primitive to communicate 
> with external objects, or is this accomplished only through shared stacks?

If you mean outside world as another cell on another computer, all you do 
is put some data in either the agent stack or one of it's data blocks and 
"call" the distant cell by name.  Your agent is transported to that cell 
and begins executing it's method.  That method now has the agents stack 
and data blocks within it's scope.  It might pull some data from the 
stack, steal some memory blocks from the index, and push some results, 
then issue a return.  Now the agent is back where it started, in your 
local cell.

> 
>     Any thoughts are welcome and appriciated....

Likewise.

I hope I don't sound too stuck in my ways.  I look forward to hearing 
other opinions on the above.

Mike