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