Messages in this thread | | | Date | Mon, 23 Jul 2007 11:05:17 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints |
| |
Andi Kleen wrote: >> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had >> just written a test program that used "Ir" with an automatic variable >> defined in the inline function (as is the case with these bitops) and >> observed that even when I gave > 32 values, it would still work -- hence >> my conclusion. >> >> However, the patch still stands, does it not? [ I will modify the >> changelog, obviously. ] The thing is that we don't want to limit >> @nr to <= 31 in the first place, or am I wrong again? :-) > > These bit operations only allow 8 bit immediates, so 0..255 would > be correct. N might work from the 4.1 docs, but I don't know if it works > in all old supported gccs (3.2+) > > However I is definitely not wrong and most bit numbers are small anyways. >
"I" is correct. The Intel documentation on this is highly confusing (and has bugs in it), but it does unambiguously state:
"Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset field in combination with the displacement field in the memory operand ... The processor will ignore the high-order bits if they are not zero." AMD processors might be different for all I know.
So unless gas is capable of doing this transformation (and it's not as of binutils-2.17.50.0.6) "I" is what's needed here.
-hpa
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |