Re: defining 2-operand version of 3-operand insns?

[Doug Evans <dje@transmeta.com>]

Frank Ch. Eigler writes:
 > Hi -
 > 
 > On Wed, Dec 06, 2000 at 11:13:49AM -0800, Doug Evans wrote:
 > : [...]
 > : [in another message]
 > :  > Doug, does that sound reasonable to you, or are you philosophically
 > :  > opposed to the entire 2/3 operand insn hack?
 > : 
 > : I'm not at all opposed to this.  I support it!
 > : [pedantic: as long as it's kept in the assembler side of things and
 > : hacks aren't added to the simulator to support it]
 > 
 > On the other hand, consider that if the ifield-assertion code is
 > changed to allow reasonable generalization and specialization
 > alternatives, then this can be a simulator performance improvement
 > gadget.   It could subsume the (decode-splits*) construct that I
 > broke (disabled) a few months ago with the decoder revamping.

That's an orthogonal issue.  There are lots of decoder games
one can play.  For example, on machines with few registers
one could have separate versions of relevant insns for each
possible input value (register, constant, whatever).  This
extends to machines with more registers and more operands (2 -> 3)
though there it gets unwieldy in the general case (with a smaller
machine (m68k, i386) you don't have to go to as much trouble
to keep the resulting number of versions of insns manageable).
But however one chooses to do this, it's orthogonal to
supporting shortcuts in assembler syntax.