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 thecode 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* theway 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