At 10:04 AM 10/16/2001 -0500, Brian Wheeler wrote:
>Thoughts?
Go for it. This sort of thing's just fine. I know I made a "NO NEW OPCODES
WITHOUT CLEARANCE" statement a while ago, but that really needs clarification.
The thing that's a no-no is new 'high-level' opcodes--basically anything
that'd require a new entry in parrot_assembly.pod. Opcode variants--tan
which takes a constant, say--are fine. We may, at some point, prune out the
less-used opcodes so we don't have a huge table of 'em if that turns out to
be a problem (like if there's a performance knee at 255/256 or 511/512 base
opcodes in the switch) but for the moment I'm not overly worried about the
excess of opcodes if it turns out that having special ones is worth it.
It may, of course, turn out that:
set N0, 12.4
tan N1, N0
ends up being faster than
tan N1, 12.4
in some cases (like if we almost never use tan of a constant but do use tan
of a register a lot, thus having to fault in the code for the constant tan
every time we use it) but that's something that'll have to do some
performance testing on to know for sure.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
