On Sun, 2011-11-20 at 18:02 +0000, Philipp Kern wrote:
> On 2011-11-20, Ben Hutchings <ben@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'
Attachment:
signature.asc
Description: This is a digitally signed message part