David M. Lloyd wrote:
> Take it from me (the one with several abortive attempts at getting an
> extra compare stuck in Perl 5's dispatch loop): You don't want to stick
> another compare in there. It *kills* performance.
Kills? I thought the event flag test dropped performance by a few
percent. We can piggy-back off the event flag test, so I'm not
adding another test, just re-using one that's (already?) there.
Keep in mind that if dispatcher performance drops by a few percent,
we might be able to make it up simply due to reduced instruction
counts. Anybody know what the enter/exit scope percentage is?
IMHO the goal for a software CPU is low instruction counts, not
high MIPS. High MIPS means you're chewing up cache with an opcode
stream instead of useful data.
> You'd want to use scope enter and leave opcodes instead. Much faster.
I'm not sure. It's a different architecture with many different
optimization possibilities. It would certainly make the compiler
a lot easier to build. No more weird restrictions on gotos. A
"call ADDRESS" just stuffs the return address in a register and
jumps. Nested subs fall out for free. Tail-calls are just "goto
ADDRESS" because there isn't any prologue. Seems like a lot of
stuff gets a lot easier if you can treat frames declaratively.
One last thing to consider. If the run-time dynamic lexical
insertion stuff comes about, then we'll have to insert scope
enter/exit opcodes in every scope. There are going to be a
lot of empty scopes around. If the run-time is able to
dynamically change the scope tag on an instruction, then we
don't have to generate those empty scopes. The debugger could
actually be built on dynamic scopes -- when you want to set
a break point, you just change the scope tag on the instruction
you want to break and insert a lexical with a DESTROY sub
that halts the VM. Full-speed execution with breaks enabled.
If the VM supports it, dynamic scoping games could be a lot
of fun. I'm starting to come around to Damian's point of view...
- Ken
