Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>>All 64 combinations would be a horror.
> Indeed.
>>But I really vote for a predereferencing like solution.
> I didn't really understand that part of your previous message, but I
> don't see what relevance that has to how the assembler decides on the
> op name to use (and hence how to encode the arguments).
Predereferencing now generates changed bytecode on the fly by
1) putting the absolute address of operands into the opcode stream, so
2) e.g. set_i_ic and set_i_i have the same C-source, actually, since my
patch the former is omitted at all.
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 would allow all 64 variations of keyed ops w/o opcode bloat, if
I didn't ignore some essential part ;-)
LHS keys and autovivification, e.g. but this we don't have now either.
> Tom
leo
