From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Evans To: Greg McGary Cc: "Frank Ch. Eigler" , cgen@sourceware.cygnus.com Subject: Re: defining 2-operand version of 3-operand insns? Date: Wed, 06 Dec 2000 11:13:00 -0000 Message-id: <14894.36845.689253.246266@casey.transmeta.com> References: <200012012217.PAA04718@kayak.mcgary.org> <20001201173254.G20294@redhat.com> X-SW-Source: 2000-q4/msg00248.html 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]