Promoting Crusoe and Geode Processors to i686 Status

Promoting Crusoe and Geode Processors to i686 Status

[Nick Lowe]

Hi All,

[x86: do not promote TM3x00/TM5x00 to i686-class] revoked the
promotion of Crusoe chips to i686 on the basis that they lacked NOPL.
Is this the right decision now?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7ef94e6889186848573a10c5bdb8271405f44de

Now that many distributions are using or moving to i686 as a baseline,
shouldn't these chips be promoted to i686?

NOPL is not standard i686, it was originally publicly undocumented by
Intel and has just been supported de facto since the Pentium Pro.
The Crusoe and Geode chips support every instruction of i686 except
NOPL. This causes pain!
The correct solution for GNU/Linux is surely to ensure that when
something is compiled for generic i686, NOPL is nowhere to be seen...

Unfortunately, the semantics for choosing the NOP sequence in binutils
(GAS) have been completely wrong for a while. This, however, has
finally been fixed now!

http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html
http://gcc.gnu.org/ml/gcc/2010-08/msg00194.html

There is actually a workaround in the kernel for this bug:
[x86: prevent binutils from being "smart" and generating NOPLs for us]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=28f7e66fc1da53997a545684b21b91fb3ca3f321

The coded assumption there was that all i686 class processors did
support the NOPL instruction. This has been changed by the recent AMD
patches so that it is not assumed and it's specified as an extension
where it is supported.

The benefit of full i686 optimisation, which do have real performance
implications, are things like bswap (useful in networking),
cmpxchg/xadd (used in atomics) and cmov (useful in compiler generated
code).

The frustrating thing for me is that broken semantics for i686 have
led to, in my opinion, absurd patches such as the following being
proposed as a workaround to the situation:

http://groups.google.com/group/linux.kernel/browse_thread/thread/c1ec68f5498236dc/617726bec31595ed?show_docid=617726bec31595ed

The point that gets missed there, I think, is that, abstractly, a NOP
is meant to be exactly as it says on the tin, a No Operation.
It's meant to do nothing at all - for a predefined number of clock cycles.

A NOP is commonly used for timing purposes, doesn't this break that contract?

Again, NOPL is not standard i686 - albeit it's an extension supported
by the vast, vast majority of i686 class processors.
If you're compiling generically for i686, however, one should never
assume that it is present.

Bad patches like the above to work around broken compilation, I think,
cause more harm than good. They plaster over the real problem.

So what say you all?

Cheers,

Nick

Re: Promoting Crusoe and Geode Processors to i686 Status

[Nick Lowe]

Two further questions...

1) Is there a benefit to keeping a CONFIG_MGEODEGX1 and
CONFIG_MGEODE_LX when we have a situation where i686
CONFIG_X86_GENERIC builds work?

# Geode GX1 support
cflags-$(CONFIG_MGEODEGX1)      += -march=pentium-mmx
cflags-$(CONFIG_MGEODE_LX)      += $(call
cc-option,-march=geode,-march=pentium-mmx)

2) Should there be the special case that forces the suboptimal
-mtune=generic32 to work around the binutils NOPL bug or, as I think,
should people just update to a sane binutils version? (It's a special
case triggered where CONFIG_X86_P6_NOP is not set.)

# Bug fix for binutils: this option is required in order to keep
# binutils from generating NOPL instructions against our will.
ifneq ($(CONFIG_X86_P6_NOP),y)
cflags-y                        += $(call
cc-option,-Wa$(comma)-mtune=generic32,)
endif

Reference: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/Makefile_32.cpu;hb=HEAD

Cheers,

Nick

Re: Promoting Crusoe and Geode Processors to i686 Status

[H. Peter Anvin]

On 09/07/2010 05:27 PM, Nick Lowe wrote:
> 
> 2) Should there be the special case that forces the suboptimal
> -mtune=generic32 to work around the binutils NOPL bug or, as I think,
> should people just update to a sane binutils version? (It's a special
> case triggered where CONFIG_X86_P6_NOP is not set.)
> 

What's suboptimal about it?

	-hpa

Re: Promoting Crusoe and Geode Processors to i686 Status

[Nick Lowe]

Hi,

Here goes...

-mtune tunes the binary for given architecture. This as opposed to
defining the baseline architecture, and thus available instruction
set, which -march does.

I believe that -mtune is predominantly used for instruction
scheduling. GCC uses it when it's reordering instructions to optimise
for specific micro-architecture over others.

With -mtune=i686, I am of the opinion that you instruct the compiler,
and give it the opportunity, to deliver a better ordering of the
instructions. In this case, better ordering for i686 than you would
get with -mtune=generic32.

I'm probably wrong somehow, it's probably marginal, and I'll concede
to your infinitely better knowledge any day! That's why I phrased it
as a question! :)

Cheers,

Nick

On Wed, Sep 8, 2010 at 10:39 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 09/07/2010 05:27 PM, Nick Lowe wrote:
>>
>> 2) Should there be the special case that forces the suboptimal
>> -mtune=generic32 to work around the binutils NOPL bug or, as I think,
>> should people just update to a sane binutils version? (It's a special
>> case triggered where CONFIG_X86_P6_NOP is not set.)
>>
>
> What's suboptimal about it?
>
>        -hpa
>

Re: Promoting Crusoe and Geode Processors to i686 Status

[H. Peter Anvin]

On 09/08/2010 03:14 PM, Nick Lowe wrote:
> Hi,
> 
> Here goes...
> 
> -mtune tunes the binary for given architecture. This as opposed to
> defining the baseline architecture, and thus available instruction
> set, which -march does.
> 
> I believe that -mtune is predominantly used for instruction
> scheduling. GCC uses it when it's reordering instructions to optimise
> for specific micro-architecture over others.
> 
> With -mtune=i686, I am of the opinion that you instruct the compiler,
> and give it the opportunity, to deliver a better ordering of the
> instructions. In this case, better ordering for i686 than you would
> get with -mtune=generic32.
> 
> I'm probably wrong somehow, it's probably marginal, and I'll concede
> to your infinitely better knowledge any day! That's why I phrased it
> as a question! :)
> 

We don't pass -mtune=generic32 to gcc.  We pass -Wa,-mtune=generic32 to
gcc, which affects binutils only.

	-hpa