Date: Sat, 20 Mar 2010 10:09:20 +0200 From: Alex Kozlov <spam@rm-rf.kiev.ua> To: Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@freebsd.org>, spam@rm-rf.kiev.ua Subject: Re: svn commit: r205307 - head/sys/i386/conf Message-ID: <20100320080920.GA80859@ravenloft.kiev.ua>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100320080920.GA80859>