Could an Intel 486 wake up with FC3

[Aleksandar Milivojevic]

James Wilkinson wrote:
> Aleksandar Milivojevic wrote:
> 
>>On the sidenote, since i586 is minimal supported platform, I don't know 
>>why packages are still built as i386, and not as i586.
> 
> 
> *Very* frequently asked question in some quarters. The short answer is
> that it doesn't appear to be worth it.
> 
> There were very few instructions added to the instruction set between
> the 386 and the 686, and apparently most of those that were added
> aren't the sort of instructions that noticably accelerate programs.
> 
> The exceptions, the instructions that do help performance, give better
> control of spinlocks and multi-threaded code. That does help, especially
> on multi-processor kit, but the code that uses those instructions tends
> to be abstracted into glibc, which *is* compiled for the different
> processors. [1]
> 
> In the meantime, some surprisingly recent kit (VIA CPUs, for example)
> don't include all the 686 support.
> 
> The Fedora development crew have repeatedly said that they would be very
> interested to see benchmarks that prove a particular program would
> benefit from different compile settings. [2] But they do expect these
> benchmarks to be rigourous: same kit, the same location on the drive (if
> relevant), system rebooted between runs, just different compile flags.
> 
> As you say, these days the programs are *optimised* for Pentium 4s:
> apparently this works well for most other modern x86 CPUs.
> 
> James.
> 
> [1] Remember that all these programs are cross-platform: they can't rely
> on running on an Intel-compatible processor, so the Right Thing is
> usually to push this sort of thing into an OS library.

The thing is, thay haven't pushed it into OS library.  And I don't see 
any plans on releasing those libraries in i586 versions.  glibc is built 
as i386 and i686 only.  The only package that is exception from 
i386/i686 rule is the kernel which is built as i586/i686 (why not build 
it as i386 with i486 for NPTL, instead of i586, when the rest of the 
system is built that way anyhow?).  Because of this there were some very 
nasty problems in FC2 when running (some) programs that depend on 
Berkely DB library.  Namely Cyrus IMAPD RPMs were unusable on anything 
but i686.  I found references that for FC3, they compiled glibc with 
i486 instruction set to resolve the problem (however, glibc RPM still 
claims to be i386?!).

The problem is that NPTL is considered "must have" on Red Hat systems 
for some time now.  NPTL is available only for i486 and above (for long 
time it was only i586 or even i686 and above, don't remember correctly). 
  So there is a clash.  Base build architecture (i386) can't accomodate 
a "must have" feature of distribution.  Many people found out this the 
hard way when FC2 was released.  Some programs simply did not work on 
i586.  Also worth mentioning is that there will never be support for 
NPTL using i386-only instruction set (so it isn't something like "we'll 
wait until it is backported", that port is not going to happen, ever).

It would be kinda cleaner also.  There would be only i586 packages, plus 
several core OS libraries and kernel with both i586 and i686 packages. 
So that would be only two architectures, instead of the current mix that 
contains 3 1/2 architectures: i386, glibc quazy-i386 (which is poluted 
with i486 instructions for NPTL support), i586 (kernel only, glibc 
should have been built with i586 too, but it wasn't), and i686.

As for VIA processors, I haven't suggested using i686, but i586 as base 
build architecture (with instruction ordering optimized for current P4s 
for packages that don't have i686 version, and for i586/P4 for packages 
that have both i586/i686 versions).  Actually, in reality the result was 
exactly the opposite of what you suggested might happen.  Because 
distribution was mainly built as i386, on FC2 some packages do not work 
on some of the supported processors.  If distribution was mainly built 
as i586, there would be no problems.

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7