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 17:41:54 -0700
- Subject: Re: RFC: designated initializer vs. long long for i386 assembler
- References: <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> <20070403231400.GA10387@mmeissner-gold.amd.com>
On Tue, Apr 03, 2007 at 07:14:00PM -0400, Michael Meissner wrote:
>
> 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.
I need a lot. All those bits, cpu_flags, opcode_modifier and
operand_types, should be extendable.
>
> Even if we posit adding operand_modifier2 as an array and use { ... }, we can
> still hide it in macros like I suggested.
>
It isn't as clean as bitfield. Since we have to change it, why not
do it right once for all?
> 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
I assume you meant by
enum
{
x = 1;
x = 2;
x = 4;
....
};
It isn't much better than today. Bitfield should work nicely with
i386-opc.c generated from a table. I will implement it in a few
weeks.
H.J.