Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
>
> > Have a small number of _real_ core.ops which have fixed assigned
> > numbers below say 256.
>
> The problem with this approach is the JIT/EXEC subsystem. Dynamically
> loaded oplibs and JIT don't play together. To make this work, it would
> need probably a total rewrite of JIT code.
I'm really no expert in the JIT system. But from my last step-thru
session in the debugger I remeber that build_asm calls out to a
function based on the opcode. Ah, here:
(op_func[cur_opcode_byte].fn) (jit_info, interpreter);
At build_asm time the oplib must already be loaded. The oplib must
then have funcions for JIT-emitting the code, otherwise it should just
emit calls to the slow core functions.
This means that the author of an oplib must also include a
JIT-emitting table (for all supported platforms). This raises the
level for writing oplibs, but the worst case is that the new oplib
under jit is as slow as the function-core (All ops call
functions). Ideally the JIT-emitting functions could be mechanically
created out of the *.ops files.
> The switched core has some overhead too, you can't expand a switch
> statement like the other table based opcode dispatches.
Thats definitly a problem.
But this can be solved by first finding out to which oplib a code
belongs (This can be done really fast by using bisection or something
similar). Then call the right switch function and stay in this
function as long as you are in this oplib.
Pseudocode:
while (next_op) {
if (op < base || op > base+num_ops) return
switch (op-base) {
...
}
}
As oplib-switches are slow it might be a good idea to include the core
ops to the switch function, so the core is always dispatched fast.
> > Comments
> > boe
>
> leo
>
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
