Simon Cozens <[EMAIL PROTECTED]> writes:
> > To implement nested pairs its nessary to introduce 2 new vtable functions
> > and the acompaning core.ops to get and set the PMC value of the indexed
> > element. I choosed set_p_p_i and set_p_i_p. The later one is inconsistent
> > with indexed set operations set_p_i_i, set_p_n_i and set_p_s_i.
>
> This isn't how we're doing indexing. Unfortunately, I'm still trying to
> catch up on how we are doing indexing. There should certainly be indexed
> versions of many of the PMC vtable entries, but I can't remember what
> form this index would take. IIRC, it should be a KEY* structure, but I
> may not RC. Anyone know where we got to?
I thought this was the problem. My notation was inspired by the
parrot_assembly.pod which states:
=head1 IMPLEMENTATION
Parrot opcodes take the format of:
code destination, dest_key, source1, source1_key, source2, source2_key
[...]
The key parameters are optional, and may be either an integer or a
string. [...] Any time a source or destination can be a PMC register,
there may be a key.
According to this document the set_p_n_i notation would be wrong. But
I already heard that the index-system is a moving target.
Anyway, I think a PMC-valued get/set-element method is necessary. So
the question is how do they map to assembly-operations. Several possible
solution come to my mind:
* Use special operation names for the indirect operations like
get_indirect and indirect_set and use the signature p_p_i for both
* Use the set-operation and distinguisch the diffrent use-cases in the
order of the types: p_i_p vs. p_p_i.
But what if we want to use PMCs as index? p_p_p? What does that mean.
* Use special assmbly-constructs for the optional key like
set PO[I1], P1 or P0;I1, P1
* Introduce a new register-type for Keys.
I've no idea which is the best way to go. The Pair-Implementation just
needs one way to get a PMC-value of an (constant) index.
I will delay my patch until this issue is solved
Jürgen.
