On Saturday 06 October 2001 07:43 pm, Gregor N. Purdy wrote:
> The Crystalizing Loader proposal I just made would work better if the
> addresses to the current registers were always the same and pushing
> regs onto stacks made copies, rather than having the current reg file
> be the new set of regs.
And now that you mention it, that may be how the register stack is handled.
Let's take a look... Nope, it's handled like a regular stack.
Of course, for hardware registers, that isn't so. You do copy the registers
onto a stack, but you still reference the registers. But that's more of a
function of hardware (where registers are different from memory) than
software (where memory is the same as memory). However, to
always refer to the base set of registers, and to push and pop copies of
those registers onto a stack.... that intrigues me. (Depends on how much we
push and pull, I guess. But you did bring up one thing - you don't get a
copy of the registers when you push. That makes it nigh impossible to pass
values in the registers when you need to save the registers off. Dan?)
But before we going jumping the gun, let's see what straight registers do.
{dum de dum de dum...} Runs about the same for me. (A shade slower on
Linux.)
> I'm interested to know if there's a way to turn the op funcs into chunks
> of code that longjmp around (or something equivalent) so we can get rid of
> function call overhead for simple ops (complex ops could consist primarily
> of a function call internally).
But argument passing? In theory, you'd just be coding by hand what the
platform's calling semantics already provide you. (More or less.)
>
> In this case, the crystalizing loader puts the address to jump to in place
> of the opcode, and opcodes jump to the location in the next opcode field
> when they are done, and the 'end' opcode is replaced by a well-known
> location that terminates the runops core.
Saving the dereference of the opcode type. Yes, I'm reserving judgement on
this (whilst I ponder it.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
