Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
>>op dest[dkey], src1[skey1], src2[skey2]
>>
>>e.g.
>>
>>add P0[P1], P2, P3[P4]
> There was however some discussion as to whether we wanted to limit
> keyed access to just the set/assign opcodes in order to avoid the
> explosion of ops that would occur if we supported keyed access
> directly on every op.
The first question is, does a HL need such operations? Or better,
does/will it produce such operations?
E.g. @a[$i] = $j + @b[$k] + 1 produces a sequence of PerlUndef's to hold
the intermediate operands of Binop('+'). Of course clever code
generation or an optimizer could take advantage of these _keyed operations.
If we really want _keyed operations for all ops (and even when not) I
would flag the _keyed ops and preprocess them in the run loop:
- op and op_keyed have the same (opcode & OP_FLAG_MASK)
if (op & OP_KEY1_FLAG)
arg1p = get_entry(arg1,key)
else
arg1p = P(arg1)
...
DO_OP(op & OP_FLAG_MASK, argp1...)
if (op & OP_KEY1_FLAG)
store_entry...
Very similar to predereferencing.
Actually, it could prederefernce all operands.
This would save a lot of opcodes and provide a smaller and more compact
core. Predereferncing is faster then other runmodes.
>>2) What PASM ops should above statement generate:
>>a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ )
>>b) add_p_k_p_k_p_k
>> if b) how to create a NULL key and how does it look like in PBC?
>>
>
> As things stand it would have to be option a, or at least that is what
> the current assembler would generate. There isn't much else it can do
> really - how would it know when to generate a null key for an operand
> and when not to?
If there is a plain P0 without [], the assembler hat to insert a NULL
key instead.
> I believe you could encode a key constant with zero components in the
> byte code if you wanted - the first word of the constant is the
> component count after all.
Yes, that seems to be working.
> Tom
leo
