On Sun, 2011-11-20 at 18:02 +0000, Philipp Kern wrote: > On 2011-11-20, Ben Hutchings <b...@decadent.org.uk> wrote: > > As I said, I think they may still be supportable - the kernel config > > allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though > > whether the result actually works is another matter. > > So what are we actually requiring when moving from 486 to 586? From your > listing I guess rdtsc and the presence of a x87 FPU (didn't we already > require that before?). Anything else?
We don't yet require a real FPU as not all 486-class processors have them. The new Pentium instructions are (according to Dr Dobb's <http://drdobbs.com/embedded-systems/184409161#0042_000c>): CMPXCHG8B - Compare and Exchange 8 Bytes With the LOCK prefix, this provides an atomic double-word compare-and- exchange. Some lock-free multithreaded algorithms are impossible to implement in userland without this operation. The kernel can fall back to an alternate that disables interrupts temporarily and this is done by patching at boot time. Requiring CMPXCHG8B would reduce the kernel image size very slightly. RDTSC - Read Time Stamp Counter This is often used in performance-sensitive code, though it is hard to use correctly in userland due to preemption and variable frequency on older processors. The kernel makes heavy use of this for precise timing, if possible. If we require a TSC, some run-time checks are removed but the kernel still cannot use it unconditionally due to flaws in some implementations. CPUID - CPU Identification This is not (in itself) important to performance. Earlier processors can be identified through other means and the most useful information is already exposed to userland through /proc/cpuinfo. The kernel always checks whether CPUID is available before using it. RDMSR - Read from Model Specific Register WRMSR - Write to Model Specific Register RSM - Resume from System Management Mode MOV - Move to/from Control Registers These are only useful to the kernel and/or firmware and would be used where necessary regardless of the supported processors. So far as I'm aware, none of the above will be generated directly by compilers (though they may be available through 'intrinsics'). So it may be that there is little to be gained by moving to 586-class as a minimum. If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
signature.asc
Description: This is a digitally signed message part
