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.
>>Not when you need 64 opcodes for the keyed variants. 64:1 isn't
>>"somewhat balanced".
> Erm.... you need to redo your math.
So I'll try. We have 4 different "addressing" modes of one single keyed
argument:
set_p_k
set_p_kc
set_p_ki
set_p_kic
Now when we want to support 3-keyed operations there are 4*4*4 different
opcodes of an all-3-keyed operation (+ some more if one isn't keyed).
If we only have e.g. <op>_p_k_p_k_p_k we are missing the nice
optimization of integer indices, we have to go through key_integer(),
have to check for NULL keys and we need a full fledged (albeit) constant
Key PMC per argument.
Further: you have to implement type morphing, range checking BIG*
promotion in the non-keyed variants and in the keyed vtable variants
too. This is error-prone and a waste of memory.
Anf finally, you are saying that these are most usefull for aggregate
containing non-PMCs. What about
@a[i] = @b[i] + 1;
or the equivalent Perl6 vector operations[1]. More permutaions on opcodes
to implement these?
> ... 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.
What I'm missing here?
>>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.
But please with a Configure switch to turn it off ;-)
[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
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.
leo
