This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: Use long long in x86 assembler


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]