At 11:45 PM 6/14/2001 -0400, Bryan C. Warnock wrote:
>A couple questions, if I may?
>
>On Thursday 14 June 2001 05:57 pm, Dan Sugalski wrote:
> > =item state stack
> >
> > For the interpreter's internal state
>
>Does this include the call stack? If it does, should it?
Might, and I'm not sure.
Keeping the call stack as a real stack is useful, straightforward, and
familiar. If we get cleverer (and that's always a dangerous thing) we can
leverage the segmented stack architecture to implement continuations. I'm
not sure if we want to do that or not, though.
If we do continuations then the call stack gets a bit more complex.
> > =head1 Opcodes
> >
> > Opcodes are all dispatched indirectly via an opcode function
> > table. Each segment of bytecode (a segment roughly corresponding to a
> > compilation unit--a precompiled module would be in its own segment,
> > for example) has its own opcode function table.
>
>Although I suspect that this is the best way to go (as it will almost always
>save an extra level of indirection), will having n number of function tables
>interfere with potentially hot functions? (IOW, would having five different
>memory lookups, dereferenced to a single function pointer, introduce
>pipeline or cache problems that a single memory lookup dereferenced to the
>one pointer?)
Generally speaking, it will have a performance penalty as you have to load
a fresh page into the cache. You'll only pay that on entry to the code that
lexically maps in the altered opcode table. That should happen only on
entry to a subroutine in the code section. We can see about making the
subroutine entry point opcode be several so we only assign the pointer if
we're jumping in from outside the code unit. Something like:
my_sub:
set_optable local_unit(table)
my_sub$:
clean_registers
so in-unit calls jump to my_sub$ instead of my_sub. Or something like that.
> > =head1 The opcode loop
> >
> > This is a tight loop. All it does is call an opcode function, get back
> > a pointer to the next opcode to execute, and check the event dispatch
> > flag. Lather, rinse, repeat ad infinitum.
>
>And if the flag is set? Is the loop responsible for saving state before you
>jump, or will you be jumping to an opcode that saves the state? When you
>return (assuming you return) from wherever the event took you, do you
>recheck the flag, or process the next op? If you recheck it, will you run
>the events dry before operating on the next opcode, or are you going to have
>some fancy scheduler in place?
While I'm sort of putting this off until later, I'm thinking we'll call
into a perl sub to handle the event. Whether that sub blocks events or not
is up in the air. I can see it going either way. The event handling sub
will *probably* block other events, but we might want to put some sort of
levels on importance. (I suppose if we're building a software CPU, we might
as well have interrupt priorities... :)
> > =head1 Bytecode
> >
> > Bytecode is both the on-disk representation of a perl program and the
> > in-memory representation of a perl program.
> >
> > The bytecode comes in three sections. The fixup and constants sections
> > have absolute machine addresses in them (after the loader is finished
> > with them) while the opcode section has none. This will allow us to
> > mmap precompiled code and share at least some of it amongst multiple
> > processes.
> >
>
>I assume from this description, then, that there's really (3 x number of
>compilation units) segments?
More or less, though what a compilation unit is might vary. If you want to
freeze the current code state of everything (to make sure your compiled
program has all its modules handy, for example, or to give more code to the
optimizer to chew on) Your program might have a single set, or you might
have one per module, or module set, or something like that.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
