On 07/15/2013 11:56 AM, Linus Torvalds wrote:
>
> (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?)
>
Yes, that is in fact why I took over NASM development when Simon Tatham
gave up on it.
On Mon, Jul 15, 2013 at 11:56 AM, Linus Torvalds
wrote:
>
> I'd actually like to say "think you" to the gas people
My fingers are all over the place today. "thank you".
It's not even like "i" and "a" are next to each other - they're at
different ends of the keyboard. Clearly I'm more used to
On Mon, Jul 15, 2013 at 11:47 AM, H. Peter Anvin wrote:
>
> To be fair, we *ought to* be able to do something like:
>
> asm volatile(LOCK_PREFIX "bts%z0 %1,%0"
> : BITOP_ADDR(addr) : "Ir" (nr) : "memory");
>
> ... but some older version of gcc are broken and emit
On Mon, Jul 15, 2013 at 11:40 AM, H. Peter Anvin 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
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:
>>
On 07/14/2013 02:14 PM, Andi Kleen wrote:
>
> I think best would be to just find some way to implement LOCK prefix
> patching using atomic compiler intrinsics and then switch to those
>
That will take a long time to make happen now, and then when we change
things we have to wait for gcc to
On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote:
> The SDM entry for BT mentions that the instruction may touch 2 or 4
> bytes depending on the operand size, but doesn't specifically mention
> that a 64 bit operation size touches 8 bytes - and it doesn't mention
> anything at all about operand
On 07/14/2013 12:49 PM, Linus Torvalds wrote:
> On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover
> 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
On 07/14/2013 12:49 PM, Linus Torvalds wrote:
On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover t.p.northo...@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
On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote:
The SDM entry for BT mentions that the instruction may touch 2 or 4
bytes depending on the operand size, but doesn't specifically mention
that a 64 bit operation size touches 8 bytes - and it doesn't mention
anything at all about operand size
On 07/14/2013 02:14 PM, Andi Kleen wrote:
I think best would be to just find some way to implement LOCK prefix
patching using atomic compiler intrinsics and then switch to those
That will take a long time to make happen now, and then when we change
things we have to wait for gcc to catch
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
On Mon, Jul 15, 2013 at 11:40 AM, H. Peter Anvin h...@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
On Mon, Jul 15, 2013 at 11:47 AM, H. Peter Anvin h...@zytor.com wrote:
To be fair, we *ought to* be able to do something like:
asm volatile(LOCK_PREFIX bts%z0 %1,%0
: BITOP_ADDR(addr) : Ir (nr) : memory);
... but some older version of gcc are broken and emit
On Mon, Jul 15, 2013 at 11:56 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I'd actually like to say think you to the gas people
My fingers are all over the place today. thank you.
It's not even like i and a are next to each other - they're at
different ends of the keyboard. Clearly
On 07/15/2013 11:56 AM, Linus Torvalds wrote:
(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?)
Yes, that is in fact why I took over NASM development when Simon Tatham
gave up on it. I'll
I think best would be to just find some way to implement LOCK prefix
patching using atomic compiler intrinsics and then switch to those
Then all this inline assembler horror could be ifdef'ed away
for old compilers only, and likely the generated code would
be better as the compiler could
On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover 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
On 07/14/2013 12:30 PM, Tim Northover wrote:
>> And that is why I think you should just consider "bt $x,y" to be
>> trivially the same thing and not at all ambiguous. Because there is
>> ABSOLUTELY ZERO ambiguity when people write
>>
>>bt $63, mem
>>
>> Zero. Nada. None. The semantics are
> And that is why I think you should just consider "bt $x,y" to be
> trivially the same thing and not at all ambiguous. Because there is
> ABSOLUTELY ZERO ambiguity when people write
>
>bt $63, mem
>
> Zero. Nada. None. The semantics are *exactly* the same for btl and btq
> in this case, so
On Sun, Jul 14, 2013 at 12:23 PM, Jeremy Fitzhardinge wrote:
>
> It looks like that if the base address isn't aligned then neither is the
> generated access, so you could get a protection fault if it overlaps a
> page boundary, which is a semantic rather than purely operational
> difference.
You
(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
(Resent without HTML)
On 07/14/2013 10:19 AM, Linus Torvalds wrote:
> Now, there are possible cases where you want to make the size explicit
> because you are mixing memory operand sizes and there can be nasty
> performance implications of doing a 32-bit write and then doing a
> 64-bit read of
On Sun, Jul 14, 2013 at 11:35 AM, Tim Northover wrote:
>
> I'm coming at this from the compiler side, where the register form is
> unambiguous and not questioned. The discussion we're having involves
> only the immediate form of the instruction. GNU as interprets:
>
> bt $63, mem
>
> as
>
Linus Torvalds wrote:
> Ok. So your commit message and explanation was pure and utter tripe,
> and the real reason you want this is that llvm-mc is broken.
>
> Please fix llvm-mc instead, ok? If the intent of llvm is to be
> compatible with the gnu compiler tools, then it should do that. Plus
>
Hi,
The issue perhaps wasn't explained ideally (and possibly shouldn't
have been CCed directly to you either, so apologies, but now that
there *is* a discussion...)
> Try some actual relevant test instead:
>
>bt %eax,mem
>bt %rax,mem
>
> and notice how they are actually fundamentally
On Sun, Jul 14, 2013 at 11:26 AM, Ramkumar Ramachandra
wrote:
>
> 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:
Ok. So your commit message and explanation was pure and utter tripe,
and the real reason you
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
On Sun, Jul 14, 2013 at 5: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
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
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
On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra
artag...@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
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
On Sun, Jul 14, 2013 at 11:26 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
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:
Ok. So your commit message and explanation was pure and utter tripe,
and the real
Hi,
The issue perhaps wasn't explained ideally (and possibly shouldn't
have been CCed directly to you either, so apologies, but now that
there *is* a discussion...)
Try some actual relevant test instead:
bt %eax,mem
bt %rax,mem
and notice how they are actually fundamentally
Linus Torvalds wrote:
Ok. So your commit message and explanation was pure and utter tripe,
and the real reason you want this is that llvm-mc is broken.
Please fix llvm-mc instead, ok? If the intent of llvm is to be
compatible with the gnu compiler tools, then it should do that. Plus
the gas
On Sun, Jul 14, 2013 at 11:35 AM, Tim Northover t.p.northo...@gmail.com wrote:
I'm coming at this from the compiler side, where the register form is
unambiguous and not questioned. The discussion we're having involves
only the immediate form of the instruction. GNU as interprets:
bt $63,
(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
(Resent without HTML)
On 07/14/2013 10:19 AM, Linus Torvalds wrote:
Now, there are possible cases where you want to make the size explicit
because you are mixing memory operand sizes and there can be nasty
performance implications of doing a 32-bit write and then doing a
64-bit read of the
On Sun, Jul 14, 2013 at 12:23 PM, Jeremy Fitzhardinge jer...@goop.org wrote:
It looks like that if the base address isn't aligned then neither is the
generated access, so you could get a protection fault if it overlaps a
page boundary, which is a semantic rather than purely operational
And that is why I think you should just consider bt $x,y to be
trivially the same thing and not at all ambiguous. Because there is
ABSOLUTELY ZERO ambiguity when people write
bt $63, mem
Zero. Nada. None. The semantics are *exactly* the same for btl and btq
in this case, so why would
On 07/14/2013 12:30 PM, Tim Northover wrote:
And that is why I think you should just consider bt $x,y to be
trivially the same thing and not at all ambiguous. Because there is
ABSOLUTELY ZERO ambiguity when people write
bt $63, mem
Zero. Nada. None. The semantics are *exactly* the same
On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover t.p.northo...@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
I think best would be to just find some way to implement LOCK prefix
patching using atomic compiler intrinsics and then switch to those
Then all this inline assembler horror could be ifdef'ed away
for old compilers only, and likely the generated code would
be better as the compiler could
44 matches
Mail list logo
