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. > 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". > 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 ;-) leo
