machine architecture (fwd)
Wed, 2 Nov 1994 18:46:14 -0800 (PST)
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,