Heheh, I should read all of my mail before I send new ones. I'll commit it shortly.
Brian On Tue, 2001-10-16 at 10:36, Dan Sugalski wrote: > 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
