Re: The reason for scads of keyed variants

[Dan Sugalski]

At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:

[ heavily snipped ]

 Now, for aggregates that hold PMCs ...
  ... and on JITted cores there's no
 win at all.

 For aggregates that *don't* hold PMCs, though, that's where the win
 is.

 If we don't have direct operations on aggregate elements but instead
 have to do a fetch and perform the operation on what we fetch, it
 means we have to create a temporary PMC for each 'fake' entry, one
 potentially with a fair amount of knowledge about how the aggregate
 works, which means that every aggregate will need to provide two
 vtables, one for itself and one for an aggregate entry.
I don't see the point here especially why we would need a temporary PMC.
If we have an array of packed ints, I just need a pointer to the element
to work on it. This is very similar to the C<key> opcode I had in some of
my proposals.
We can't do that. There's insufficient information about the 
variables at compiletime to do anything other than call into the PMC 
to do the operation, so the internal representation's irrelevant. As 
far as parrot is concerned, it's a PMC and it doesn't know anything 
about the inside.

 > Going with direct operations on keyed aggregates, then, makes the
 code somewhat more dense, since we only need to access one vtable per
 operand rather than two (one to fetch the data and one to operate on
 it). That's balanced somewhat by having to have two sets of PMC
 opcodes, one that operates on all parts keyed and one that doesn't.
Not when you need 64 opcodes for the keyed variants. 64:1 isn't
"somewhat balanced".
Erm.... you need to redo your math. Even *if* we went with a full set 
of keyed and unkeyed parameters (and I don't see a reason to do so, 
though we certainly can) it's not 64. At worst it's 16 for three-arg 
ops, and that's for both the keyed int, keyed normal, and nonkeyed 
version.

 > More information's available if anyone wants it, but this *is* the
 way we're going unless someone proves that it's suboptimal in the
 common case.
Implementation details wanted ;-)
I'll go thump the ops preprocessor, then. There's no reason to 
actually write all the code for it, as it can be autogenerated.
--
                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk