In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> For _keyed operands I would propose:
>
> The used keys are not coded into the opcode name (so no 64 variations),
> but the opcode-number holds this information.
>
> add_p_p_p (op #297)
> app_p_k_p_p => #297 + (KEY1_FLAGS << 16)
> add_p_p_k_p => #297 + (KEY2_FLAGS << 16)
> ...
> where KEY1_FLAGS are e.g.
> _k 0b0001
> _ki 0b0011
> _kic 0b0111
> _kc 0b0101
> KEY2_FLAGS same << 3 ...
>
> Now the current run loop look's like this:
> while (pc) {
> DO_OP(pc, interpreter);
> }
>
> #define DO_OP(PC,INTERP) (PC = (INTERP->op_func_table)[*PC])(PC,INTERP))
>
> I would change the run loop like so:
>
> while (pc) {
> argp1 = ...pmc_reg.registers[cur_opcode[1]];
> if (*pc & KEY1_MASK) {
> key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
> argp1 = get_keyed_entry(argp1, key1, flags);
> }
> ...
> PC = (INTERP->op_func_table)[*PC & KEY_MASK]( ... );
> PC += n_keys; /* account for additonal keys in bytecode */
> }
>
> which would call add_p_p_p(argp1, argp2, argp3).
>
> "argp" points either directly to the PMC register, or for keys, into
> the bucket, where the PMC is stored in the aggregate. Of course, argp
> shouldn't move due to GC while processing one op.
This may be all fine and dandy for the prederef case but it's going to
force the opcode functions to do a lot more work working out where to
get the key from in all the other cases.
It also prevents you using the optimised _int vtable methods for keyed
access using integer keys...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
