This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: designated initializer vs. long long for i386 assembler
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Michael Meissner <michael dot meissner at amd dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Jan Beulich <jbeulich at novell dot com>, binutils at sourceware dot org, christophe dot harle at amd dot com
- Date: Tue, 3 Apr 2007 15:47:44 -0700
- Subject: Re: RFC: designated initializer vs. long long for i386 assembler
- References: <20070214015134.GA8541@bubble.grove.modra.org> <20070214020138.GA30518@lucon.org> <20070312190508.GA7845@lucon.org> <45F66D2D.76E4.0078.0@novell.com> <20070313124835.GA12145@lucon.org> <m34popi3ap.fsf@localhost.localdomain> <20070313155338.GA19017@lucon.org> <m3ejntgmlh.fsf@localhost.localdomain> <20070313161831.GB19017@lucon.org> <20070403222801.GA7433@mmeissner-gold.amd.com>
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.