At 10:08 PM +0100 1/24/02, Juergen Boemmels wrote:
>Simon Cozens <[EMAIL PROTECTED]> writes:
>
>> > 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.
>>
>> In this case, I'd prefer you trusted the documentation. :)
>
>Which one parrot_assembly.pod or core_ops.pod? They are both in docs
>dir and state diffrent things. I selected the first one.
parrot_assembly.pod, though in this case it was a little unclear.
Just because you don't have to specify key structures at the assembly
level doesn't mean they're not needed at the bytecode level.
> > > Anyway, I think a PMC-valued get/set-element method is necessary.
>>
>> Yes. Basically all the vtable methods would get an equivalent whereby
>> each parameter is followed by a key of type KEY*.
>
>KEY*? Isn't this just an array of all possible keys?
Nope. Aggregates, which is any variable that holds multiple values,
have individual values specified by key. (Which is different from a
hash key, so it's an unfortunate choice of term)
> > > * Use special operation names for the indirect operations like
>> > get_indirect and indirect_set and use the signature p_p_i for both
>>
>> I guess this.
>
>you mean like this:
>
>inline op indirect_set (out PMC, in PMC, in INT) {
> KEY *key = $1->cache.struct_val;
> KEY_PAIR *key_pair = key_element_i (key, $3);
> $1->vtable->set_pmc_key ($1, $2, key_pair);
>}
>
>Or will the key system completely reengeniered?
Completely reengineered.
> > > * Use special assmbly-constructs for the optional key like
>> > set PO[I1], P1 or P0;I1, P1
>>
>> How we disguise this in the assembler isn't really relevant.
>
>Why not. The problem is how can the assembler know which vtable method
>is to call.
There's only one method for keyed access. The current implementation
is in error, based on incomplete information I gave. (That's the
trouble with some of this stuff--just because I have it all in my
head doesn't mean I get it all *out* of my head to other people...)
All keyed access is via a function of the form:
some_func(PMC *, key *, PMC *, key *, PMC *, key *);
and the assembly is of the form:
opcode dest[key], source1[key], source2[key]
The keys may be left off if they aren't needed, in which case a NULL
is substituted. So this:
add P2, P1[2], P3
is just shorthand for
add P2[NULL], P1[2], P3[NULL]
In the square brackets you may have either an integer, a quoted
string, or a PMC register. All are unambiguous, so there's no issue
there.
S registers may hold key structures, so for non-constant keys they'll
be stuffed into S regs. We need to define assembly and opcodes to
manage keys--I think there's some stuff, but on later thought it
needs some rejigging.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
