[PATCH v2] X86: disambiguate unqualified btr, bts

[Stephen Checkoway]

On Jul 17, 2013, at 3:03 AM, Tim Northover <t.p.northover at gmail.com> wrote:

>> Cool. Sounds like we have a winner, then. Default to ‘l’ and issue a
>> diagnostic for immediates outside the range [0,31].
> 
> I think that solution only really makes consistent sense if you forget
> about "btw", which has the same problem for immediates above 15. To me
> it seems like it's taking half a stand that the immediate shouldn't
> wrap, but not a full one.

Hmm, I think I wasn't as clear as I could have been. For those bit testing mnemonics with explicit size suffixes, a diagnostic for immediates that are out of range seems correct. So [0,15] for btw and friends, [0,31] for btl and friends, and [0,63] for btq and friends. For those without, default to l and follow its behavior.

Other instructions which have limited range immediates like shl, sar, shr should likewise warn. E.g.,
	unsigned int x = 1;
	asm("shll $32, %0" : "+r"(x));
	printf("%u\n", x);
prints 1 which is probably not what the user wanted.

> For what it's worth, I'd favour a btl/btq choice combined with an
> error for > 63 (we don't need to include btw, since btl is more
> compact and does the same job; it's just there to mess with our
> plans). It avoids possibly decidedly non-obvious memory operand
> fiddling but does what most people would expect for as long as
> possible.

That also seems fine since it leads to behavior that is unlikely to surprise the user and is unlikely to have an effect that's different from what the user wanted.

Doing what the Intel manual suggests and what Ramkumar posted a patch for also seems fine from the point of view that its effect will be what the user wanted but concerns were raised that it would be surprising to the user to see different immediates and different memory accesses for the instruction.

-- 
Stephen Checkoway