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]
My first proposal WRT a solution (modifying the run loop) did not earn
much
At 8:23 AM +0200 10/22/02, Leopold Toetsch wrote:
Juergen Boemmels wrote:
... Also no vtable function has to
decide wether its called with 1, 2 or 3 keyed elements.
Yes, another advantage, I didn't think of. Currently all _keyed
vtable calls have to check, it the key is really there. This co
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
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]
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
> > implementa
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"}
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
What happens if you try to use it on an object which has no real
components like a bitvector or a packed structure?
The substituted code for an aggregate is:
set Py, P1[k1]
and for a non keyed operand:
set Py, {N,S,I}1
Dan Sugalski wrote:
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
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 ne
Dan Sugalski wrote:
For the moment, I'd rather things stay the way they are. If we can
produce demonstrable speed wins, then I'll change my mind.
I have some preliminary numbers:
- changed core.ops to include add_keyed [1]
- did implement add_keyed_int in array
- hacked set_pmc_keyed_int()
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski wrote:
>
> > At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
>
>
> >> 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{,_i
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
No, take the "new px, .PerlUndef" out of the opcode, it must only be
done once. This temporary Px can be reused by _all_ _keyed ops.
Im not sure about this. This really depends on the fact if the
op does something depending
10 matches
Mail list logo
