This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: defining 2-operand version of 3-operand insns?
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]