On Thu, Dec 13, 2012 at 12:51:29PM +0100, David Brown wrote:
> Is there much to be gained from keeping 486 support - or
> alternatively, is there much to be gained by dropping it at the same
> time?
In practice, there is very little difference betweeen 486 and Pentium
for code what will be generated by a compiler (tuning is different,
especially for the FPU).
After digging the instruction set differences, the following instructions
were implemented on the 486 but not on the 386:
1) bswap: ntohl and htonl directly map to it, heavily used in the
networking code, but not earth shattering.
2) xadd and cmpxchg: basic building blocks for atomic operations,
the main reason to drop i386 IMHO.
3) cache management instructions: invd and wbinvd
4) tlb management: invlpg
3) and 4) don't affect the compiler, only the kernel. However, the main
reason to drop the 386 in the Linux kernel is the fundamentally broken
behaviour of accessing user space from the kernel, fixed in the 486
and later by the WP bit. This caused memory management nightmares in
the kernel (actually, I'm not even convinced that there were no
security holes).
Between the 486 and the Pentium, the differences are:
+1) cmpxchg8b: may be useful for some atomic operations, but not
all 32 bit architectures have 64 bit atomic operations (to
my knowledge, only x86, m68k and s390), so arm/mips/ppc and
others have to deal with this limitation.
+2) cpuid: its results may be used when selecting libraries and
code paths, but hopefully from variables set after executing
it once at program/library initialization.
+3) rdtsc: maybe useful for performance measurements but apart
from this abstracted in gettimeofday() and more modern
equivalents
+4) rdmsr/wrmsr: only kernel code
-5) mov to/from test registers: removed on Pentium, only kernel code
+6) rsm (exit the bloody SMM mode): never used by a compiler (without
considering that fact that SMM is a potential latency nightmare
if used on embedded systems)
Actually, I believe that some (late) 486 implemented cpuid and rdtsc.
So only point 1) from the above list is relevant.
> If 586 has been the standard configuration for the last two
> releases of gcc, and 686 has been the standard for most 32-bit x86
> Linux distributions for a number of years, perhaps it is worth
> deprecating 486 (and maybe even 586) at the same time. After all,
> "deprecating" targets does not mean that they are dead - users can
> always use older versions of gcc, and can argue against the
> deprecation if it is affecting them.
Either drop both 486 and 586 or none. There is nothing significant
to be gained from dropping only the former. PPro has cmov/fcmov,
floating point compares directly setting flags, but still only the
x87 FPU. After this the next significant step is SSE2 in Pentium-III
(SSE is single precision only, not a general purpose FPU).
Gabriel
