RFC: Use long long in x86 assembler
H. J. Lu
hjl@lucon.org
Tue Jul 18 20:01:00 GMT 2006
On Mon, Jul 17, 2006 at 02:14:25PM -0700, H. J. Lu wrote:
> On Mon, Jul 17, 2006 at 01:12:34PM -0700, H. J. Lu wrote:
> > On Mon, Jul 17, 2006 at 06:18:58PM +0930, Alan Modra wrote:
> > > On Sun, Jul 16, 2006 at 10:13:29AM -0700, H. J. Lu wrote:
> > > > On Sun, Jul 16, 2006 at 01:23:56PM +0930, Alan Modra wrote:
> > > > > On Thu, Jul 13, 2006 at 04:09:03PM -0700, H. J. Lu wrote:
> > > > > > http://sourceware.org/ml/binutils/2001-05/msg00065.html
> > > > > > http://sourceware.org/ml/binutils/2001-05/msg00187.html
> > > > > >
> > > > > > use InvMem on source operand to indicate that it must be register.
> > > > > > I don't believe it is correct since RegYYY won't match memory anyway
> > > > > > and InvMem is used to indicate how operand should be encoded. This
> > > > > > patch removes it.
> > > > >
> > > > > It's true that the way the code is currently written that removing this
> > > > > flag will not change the insn encoding. All InvMem does on *source*
> > > > > operands of these reg->reg insns is document that the register is
> > > > > encoded in the regmem field of the modrm byte. So why do you want to
> > > > > remove documentation? There is certainly nothing wrong with InvMem on
> > > > > these operands.
> > > >
> > > > Those operands only take registers and are encoded properly. What
> > > > additional information does InvMem provide here?
> > >
> > > Didn't you read what I said? To a programmer reading i386.h, InvMem
> > > says that this particular register operand is encoded in the regmem
> > > field, and the other register is encoded in the reg field.
> >
> > InvMem is only checked on the destination register operand in
> > instructions with 2 register operands. It looks like InvMem is really
> > used on the destination register operand to indicate how to encode an
> > instruction with 2 register operands.
> >
>
> This patch renames InvMem to RegMem and updates comments.
>
>
I really don't like it since InvMem/RegMem is included in AnyMem,
but it is really meanful in the destination register operand. It
really belongs to opcode_modifier. I'd like to add a bit to
opcode_modifier. But that means long long will be used since there
is no unused bit in opcode_modifier. I timed "make check" in gas on
both x86 and x86-64. I got
1. On x86-64:
int: 18.57s user 5.17s system 85% cpu 27.738 total
long long: 18.70s user 5.18s system 85% cpu 27.802 total
2. On x86:
int: 14.19s user 2.24s system 83% cpu 19.726 total
long long: 14.29s user 2.13s system 88% cpu 18.593 total
The difference is quite small. Any objections to use long long in x86
assemblers?
H.J.
More information about the Binutils
mailing list