Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Leopold Toetsch wrote:
>
> > 2. Proposal for _keyed opcodes
> > ------------------------------
> > The thread with subject "pdd06_pasm, pdd08_keys: _keyed ops" clearly
>
> > showes the shortcomings of the current _keyed opcodes and the
> > implementation of these.[1]
>
>
> > The 3 operand keyed add @a[$i] = @b[3] + %h{"k"}:
> > add_p_ki_p_kic_p_kc
>
>
>
> Attached is a proof of concept of my proposal.
>
> A 6 operand 3 keyed op get's rewritten like so:
>
> /* OP _p_k _p_k_p_k =>
> * set py, p_k
> * set pz, p_k
> * new px, .PerlUndef
> * OP px, py, pz
> * set _p_k_px
> */
>
> - It uses only set_ ops
> - only imcc, but with pasm syntax in example
I like this approach. (The first time you posted it I didn't
understand it).
What happens if you try to use it on an object which has no real
components like a bitvector or a packed structure? There will always
be a pack-unpack cycle. On the other hand, is there any case where
this pack-unpack cycle can be avoided?
The newly created PMC is of type PerlUndef. Is this the correct
behavior or shouldn't it be the same type as the old element in the
Component? Something like this.
# OP Px[kx], Py[ky], Pz[kz]
set Pa, Py[ky]
set Pb, Pz[kz]
typeof Ii,Px[kx]
new Pc, Ii
OP Pc, Pa, Pb
set Px[kx], Pc
> With an approach like this, we could cut down the VTABLE to roughly
> 1/3 of it's current size. The _keyed entrys would only consist of the
> set_.._keyed{,_int} variants plus exists_keyed and defined_keyed. And,
> we would never have the opcode explosion to 64 times of current size.
Instead of 1 opcode and 1 vtable-lookup with a quite complex
vtable-function you have 6 opcodes and 5 vtable lookups with simple
vtable-functions.
>From the just opcode-counting point of view, the first solution is
surley better, but the complexity of the vtable function is much
larger than in the later case. The vtable has to distinguish all 8
possible combinations of keyed/non-keyed and than do up to 4
vtable-lookups with the resulting calls to the vtable functions. So
behind the behind the scenes the total number of vtable-calls
(except for some very special cases) is exactly the same. Remains the
number of opcodes. But as the opcode-table gets smaller so its much more
likely that it fits into the cache. Also no vtable function has to
decide wether its called with 1, 2 or 3 keyed elements.
bye
b.
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
