This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Hi -

Greg McGary <greg@mcgary.org> wrote:
: > I got this to work by employing a dirty trick.  [...]
: > (df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
: >      ((value pc) (add UWI value (sll UWI value (const 5))))
: >      ((value pc) (srl UWI value 5)))
: > 
: > The decode part is actually unused, since the insn that uses
: > dest2 has a NO-DIS attribute.
: 
: Whereas this works for the assembler, it causes trouble for the
: simulator:
: [...]
: 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?

I think there are two or three good longer term options:

* an extension to the insn macro code that would allow one to copy
  ifield values
* a generalization of insn ifield-assertions (the "(+ ENUM op (f-foo 1))"
  clauses) to permit specialization to override other alternatives, both
  for disassembly and for sim decoding

In the short term, another way would be to combine the two alternative
instructions into one, taking a special operand that stands for the
required/optional pair.  This operand would be associated with a parser
function in *.opc that consumes one or two comma-separated fields (depending
on the input string), and fills in the optional field in the former case.
(An associated printer routine can do the inverse transformation.)

Do I need to complete this sketch with an example?


- FChE

PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]