Dan Sugalski wrote:
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:The big problem with this is you're increasing non-local call performance for normal running. I don't think this is a good idea--while you'll save maybe 50 cycles for each non-local call, you're making each opcode pay another four or five cycles, perhaps a bit more on the more register-starved architectures if the extra interpreter structure element fetching causes a register to get stack flushed.Changing the addressing scheme to opcode offsets relative to code
Yep. But first, we don't really know yet, how many local/non-local calls we have in real world programs and the "some cycles per normal op" impact is not for Prederef, JIT and compiled C. The latter 2 are in magnitudes faster then the slower/normal kinds of run loops - in tight loops or runloop based tests.
Anyway, I was able to fix most of compiled C code quirks, where
this RfD eminated from.
- invoke
- bsr/jsr + ret
always work on offsets now. The latter was necessary because PASM subs called via set_addr/invoke/ret did work differently to bsr/ret in compiled C code.
So it might be only necessary to clearly define which branches need a run-loop based PC (whatever this might be) and which ops take a offset in terms of opcode_t from code_start. The macros in core.ops should somehow reflect this behaviour - currently I have changed these to CUR_OPCODE + $x, which is always the offset (todays 3 commits)
leo
