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: "Michael Meissner" <michael dot meissner at amd dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: "Michael Meissner" <michael dot meissner at amd dot com>, "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 19:14:00 -0400
- Subject: Re: RFC: designated initializer vs. long long for i386 assembler
- References: <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> <20070403224744.GC13989@lucon.org>
On Tue, Apr 03, 2007 at 03:47:44PM -0700, H. J. Lu wrote:
> 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.
How many new instruction types are you guys adding :-) Note, I don't mean
number of new instructions, but instructions that need different operand
modifiers.
Even if we posit adding operand_modifier2 as an array and use { ... }, we can
still hide it in macros like I suggested.
I just did a simple analysis, and there are only 87 distinct bit combintions
for all of the current operands in the FSF sources. I could imagine changing
operand_modifier into an enum, that indexes into a structure/array for each of
the tests, possibly hidden by feature test macros. Adding new bits is an
exponential problem as you note, but the machines tend to be regular in terms
of the number of distinct possibilities.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com