From: alex@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@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@ieee.org