llvm dev - Jul 2013 - [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix

On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
> I don't think you've actually tested that, have you? (x86-64)
Oh, you're right, for constants > 5 bits you have that other thing
going on. I didn't think about the fact that the constant changed in
the middle of the thread (it started out as 1).

We use the gcc constraint "I" (0-31) in the kernel for this reason.

             Linus

On 07/14/2013 12:49 PM, Linus Torvalds wrote:
> On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>>
>> I don't think you've actually tested that, have you? (x86-64)
> 
> Oh, you're right, for constants > 5 bits you have that other thing
> going on. I didn't think about the fact that the constant changed in
> the middle of the thread (it started out as 1).
> 
> We use the gcc constraint "I" (0-31) in the kernel for this
reason.
> 
>              Linus
This is also why the Intel manuals point out that "some assemblers"
can
take things like:

	bt[l] $63,(%rsi)

... and turn it into:

	btl $31,4(%rsi)

This is definitely the friendly thing to do toward the human programmer.
 Unfortunately gas doesn't, nor does e.g. NASM.

	-hpa

On Mon, Jul 15, 2013 at 11:40 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 07/14/2013 12:49 PM, Linus Torvalds wrote:
>
> This is also why the Intel manuals point out that "some
assemblers" can
> take things like:
>
>         bt[l] $63,(%rsi)
>
> ... and turn it into:
>
>         btl $31,4(%rsi)
>
> This is definitely the friendly thing to do toward the human programmer.
>  Unfortunately gas doesn't, nor does e.g. NASM.
Yeah, that's definitely a "quality of implementation" issue.
Clearly
"bt $63,mem" is talking about bit 63, and a quality assembler would
either warn about it or just do the RightThing(tm) like the intel
manual says.

I'd actually like to say "think you" to the gas people, because
gas
today may not do the above, but gas today is still *lightyears* ahead
of where it used to be two decades ago. Back in those dark ages, GNU
as was even documented to be *only* about turning compiler output into
object code, and gas was the ghastliest assembler on the planet - it
silently did horrible horrible things, and didn't do *anything*
user-friendly or clever. It would entirely ignore things like implied
sizes from register names etc, and generate code that was obviously
not at all what the user expected, but because cc1 always used
explicit sizes etc and only generated very specific syntax, it "wasn't
an issue".

gas has improved immensely in this regard, and the fact that it
silently takes a $63 and effectively turns it into $31 is something I
think is not nice and not a good QoI, but considering where gas came
from, I'm not going to complain about it too much. It's
"understandable", even if it isn't great.

But quite frankly, partly because of just how bad gas used to be wrt
issues like this, I think that any other assembler should aim to be at
_least_ as good as gas, if not better. Because I definitely don't want
to go back to the bad old days. I've been there, done that. Assemblers
that are worse than gas are not worth working with. gas should be
considered the minimal implementation quality, and llvm-as should
strive to do better rather than worse..

(NASM used to be *much* more pleasant to work with than gas. Maybe you
should strive to make nasm DTRT wrt bt and constants, and maintain
that lead?)

                   Linus