In message <8fe9f5554b.tom@compton.compton.nu>
Tom Hughes <tom@compton.nu> wrote:
> I've been trying to make sense of the current status of keyed access
> at all levels, from the assembler through the ops to the vtables and
> it has to be said that the harder I look the more confused I seem to
> become...
Well that stimulated a detailed discussion. Not.
Let's try again shall we. This time I'm going to give up on trying to
make sense of the current mess and just suggest a scheme loosely based
on PDD 8 and see what people think.
The op name will be generated as normal with any keyed operand causing
an single extra argument to be introduced. If the key has more than one
component then this will be of type k but if the key has just a single
component then the key argument will have the usual encoding for an
argument of the key type, but with a k prefixed, so we get this encoding:
set P0[0], 1 --> set_p_kic_i
set P0[I0], 1 --> set_p_ki_i
set P0["A"], 1 --> set_p_ksc_i
set P0[S0], 1 --> set_p_ks_i
set P0[0;1], 1 --> set_p_k_i
set P0[0], P1[S1] --> set_p_kic_p_ks
Arguments of type kic, ki, ksc, ks, etc are encoded in the bytecode
in the normal way while those of type k are encoded as a new type of
constant using an encoding similar to that given in PDD 8.
Questions that I would like people to consider:
1) Is this a reasonable way to do it?
2) Should we just have k arguments and encode even single
items keys in the constant table - this would reduce the
amount of op duplication?
3) Is the answer 42?
4) Am I talking to myself here?
Tom
--
Tom Hughes (tom@compton.nu)
http://www.compton.nu/
Thread Previous
|
Thread Next