[PATCH v2] X86: disambiguate unqualified btr, bts

[Stephen Checkoway]

On Jul 13, 2013, at 12:43 PM, Tim Northover <t.p.northover at gmail.com> wrote:

> The problem is that behaviour seems to violate the intended design of
> AT&T mnemonics.

Is there an actual specification for AT&T syntax? The one Jim Grosbach posted to the list explicitly says that instructions without the size suffix default to l. I don't see any reason to take that as the definitive definition of AT&T syntax but then I don't see anything that would indicate that gas's behavior is incorrect.

> If we make btr default to btrl, shouldn't we do the same for every
> other pair?


Based on the Solaris doc, yes.

On Jul 15, 2013, at 7:18 PM, Jim Grosbach <grosbach at apple.com> wrote:

> If adding aliases for these mnemonics is the right thing to do, then an argument can and should be made for that independent of gas’ current behavior.

I think the best argument is the one Linus made (modulo being rude). If the assembler is a tool for humans, then all else being equal, it should operate on a principle of least surprise.

bt $n, mem becomes
1.  btl $n, mem for n in [0, 31] and
2a. btq $n, mem for n in [32, 63] or
2b. btl $(n-32), mem+4 for n in [32, 63]

Or even take the more general route discussed in the Intel manual
bt $n, mem becomes btl $(n % 32), mem + 4*(n / 32)

bt, btr, and bts should probably operate in the same manner.

It seems unlikely people would ever write an immediate value outside the allowed range and want/expect the compiler to blindly copy the one byte immediate even though the hardware only looks at the least significant 4 (resp. 5 or 6) bits for btw (resp. btl or btq).

-- 
Stephen Checkoway