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?
> =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?)
>
> Opcodes are all responsible for returning a pointer to the next opcode
> to execute. The interpreter can figure out the offset, but we
> won't--it's faster for the opcode functions to do the math. (No table
> lookups that way)
>
> =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?
>
> =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?
--
Bryan C. Warnock
[EMAIL PROTECTED]
