Leopold Toetsch writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote:
> 
> >>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.
> 
> We don't loose the abstraction with a special C<key> opcode. This C<key>
> opcode is the abstraction: get a pointer to an item in the aggregate (or
> prepare for a LHS). This is a vtable method of the aggregate. Splitting
> the 3-keyed operations down to simpler parts, that's it - no permutations.

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.

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

How does foo know that it's working on fake PMCs?  Or am I missing your
vision (probably am)?

> [1] I expect the most speed gain here, when we can optimize to
> hell.
> 
>   @a >>=<< @b + 1     // @a, @b are known to be arrays of packed int

FWIW, that does something entirely useless[1]: the equivalent of:

    @a = (1 + @b) x @a

I think you meant to say:

    @a = @b >>+<< 1


>   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!

Luke

[1] I'm saying that word with full awareness of its connotations on a
list like this :-)

> leo

Reply via email to