svn commit: r205307 - head/sys/i386/conf

[Alex Kozlov]

On Sat, Mar 20, 2010 at 01:27:24AM +1100, Bruce Evans wrote:
> > No, this is wrong.  Revert this.  We do _not_ unconditionally use SSE in the
> > kernel.  GENERIC should run just fine on a 486.  If it doesn't, that should be
> > fixed, but I have not seen any reports to the contrary.
> Indeed.  This doesn't even break the non-SSE case, since it doesn't
> remove I686_CPU or any of the code that dynamically chooses whether
> to use SSE.
> 
> Most 686's don't have SSE, since a 686 is an old name for a PentiumPro
> or maybe a Pentium2 and these don't have SSE (not sure about the
> Pentium2, but my old Celeron is Pentimum2-class and it only has FXSR).
> However, we keep using this old name for all generations of i386's
> after i586, even for generations that are really HAMMERs.  Thus the
> static configuration related to I*86_CPU is almost usless: it controls
> only couple of options for i486 and i586, with the more complicated
> and costly configuration for post-i586 being handled dynamically.
> Omitting I486_CPU and I586_CPU thus has very little effect except
> breaking i486 and i586, and having these options does little except
> support this foot-shooting.  The effect of I486_CPU is especially small.
> It is:
> - statically disable use of the TSC in the bogus get_cyclecount() API.
>    Although the TSC is dynamically configured elsewhere, this function
>    wants to use the TSC without any dynamic tests, so it is uses static
>    configuration for efficiency.
> - avoid compiling in functions to initialize a 486.  There is dynamic
>    code to use these functions as needed, but this optimization saves
>    a few hundred if not a few thousand bytes.
> - panic if the CPU is an i486, since the necessary extra support for
>    an i486 (just the above 2 features) is not present.
> I586_CPU gives a little more.  E.g., support for fixing the F00F hardware
> bug on some Pentium1's.  Again there is dynamic configuration for this
> but a few hundred bytes are saved by not compiling it in.
To be more elaborate:

i486:
- use binuptime in get_cyclecount, but only if tsc_present not set
- assign bzero_vector = i486_bzero if cpu family 486
- few initcpu functions for IBM Blue Lightning/Cyrix 486SLC,DLC/Cyrix 486DX/Cyrix 5x86/Cyrix 6x86
- don't panic on i486

i586:
- f00f workaround
- few initcpu functions for k5/k6/k6-2 to enable write alloc but only if CPU_WT_ALLOC defined
- * few (i586_bzero,i586_bcopy,i586_copyout,i586_copyin,fastmove) unused functions in
  sys/i386/i386/support.s. Code which was supposed to initialize them were commented out in 2001
  (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/npx.c.diff?r1=1.94;r2=1.95;f=h)
  This need to be fixed in any case.
- don't panic on i586

i686:
- define CPU_ENABLE_SSE
- few initcpu functions for Cyrix 6x86MX/Pentium Pro/Mendocino celeron if CPU_PPRO2CELERON set
- use sse2_pagezero if CPU_ENABLE_SSE set, i686_pagezero otherwise
- don't panic on i686


So, yes I?86_CPU is practicaly noop.


--
Adios