CentOS - Jun 2005 - Re: i486 and i686 are the majority ISAs for x86 -- WAS: CentOS 4.0 -> 4.1 update failing

From: alex at milivojevic.org
> At various points in time Red Hat made some somewhat conflicting 
> decisions.  The first was that Red Hat distributions must have NPTL.
> For NPTL support, there are two components of system where it is
> implemented, kernel and glibc.  Back then glibc supported NPTL only
> for i686.  NPTL support was later backported to i586 and i486.
Also remember that sometimes someone has to adopt something
before the issues are well known and accommodated.  More often
than not, this is Red Hat.
> Kernel should be fine with i486 and newer.  There will never be
> i386 support for NPTL, since i386 lacks some assembly instructions
> needed to implement it effectively (NPTL i386 system would be
> unusably slow).
Exactly.  Today, I don't expect Linux to run on anything but an i486
ISA or higher.  The TLB and other augmentations of the i386 ISA
are huge upswings in performance.  I'm not talking about Intel-
specific product additions (cache, FPU, etc...), but the actual ISA an
features like the TLB.

Pretty much everyone since the mid-'90s has been producing a i486
compatible ISA, including pretty much every embedded product.

The i586 is _only_ for _genuine_ Pentium/Pentium MMX.  It should
_never_ be used on anything else -- and that includes the Pentium
Pro on-ward, which are i686 ISA.

The i686 ISA and designs fix a massive amount of serious design
errors made in both the Pentium ALU itself as well as considerations
in its i586 ISA.  To be fair to Intel, it was their first superscalar
design.  But at the same time, NexGen was able to pull off an even
better, superscalar ALU, and much of Intel's "design assistance"
came indirectly from joining Digital on the Alpha chip briefly.

i486 ISA Compatible Architectures
- AMD:  486, 586, K5 (both original and Nx586+FPU), SCLan
- Cyrix:  5x86, 6x86, M1
- IDT/Centaur:  WinChip (just the original?)
- SGS-Thompson:  Nearly all cores (except very latest)

i686 ISA Compatible Architectures
- AMD:  K6, Athlon, Athlon64/Opteron
- Cyrix/NS:  M2, Geode
- IDT/Centaur:  WinChip2+ (or WinChip4+?)
- SGS-Thompson:  Latest cores are i686?
- ViA:  C3

The only major processor I know that was only i386 ISA compatible,
but had Pentium-like features (as well as its own idea of a TLB) was
the original NexGen Nx586.  AFAIK, the rev of the Nx586 with a
non-pipelined FPU was fully i486 ISA comaptible, and became AMD's
K5 design at higher ratings (120+?).  Either that, or it was AMD's
changes for the K5 that made it i486 compatible (and the K6 was
a rev to make it fully i686 compatible).

i486 cores were still popular until very recently.  National Semi has
been liberal in its licensing of the M2/Geode cores, which are i686
ISA compatible.  I believe SGS-Thompson how has their own core
offering that is i686.  Almost everything else out there is based on
these two -- and even AMD has gone Geode and deprecated its
SCLan for embedded PC duties.
> Then, Red Hat dropped i386 kernels, and continued to support i586
> and i686 kernels only.  However on the glibc side, i386 and i686
> builds were used.  This broke things badly in Fedora Core 2 for i586
> machines for some packages that used Berkely DB library (most
> notably, Cyrus IMAPD was the most problematic package).
I'm sure Red Hat's rationale was that the fact that i586 architectures
are _very_rare_ now -- the original Pentium and Pentium MMX _only_.
Using i586 ISA (especially i586 optimizations) on i686 is _detrimental_
to performance -- even Intel's own.

I know most people don't know this, but it's a very well known fact
among developers.
> Now, I'm not sure if this part is urban legend or reality.  Apperently
they
> "fixed" it in Fedora Core 3.  The fix was not i586 version of
glibc (which
> would be logical, glibc is one of the few rare packages that might actually
> benefit from i586 instruction set,
But _only_ on _true_ Pentium and Pentium MMX.  On a K6, M2, Pentum Pro
and latter revisions, you want to use i686, _not_ i586.  Trust me on this,
there are a lot of "hacks" to i586 code because of the massive bugs in
its
superscalar ALU.  One of the reasons for MMX was actually to introduce
instructions to work around the design flaws (hence why 45 of the 47
instructs of MMX are integer related -- sometimes using the single FPU
pipe instead of the dual-ALU pipe for operations that should normally
be done by the ALU).
> if nothing else than because of mandatory NPTL support for Red Hat
> distributions).  What they did was to build i386 version of glibc with
> NPTL part using i486 instructions (at that point in time, glibc folks
> have already backported NPTL to i486 and i586).
I would personally wish Red Hat, and the rest of the Linux community,
would just call the packages "i486" when you need an i486 ISA.  But
I'm sure that would break a lot of package managers.  But I would
have still done it as of either Red Hat Linux 8.0 or Fedora Core 2.

Red Hat has essentially been building i486 ISA with i686 optimizations
(but not i686 ISA) as standard years ago (RHL8?  7.3?).  I know they
flirted (adopted?) P4 optimizations since Athlon seems to do well with
them too.
> Now, *if* i586 is supported architecture for distribution (are they
> shipping i586 kernel?  what release notes for distro say?), then this
> should be considered as a bug.
Red Hat _avoided_ ever shipping an i586 ISA distro, let alone I do
_not_ think they _ever_ optimized for i586 -- other than a few release
kernels.  i586 is _only_ good for Pentium / Pentium MMX from a
performance standpoint.
> What might be checked first is if FC3 NPTL fix for i386 glibc is reallity?
> Is it included with RHEL4 glibc?
It would surprise me if anyone put in the effort to build a release-
quality set of NPTL patches for i386.  i486 or higher has really been
the realm of even the embedded x86 core since the mid-'90s, and the
i686 since the turn of the millenium.

Hence why it's really not worth Red Hat's bother to ship anything but
i686 ISA, because people who subscribe to RHEL are typically running
mid-to-late '90s hardware on-ward.  I would almost argue they should
adopt the same attitude for Fedora Core, although SPEC files in FC
should _always_ be capable of building at least i486.

Supporting the i386 at this point is just not worth it.  Even Alan Cox
pointed this out to me when I questioned the move to i486 years ago,
that even embedded x86 cores have been i486 for a long, long time
and the "drop" in performance due to lacking instructions for
addressing,
TLB, etc... in the i386 ISA just make it a poor solution in general.


From: alex at milivojevic.org
> %ifarch %{nptlarches}
> %define enablekernelnptl 2.4.20
> %ifarch i386
> %define nptl_target_cpu i486
> %define tls_subdir tls/i486
> %else
> %define nptl_target_cpu %{_target_cpu}
> %define tls_subdir tls
> %endif
> %endif
> So, I'd say just compile it for i386, and it should work correctly. 
It'll use
> i486 instructions for NPTL support.  Some testing to see if NPTL is really
> working might be needed.  That's apperently the way Red Hat is doing
it, so
> CentOS should follow.
If you watch the build of nearly all packages -- especially the kernel and
GLibC -- when targetting the i386, you'll see "--march=486" which
is
_clearly_ requiring a i486 ISA.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org