RFC: designated initializer vs. long long for i386 assembler

[H. J. Lu]

On Tue, Apr 03, 2007 at 06:28:01PM -0400, Michael Meissner wrote:
> 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.
> 

Adding another field won't solve the long term problem. We will
run out of bits again very soon. We should use bitfield. We can
generate i386-opc.c from a table or something like that.


H.J.