[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- WAS: i586/686 glibc/kernel

Bryan J. Smith wrote:
<snipping discussion re: relatively fast old-ISA chips>
But the ISA is often only a 486 or lower!  Even when the product is sold
as 5th-Gen (Pentium) or 6th-Gen (Pentium II) "class" chip!

Now AMD has licensed National Semi's Geode products.  The Geode are the
Cyrix M2 core, which are Pentium ISA.  These are quickly commonplace.

Pentium = 586 obviously.

But AMD was is still selling its E86/SCLAN series too (and was its
_only_ product for awhile), which kicks some serious butt at 133MHz,
with lots of on-board peripherials.

Also a 586:
"The ÉlanSC520 microcontroller combines a 32-bit, low-voltage Am5x86 CPU with a complete set of integrated peripherals..."

(quoted from http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_8634_8635,00.html

Same deal with STMicro and others.  These are _huge_ in Europe, as well
as non-US markets, and a lot of imports into the US as well.  STMicro is
notorious for marketing them as "Pentium/Pentium-II" class because they
run at 100MHz, have 64-bit memory busses, PCI, ATA, USB, etc...
support.  But underneath, the _majority_ of STMicro products are i486

Yup, looks like there are a lot of 486s there, looking at this page: http://www.st.com/stonline/products/selector/107.htm

These systems are all over the place.  In black boxes atop of your TV
that have 128MB+ of RAM, 10-20GB disks, etc...  Serious power.

That's why I'm all for making the distro i686 optimized, but i386 ISA

But... All of the examples you quoted were 486+. Now consider what Jakub Jelinek wrote a little while back:

"I'd like to make NPTL the default threading library for FC3,
as a step in phasing out LinuxThreads."

"3) NPTL has not been ported to i386, only i486+, x86_64,
   ia64, ppc32, ppc64, s390, s390x, alpha, sh and sparcv9.
   i386 (and sparc < v9) lacks atomic instructions powerful
   enough for NPTL needs.  Well, I have tried to port NPTL
   to i386, http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html,
   but that port is severely limited and maintaining two
   different IA32 ports would be too much work."

So clearly a very important dividing line seems to lie between 386 and 486 support. I'm all for going wint NPTL as default for Fedora; this is supposed to be a forward-thinking distribution.

But for plain Jane x86, there is little sense to break i386 ISA
compatibility.  Yes, _assume_ the "performance/memory/disk" equivalent
of a Pentium Pro/II or higher.  But leave the instruction set
compatibility (ISA) at i386 -- please, for Fedora adoption sake.

Well, as far as I can see it sure seems like letting all programs use NPTL-specific features by default can be a somewhat important perfomance win? That's a real difference that ignoring the 386 would give us, and I have yet to see any examples even of modern embedded processors that don't support the 486 ISA (admittedly, I might not have looked hard enough but the examples you came up with were all 486 and you seem to have much more insight in the embedded world than I do). I think that this makes 486 a realistic base target, and given that there isn't much of an NPTL port for 386

I summary, my main point is that 386 is not the same as 486. Jakub suggests in the e-mail I linked to earlier that in general there is little to be gained from going to --march=i486; however, given that there won't be an NPTL library available for 386 I think it feels more honest to just go with --march=i486 anyways. Not that I feel all that strongly about it though.

Basically I think that I'm more or less agreeing with you: Fedora shouldn't dump old ISAs unless there is a real, tangible gain; moving beyond 486 doesn't really seems to give us that. Where we differ is that I think that ignoring the 386 by explicitly using NPTL is a good idea and very much in line with the Fedora goals.


Per Bjornsson <perbj at stanford dot edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]