[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
artagnon at gmail.com
Wed Jul 10 22:29:32 PDT 2013
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
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 . If other mainstream
assemblers handle btr/bts differently, I would see a cause for worry;
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.
: Especially considering that we can't seem to find one.
More information about the llvm-dev