public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Algorithm for CPU_X86
@ 2002-06-04  3:18 J.A. Magallon
  2002-06-04  4:28 ` Ghozlane Toumi
  2002-06-04  5:19 ` H. Peter Anvin
  0 siblings, 2 replies; 3+ messages in thread
From: J.A. Magallon @ 2002-06-04  3:18 UTC (permalink / raw)
  To: Lista Linux-Kernel

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:jamagallon@able.es
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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Algorithm for CPU_X86
  2002-06-04  3:18 Algorithm for CPU_X86 J.A. Magallon
@ 2002-06-04  4:28 ` Ghozlane Toumi
  2002-06-04  5:19 ` H. Peter Anvin
  1 sibling, 0 replies; 3+ messages in thread
From: Ghozlane Toumi @ 2002-06-04  4:28 UTC (permalink / raw)
  To: J.A. Magallon, Lista Linux-Kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Algorithm for CPU_X86
  2002-06-04  3:18 Algorithm for CPU_X86 J.A. Magallon
  2002-06-04  4:28 ` Ghozlane Toumi
@ 2002-06-04  5:19 ` H. Peter Anvin
  1 sibling, 0 replies; 3+ messages in thread
From: H. Peter Anvin @ 2002-06-04  5:19 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <20020604031840.GA4289@werewolf.able.es>
By author:    "J.A. Magallon" <jamagallon@able.es>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-06-04  5:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-04  3:18 Algorithm for CPU_X86 J.A. Magallon
2002-06-04  4:28 ` Ghozlane Toumi
2002-06-04  5:19 ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox