On Mon, 2007-07-23 at 23:30 +0200, Andi Kleen wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
>
> Are you sure? I doubt it. It would need a full asm parser to do this
>
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly and then even it could be wrong
(e.g. when the
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Trent Piepho wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
> >
>
> How does it do that? By looking for \n, ';', etc?
Trent Piepho wrote:
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
>
How does it do that? By looking for \n, ';', etc?
J
-
To unsubscribe from this list: send the line
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > The (3) as I had originally written / meant was that multiple
> > instructions in a volatile asm would not get _individually_
> > interspersed with the rest of the code i.e. be emitted out
> > _consecutively_. I don't think
Satyam Sharma wrote:
> The (3) as I had originally written / meant was that multiple
> instructions in a volatile asm would not get _individually_
> interspersed with the rest of the code i.e. be emitted out
> _consecutively_. I don't think we need any such guarantees for
> the non-atomic variants
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> I'm not quite sure what your point is.
Could be a case of terminology confusion ...
> The paragraph you quoted is
> pretty explicit in saying that volatile doesn't prevent an "asm
> volatile" from being interspersed with other code, and the
Satyam Sharma wrote:
> Hi Jeremy,
>
>
> On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
>
>
>> Satyam Sharma wrote:
>>
>>> From: Satyam Sharma <[EMAIL PROTECTED]>
>>>
>>> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>>>
>>> Another oddity I noticed in this file. The
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The semantics of __volatile__
> > when used to
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The semantics of __volatile__
> >
Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm__ are that the compiler will not
> (1) elid, or, (2)
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm__ are that the compiler
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) intersperse, our
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) intersperse, our inline
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or,
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline
Satyam Sharma wrote:
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
I'm not quite sure what your point is.
Could be a case of terminology confusion ...
The paragraph you quoted is
pretty explicit in saying that volatile doesn't prevent an asm
volatile from being interspersed with other code, and the example
Satyam Sharma wrote:
The (3) as I had originally written / meant was that multiple
instructions in a volatile asm would not get _individually_
interspersed with the rest of the code i.e. be emitted out
_consecutively_. I don't think we need any such guarantees for
the non-atomic variants of
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
The (3) as I had originally written / meant was that multiple
instructions in a volatile asm would not get _individually_
interspersed with the rest of the code i.e. be emitted out
_consecutively_. I don't think we need
Trent Piepho wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
How does it do that? By looking for \n, ';', etc?
J
-
To unsubscribe from this list: send the line
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Trent Piepho wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
How does it do that? By looking for \n, ';', etc?
Yes:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly and then even it could be wrong
(e.g. when the sections
On Mon, 2007-07-23 at 23:30 +0200, Andi Kleen wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly
28 matches
Mail list logo
