Displaying 20 results from an estimated 200 matches similar to: "I want to try something on the BTR file system,..."
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 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 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself.
-Jim
On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> 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
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 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
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
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 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:
> 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 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 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
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
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
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
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
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> Jim Grosbach wrote:
> > No. The above rule is absolutely the wrong thing to do, as has been
> > previously noted.
>
> I don't give a shit about whether you think it is "absolutely wrong"
> or not; I did what hpa and the Intel manual outlined. If you have
> some _reason_ not to do
2013 Jul 17
1
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de>
wrote:
>
> On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> > Jim Grosbach wrote:
> > > No. The above rule is absolutely the wrong thing to do, as has been
> > > previously noted.
> >
> > I don't give a shit about whether you think it is
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 17
3
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> No. The above rule is absolutely the wrong thing to do, as has been
> previously noted.
I don't give a shit about whether you think it is "absolutely wrong"
or not; I did what hpa and the Intel manual outlined. If you have
some _reason_ not to do that, bring it up.
I reported four bugs a few days ago, and the community has shown ZERO
(if not NEGATIVE)
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 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
>>>