machine architecture (fwd)

[Mike Prince]

I'm breaking my own rule about not posting any more until we are 
organized, but this is my way of celebrating having just sent out my 
proposed organizational scheme.  On to the Reply...

On Mon, 31 Oct 1994, Raul Deluth Miller wrote:

> Mike Prince:
> . Each agent in itself is kind of a message.
> 
> Could you elaborate a bit on this point?
> 
> I take it that I can have a queue of agents (presumably processed by
> some other agent).

An agent is a slice of processor time.  The kernel handles creating, 
destroying, and scheduling them.  Is that too vague?

> Does this queue belong to the processing agent, or to the "tool box"?
> Can tool boxes send agents between each other?  Can they sends stacks?
> Tool boxes?

The queue is handled by the kernel.  An agent may traverse tool boxes.  
Each agent has a set of what I call stacks.  But all they are really are byte 
arrays.  These are local to the agent and travel with it; a tool box 
sends stacks by sending the agent that owns them to another tool box.  
Tool boxes do not move at the discretion of the tool box, or agents, the 
kernel will decide.  Probably (but what I'm trying to stay away from) is 
that we'll provide a hook into the kernel from above which will poke it 
and suggest a tool box migration.

> At what point does this sort of thing become expensive?  What should
> be cheap?

I'm trying to stay away from context switches.  We set up the registers 
for an agent (pointing to it's data stack, return stack, and the code 
it's executing.  A call is vectored by some special kernel code, and 
herein will lay our performance hit.  We can minimize this overhead to 
local calls (within a tool, which should be the majority) to simply a 3 
byte push onto the path stack, and jump absolute offset from the current 
code segment.  The return would again goto the kernel, pull the first 
byte off the path, then jump indirectly through an array of entry points to 
the code segment.  There are no context switches when going into the 
kernel.  I'm hoping (Blasphemy) that we don't have to protect it because 
all our code is secure.  I might be wrong.

It gets expensive when we start jumping between tool boxes, having to 
look up in some way the destination tool box.  I have thought about some 
optimizations, but am leery of adding even more complexity.  Have most 
external calls from a tool box registered (use one of the stacks 
keep a list).  Calls can be made by reference to this list (16 bit 
integer probably).  The kernel would protect this list, add it's own 
information (the physical address of the destination) and use it to 
quickly send the agent on it's way when local.  Obviously far references 
would still be relatively slow.  When the tool box is moved between 
machines the work space dependent values are cleared and teh next work 
space would have to re-vector the list.

There could be some advantages to this scheme.  The tool box, a priori, 
could provide expected tool box demands as part of the argument when listing 
external references.  Or the kernel could track usage and determine 
demands on the fly.

I think I've said enough for now,

Mike