From: "Jan Beulich" <jbeulich@novell.com>
To: "Chuck Ebbert" <cebbert@redhat.com>
Cc: <mingo@elte.hu>, <tglx@linutronix.de>,
<linux-kernel@vger.kernel.org>, <hpa@zytor.com>
Subject: Re: [RFC] x86: bitops asm constraint fixes
Date: Mon, 17 Mar 2008 09:16:22 +0000 [thread overview]
Message-ID: <47DE44F6.76E4.0078.0@novell.com> (raw)
In-Reply-To: <47DAE909.20006@redhat.com>
>> --- linux-2.6.25-rc5/include/asm-x86/bitops.h 2008-03-10 13:24:33.000000000 +0100
>> +++ 2.6.25-rc5-x86-clear-bit/include/asm-x86/bitops.h 2008-03-13 08:45:40.000000000 +0100
>> @@ -24,9 +24,12 @@
>> /* Technically wrong, but this avoids compilation errors on some gcc
>> versions. */
>> #define ADDR "=m" (*(volatile long *) addr)
>> +#define BIT_ADDR "=m" (((volatile int *) addr)[nr >> 5])
>> #else
>> #define ADDR "+m" (*(volatile long *) addr)
>> +#define BIT_ADDR "+m" (((volatile int *) addr)[nr >> 5])
>> #endif
>> +#define BASE_ADDR "m" (*(volatile int *) addr)
>
>Can't you just do everything with unsigned longs, like this?
That's not very desirable: For one part, because there are uses of
bitops on arrays of ints (and casting these up isn't fully correct on
x86-64 because of the same reason that using the bitops on char
arrays isn't correct (see the other response I sent to Jeremy's reply),
but also because operating on longs requires REX prefixes n x86-64,
hence making the code bigger for no good reason.
>>In include/asm-x86/types.h:
>>
>> ifdef CONFIG_X86_32
>> # define BITS_PER_LONG 32
>>+# define BITMAP_ORDER 5
>> #else
>> # define BITS_PER_LONG 64
>>+# define BITMAP_ORDER 6
>> #endif
>
>Then:
>
>> #define ADDR "=m" (*(volatile long *) addr)
>> +#define BIT_ADDR "=m" (((volatile long *) addr)[nr >> BITMAP_ORDER])
>> #else
>> #define ADDR "+m" (*(volatile long *) addr)
>> +#define BIT_ADDR "+m" (((volatile long *) addr)[nr >> BITMAP_ORDER])
>> #endif
>
>No need for BASE_ADDR that way (or ADDR could be renamed to that.)
Not really, since BASE_ADDR is an input, whereas ADDR is an output.
However, ultimately all uses of ADDR should go (since even if any of
the functions needs the memory clobber to stay, using an input for
specifying the array base address is sufficient - such operations simply
don't need an exact "m" output operand then).
Jan
next prev parent reply other threads:[~2008-03-17 9:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-13 9:08 [RFC] x86: bitops asm constraint fixes Jan Beulich
2008-03-14 7:51 ` H. Peter Anvin
2008-03-14 8:09 ` Jan Beulich
2008-03-14 18:56 ` Jeremy Fitzhardinge
2008-03-17 9:08 ` Jan Beulich
2008-03-14 21:07 ` Chuck Ebbert
2008-03-17 9:16 ` Jan Beulich [this message]
2008-03-19 13:19 ` H. Peter Anvin
2008-03-21 13:54 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2008-03-27 8:12 Jan Beulich
2008-03-27 8:41 ` Ingo Molnar
2008-04-14 12:53 ` Jan Beulich
2008-03-28 19:55 Jan Beulich
2008-04-14 13:31 Jan Beulich
2008-04-14 16:21 ` Jeremy Fitzhardinge
2008-04-15 7:03 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47DE44F6.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=cebbert@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox