Re: RFC: designated initializer vs. long long for i386 assembler

["Michael Meissner" <michael dot meissner at amd dot com>]

On Tue, Mar 13, 2007 at 09:18:31AM -0700, H. J. Lu wrote:
> On Tue, Mar 13, 2007 at 09:00:26AM -0700, Ian Lance Taylor wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > 
> > > > Of course it would be super nice to move the opcode table from
> > > > include/opcode/i386.h into opcodes/i386-opc.c.
> > > 
> > > I can do that. But opcodes/i386-opc.c will be generated from
> > > a tool compiled with a C99 compiler so that I can use
> > > designated initializer in opcodes/i386-opc.h.
> > 
> > I would vote strongly against checking this sort of generated file
> > into CVS.  I think there are other approaches which work just as well.
> > 
> 
> I am open to all suggestions.

I may be missing followups to this discussion, but like H. J. I too need more
bits in operand_modifier for a future AMD processor, and I'm sure both of our
companies will happily add more things in the future.  In our original
implmentation of the new instructions, we used modifier bit pairings that don't
occur (like regKludge and Seg2ShortForm) to indicate new bits.  At the moment,
I'm using long long, but I think we need to iterate on another solution.

I don't like the idea of forcing the use of a C99 to build opcodes/i386-opc.c.
This for instance might break if you use something like Red Hat RHEL4 for
development since the native compiler is 3.4 based.  I also don't like long
long, in part because because it isn't in C90, and in part because historically
the code generated by gcc for long long ops in 32-bit has been horrible.

So, the simplest approach is to add another field operand_modifier2 or some
such, and take the one time hit in coverting i386-opc.c, adding the extra
field.  It means the spacing will be worse, but I suspect nobody who edits this
file still uses 80 column windows right now.

Now given a lot of fields are the same, it may be better to define a set of
macros to initialize a bunch of common cases.  Right now for instance we have:

{"cmovo",   2, 0x0f40, X, Cpu686, wlq_Suf|Modrm,	{ WordReg|WordMem, WordReg, 0} },
{"cmovno",  2, 0x0f41, X, Cpu686, wlq_Suf|Modrm,	{ WordReg|WordMem, WordReg, 0} },

I could imagine a macro like (assuming we add another op_modifier field):
#define OP2_cmove(str,op,cpu)						\
	{ str,					/* name */		\
	  2,					/* operands */		\
	  op,					/* base_opcode */	\
	  X,					/* extension_opcode */	\
	  cpu,					/* cpu_flags */		\
	  wlq_Suf|Modrm,			/* opcode_modifier */	\
	  0,					/* opcode_modifier2 */	\
	  {WordReg|WordMem, WordReg, 0}}	/* operand_types */

OP2_cmove("cmovo",  0x0f40, Cpu686),
OP2_cmove("cmovno", 0x0f40, Cpu686),

Ie, instead of a single OP macro that takes all of the fields, define a bunch
of macros that commonizes things and initializes the various flag fields.  That
way, if we ever have to add another field, we have to modify 40 or so macros,
and not thousands of instructions.

Obviously we could add a generator function that builds i386-opc.c at build
time, much like we use the gen* functions in GCC, but I suspect that may more
overhead than it is worth.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com