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

[Doug Evans <dje@transmeta.com>]

Greg McGary writes:
 > > OTOH, I've only seen (f-FIELD VALUE) construct used with
 > > literal VALUE arguments.
 > 
 > That appears to be the limitation.

I believe that's the case.  Supporting non-literal values
is a left-for-later extension.

 > I got this to work by employing a dirty trick.  Fortunately,
 > the dest and src1 operands are contiguous, so I defined a
 > new field that encompasses both, called f-dest2, and used
 > encode/decode magic to propagate:

Another way is to have assembler C code do the duplication.
Define a separate version of the operand used by the 2 operand
version and give it special parse/insert/extract/print handlers
(whatever's necessary - you might be able to get away with just a
special insert handler).

[in a later message]
 > All of the instructions for which I have 2 & 3 operand versions
 > defined as above are excluded from the sim decoder as ambiguous.
 > Since the 2-operand versions are exclusively an assembler-language
 > convenience, they should be ignored from the simulator.
 > Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
 > is there a better way out of this jam?

ALIAS is the NO-SIM attribute you're looking for.
Since this is an assembler side problem I'd prefer to keep it
out of the simulator too.  The ALIAS attribute will do that.

[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]