Luke Palmer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch writes: > And I think you're saying that it'll be illegal to use this pointer PMC > if the aggregate changes or anything like that, so the proxy can be as > dumb and fast as possible... right? And that it wouldn't really need a > header. So it wouldn't really be a PMC. But that's okay, I think.
It would be a Key PMC probably with some extra flags. I didn't much think about details yet. Its basically that part inside current keyed set operations that gets at the value inside the aggregate. This part of code is currently repeated all over followed by an get- or set_<type> something operation basically. For aggregates holding basic types a C-pointer would be enough. > I'm wondering how the actual ops would look in this case though. > foo a[x], b[y] > turns into: > key P0, a[x] > key P1, b[y] > foo P0, P1 Yes. The first one would be C<key_lhs> or such. > How does foo know that it's working on fake PMCs? Or am I missing your > vision (probably am)? It doesn't matter for PMCs. The C<key_lhs> for C<a> has to prepare a new PMC slot in the aggregate, P0 points at it, C<foo> sets the value then. > I think you meant to say: > @a = @b >>+<< 1 Oops, yes of course. >> n = @b.elements() >> c = n / CHUNK_SIZE >> r = n % CHUNK_SIZE >> for i (0..c-1) >> ptra = @a.make_chunk(i) >> ptrb = @b.get_chunk(i) >> for (1..CHUNK_SIZE) >> *ptr++ = *ptrb++ + 1 >> // do rest ... >> @a.elements = @b.elements >> >> This would be a seqence of some specialized opcodes (enventually with a >> runtime check in front) and its fully JITtable. > That would be, um, very cool. PDL, eat your heart out! I dunno, which of the many acronyms of PDL you are applying here :-) But anyway such optimizations make vector ops fly at optimized C level speed. "Fat" multikeyed opcodes wont't do that. > Luke leo
