2002-06-04 03:19:10

by J.A. Magallon

[permalink] [raw]
Subject: Algorithm for CPU_X86

Hi all...

Following with the cpu selection changes, setting the flags controlled
by the various CPU_X86_xxxx can be a real mess.

But, I have ralized that those CPU_X86 flags can be logically split in
two groups: features (TSC,MMX,3DNOW) and bugfixes (PPRO_FENCE) (or perhaps
more, it is just a first thought...).

So the algorithm can be easy (i think..)
- Enable all feature flags (say, MMX and 3DNOW)
- Disable all bugfix flags (FENCE)
- For each CPU
if it does not have the feature, kill it
(if VENDOR_INTEL set 3DNOW=n)
if this-cpu-kernel could run on buggy-cpu, enable fix
(if GENERIC_586 set FENCE=y)

Right ?

--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre9-jam1 #1 SMP lun jun 3 19:59:12 CEST 2002 i686


2002-06-04 04:30:01

by Ghozlane Toumi

[permalink] [raw]
Subject: Re: Algorithm for CPU_X86

On Monday 03 June 2002 23:18, J.A. Magallon wrote:
> Hi all...
> So the algorithm can be easy (i think..)
> - Enable all feature flags (say, MMX and 3DNOW)
> - Disable all bugfix flags (FENCE)
> - For each CPU
> if it does not have the feature, kill it
> (if VENDOR_INTEL set 3DNOW=n)
> if this-cpu-kernel could run on buggy-cpu, enable fix
> (if GENERIC_586 set FENCE=y)
>
> Right ?

What if the next wizz-bang processor as a great new feature ?
You'd have to disable it for *all* the previous CPUs...

ghoz

2002-06-04 05:19:18

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Algorithm for CPU_X86

Followup to: <[email protected]>
By author: "J.A. Magallon" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Following with the cpu selection changes, setting the flags controlled
> by the various CPU_X86_xxxx can be a real mess.
>
> But, I have ralized that those CPU_X86 flags can be logically split in
> two groups: features (TSC,MMX,3DNOW) and bugfixes (PPRO_FENCE) (or perhaps
> more, it is just a first thought...).
>

Don't forget optimizations. It's a big difference between "optimize
for" and "require" -- consider gcc, which have -mcpu= and -march=
respectively for the two.

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>