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]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.The big disadvantage here is speed. It means that specialized aggregates will have to create temporary PMCs for things that don't already have them, which is potentially slow and wasteful, something I'd rather avoid. Encouraging the use of specialized aggregates is one of the reasons for the typing system coming in with perl 6, and given the size of aggregates in perl 5 I think it's something that will see some heavy use.
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.
I don't mind the opcode explosion, honestly. It's automatically generated, and that's not a big deal. There are other ways to cut down on it as well, if we find the need.
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. For now, though, things stay generally the way they are. We can do some mild reworking to get things manageable if they're currently really unmanageable.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
