llvm dev - Jul 2013 - [LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com>
wrote:
> On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra
> <artagnon at gmail.com> wrote:
>> Jim Grosbach wrote:
>>> To say that another way, is the assembler correctly diagnosing a
previously
>>> unnoticed problem in the project source code, or is the assembler
not
>>> behaving correctly according the the documented Intel assembly
mnemonics?
>> 
>> Where are the authoritative instruction set pages?  If such a thing
>> were readily available, why are there gaps in the current
>> implementation?  A quick Googling gets me [1], but I can't say
it's
>> authoritative.  What's important is that there certainly are
>> architectures where btr/bts are valid instructions, and they must be
>> supported.  btr/bts are certainly not invalid instructions that
we're
>> bending over backwards to support, because linux.git/gas works with
>> them.
>> 
>> [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html
>> _
> 
> The correct answer here is "Vol 2a of the Intel Reference Manual
> available off of the Intel website”.
Yep, for Intel syntax that’s exactly right.
> As far as whether or not we should support the instructions with a
> lack of length mnemonic, I'm going to step back away from the
> discussion. The Intel manuals support Intel syntax (which we also
> support) which necessarily doesn't have length encodings for most
> instructions, but AT&T syntax which gas uses (and llvm supports as
> well) often has length specifiers for instructions.

The length specifier is, as I understand it, required when the instruction
references memory but is optional (and inferred from the registers) for the
register variants.

The best reference I know of for the AT&T syntax is:
http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf

That does raise a clarifying question here. Is the code you’re interested in
using Intel or AT&T syntax?

Also note that the question isn’t whether we should support the btr/bts
instructions. We absolutely must (and do). The question is whether we are
properly handling the un-suffixed mnemonic form of the assembly syntax.

Perhaps you can help by clarifying via explicit example what code you believe
should work but does that. Descriptions are great, but specifics are better once
we’re this deep into the details.

-Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/76979871/attachment.html>

On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com>
wrote:
> The length specifier is, as I understand it, required when the instruction
references memory but is optional (and inferred from the registers) for the
register variants.
> 
> The best reference I know of for the AT&T syntax is:
http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
I'm not sure I'd use the documentation for the Solaris assembler as
authoritative for AT&T syntax, but page 17 does say that if the suffix is
omitted it defaults to long.

However, that isn't my experience with gas which uses register operands to
disambiguate, if possible (although I'm on a phone and can't check right
now).

-- 
Stephen Checkoway

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/30d207c7/attachment.html>

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote:
> On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com>
wrote:
>> The length specifier is, as I understand it, required when the
instruction references memory but is optional (and inferred from the registers)
for the register variants.
>> 
>> The best reference I know of for the AT&T syntax is:
http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
> 
> I'm not sure I'd use the documentation for the Solaris assembler as
authoritative for AT&T syntax, but page 17 does say that if the suffix is
omitted it defaults to long.
Yeah, me either. That’s part of why I’m asking for references. I’d love to know
which ones other people use. Good docs for AT&T syntax are annoyingly hard
to find.
> However, that isn't my experience with gas which uses register operands
to disambiguate, if possible (although I'm on a phone and can't check
right now).
Yep, it’s the memory reference versions which IIUC require a suffix.

I want to make sure we do the right thing here and know why we’re doing it
rather than just adding some aliases because it matches gas’ behavior.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/cee90d28/attachment.html>

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/asm/bitops.h#L68

Here is one example that I found. Are the inline assembly arguments
ambiguous in size?

-Jevin

Sent from my mobile device. Typos are par for the course.

On Jul 10, 2013, at 5:47 PM, Jim Grosbach <grosbach at apple.com> wrote:


On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com>
wrote:

On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:

Jim Grosbach wrote:

To say that another way, is the assembler correctly diagnosing a previously
unnoticed problem in the project source code, or is the assembler not
behaving correctly according the the documented Intel assembly mnemonics?


Where are the authoritative instruction set pages?  If such a thing
were readily available, why are there gaps in the current
implementation?  A quick Googling gets me [1], but I can't say it's
authoritative.  What's important is that there certainly are
architectures where btr/bts are valid instructions, and they must be
supported.  btr/bts are certainly not invalid instructions that we're
bending over backwards to support, because linux.git/gas works with
them.

[1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html
_


The correct answer here is "Vol 2a of the Intel Reference Manual
available off of the Intel website”.


Yep, for Intel syntax that’s exactly right.

As far as whether or not we should support the instructions with a
lack of length mnemonic, I'm going to step back away from the
discussion. The Intel manuals support Intel syntax (which we also
support) which necessarily doesn't have length encodings for most
instructions, but AT&T syntax which gas uses (and llvm supports as
well) often has length specifiers for instructions.



The length specifier is, as I understand it, required when the instruction
references memory but is optional (and inferred from the registers) for the
register variants.

The best reference I know of for the AT&T syntax is:
http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf

That does raise a clarifying question here. Is the code you’re interested
in using Intel or AT&T syntax?

Also note that the question isn’t whether we should support the btr/bts
instructions. We absolutely must (and do). The question is whether we are
properly handling the un-suffixed mnemonic form of the assembly syntax.

Perhaps you can help by clarifying via explicit example what code you
believe should work but does that. Descriptions are great, but specifics
are better once we’re this deep into the details.

-Jim

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/ab19e1fb/attachment.html>

Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested
in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you can help by clarifying via explicit example what code you
> believe should work but does that. Descriptions are great, but specifics
are
> better once we’re this deep into the details.
I don't know!  This is the first time I'm hearing about differences
between Intel and AT&T syntax; I have absolutely no clue how btr/bts
_should_ be implemented, and the only specifics I have are real-world
examples: linux.git/gas.  Does looking at bitops.h in the kernel tree
help?

For the record, I don't think matching linux.git/gas is a problem:
they're very authoritative pieces of software that have been around
for a _really_ long time.  What matters to me is that real-world
software works as expected, even if it violates some transcendental
(but unimplemented) authoritative standard [1].  If other mainstream
assemblers handle btr/bts differently, I would see a cause for worry;
otherwise, no.

Eli Friedman wrote:
> The reason it's the right thing to do is that the mem/imm forms of
> btsw and btsl have exactly the same semantics.
Not sure I understand this.

[1]: Especially considering that we can't seem to find one.

On Thu, Jul 11, 2013 at 10:59:32AM +0530, Ramkumar Ramachandra
wrote:
> For the record, I don't think matching linux.git/gas is a problem:
> they're very authoritative pieces of software that have been around
> for a _really_ long time.
That's a very, very weak argument. There are a lot of things Clang
rejects as errors by default that has been used in old code bases,
because GCC accepted it.
> Eli Friedman wrote:
> > The reason it's the right thing to do is that the mem/imm forms of
> > btsw and btsl have exactly the same semantics.
> 
> Not sure I understand this.
There is no way to tell from the arguments whether bts should be btsw or
btsl. That's the ambiguity it is complaining about. Fixing it is
trivial. There are other cases with similar issues in the 8087 syntax
with size of the floating point operand.

Joerg

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote:
>
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/
> asm/bitops.h#L68
> 
> Here is one example that I found. Are the inline assembly arguments
> ambiguous in size?
It would help us for sure to build the kernel and others.



--
JS