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 section
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 "uns
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 examp
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 seman
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 qual
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) reorde
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 unsubsc
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 w
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 inlin
14 matches
Mail list logo
