Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix"
2013 Jul 14
0
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
(resent without HTML)
On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote:
> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
> changed a bunch of btrl/btsl instructions to btr/bts, with the following
> justification:
>
> The inline assembly for the bit operations has been changed to remove
> explicit sizing hints on the instructions, so the assembler will
2013 Jul 15
1
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote:
> (resent without HTML)
>
> On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote:
>> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
>> changed a bunch of btrl/btsl instructions to btr/bts, with the following
>> justification:
>>
>> The inline assembly for the bit operations has been
2013 Jul 13
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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.
The Intel documentation implies that this is the case:
> If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure
2013 Jul 14
0
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
> changed a bunch of btrl/btsl instructions to btr/bts, with the following
> justification:
>
> The inline assembly for the bit operations has been changed to remove
> explicit sizing hints on the instructions, so the
2013 Jul 10
2
[LLVMdev] [BUG] Support unqualified btr, bts
Hi,
I happened to notice that linux.git uses plenty of btr and bts
instructions (not btrl, btrw, btsl, btsw). For examples, see
arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity,
while GNU as is fine with them. Surely, there must be architectures
where the w/l variant is unavailable? LLVM must support those
architectures, no?
Thanks.
2013 Jul 14
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Stephen Checkoway wrote:
> [...]
Thanks for the absolutely splendid analysis!
> For the memory, immediate form without the suffix, it seems like the options are
> 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error;
> 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed
2013 Jul 10
0
[LLVMdev] [BUG] Support unqualified btr, bts
On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> Hi,
>
> I happened to notice that linux.git uses plenty of btr and bts
> instructions (not btrl, btrw, btsl, btsw). For examples, see
> arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity,
> while GNU as is fine with them. Surely, there must be architectures
> where
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote:
>
> 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
2013 Jul 11
1
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 11
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 14
2
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
Linus Torvalds wrote:
>> btrl $1, 0
>> btr $1, 0
>> btsl $1, 0
>> bts $1, 0
>
> What the heck is that supposed to show?
I was trying to show a reduced case where gas doesn't complain, but
llvm-mc does. Try compiling this with llvm-mc, and you'll get:
.text
btrl $1, 0
in.s:2:1: error: ambiguous instructions require an
2013 Jul 10
6
[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
>>>
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 10
3
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386. GNU as supports them fine. Unfortunately, LLVM does not
> support them, and barfs with:
>
> error: ambiguous instructions require an explicit suffix
>
> Fix this problem by disambiguating it
2007 Apr 18
8
[patch 0/8] Basic infrastructure patches for a paravirtualized kernel
Hi Andrew,
This series of patches lays the basic ground work for the
paravirtualized kernel patches coming later on. I think this lot is
ready for the rough-and-tumble world of the -mm tree.
The main change from the last posting is that all the page-table
related patches have been moved out, and will be posted separately.
Also, the off-by-one in reserving the top of address space has been
2007 Apr 18
8
[patch 0/8] Basic infrastructure patches for a paravirtualized kernel
Hi Andrew,
This series of patches lays the basic ground work for the
paravirtualized kernel patches coming later on. I think this lot is
ready for the rough-and-tumble world of the -mm tree.
The main change from the last posting is that all the page-table
related patches have been moved out, and will be posted separately.
Also, the off-by-one in reserving the top of address space has been
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> Also, please elaborate on why this is a good change. Because gas accepts it
> isn’t sufficient reason in and of itself.
That they're valid instructions isn't sufficient reason? Should I
additionally say that linux.git uses them?
I wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> Jim Grosbach wrote:
>> Also, please elaborate on why this is a good change. Because gas accepts it
>> isn’t sufficient reason in and of itself.
>
> That they're valid instructions isn't sufficient reason? Should I
> additionally say that linux.git uses them?
>
Is the