Hi everybody,
I've tried to install CentOS 5.5 i386 on an AMD Geode LX 800 processor. That processor, being of the much more recent i586 family, is fully i386- compatible. However, my attempt was brutally shattered when I had to discover that CentOS takes a rather open and surprising attempt at defining x86 compatibility: while claiming to be i386-compatible CentOS 5 requires an i686 processor and does not support the fully i386 but not the least i686 compatible i586 architecture.
This is more of a general issue. i386 does not generally refer to "whatever x86-compatible processor is the most recent" but a very well defined and standardized architecture. Specifically, i386 refers to Intels 80386 processor and its 32-bit x86 architecture (which is why x86 are i386 are often used interchangeably when x86 should instead be referring to the 8086 architecture). Code that claims to be i386 compatible has to run on any given microprocessor that claims to be i386 compatible. It's as simple as that: if it doesn't run on i386 processors then it's not i386 compatible. That's industry standard and thus universally valid. If one would claim i386 compatibility but require a x86_64 compatible processor, which of course would be capable of executing standard i386 code, it'd be the exact same issue. It'd be more radical but at its core not different from CentOS's unmet claim of i386 copmpatibility.
I guess my question is thus quite simple: why does CentOS 5 claim to be i386 when it's not even remotely i386 compatible? And shouldn't the name reflect code and/or processor family compatibility and affiliation?
And in a closely related question of more personal interest: what exactly is it that makes CentOS require an i686 processor?
Thanks, Martin
Martin,
its the US - nobody takes things as literal as someone speaking German...
Over the past few years, i386 has become a synonym for 32bit rather than "it will run on a 80386". The RPM package for the kernel is correctly labeled as i686, its just the name of the distro that remained i386. The main reason for the higher requirements is the CMOV instruction. Search google for i386 CMOV and you will find the reason why and that this affects most other distributions the same way.
Peter.
On Sunday, December 12, 2010 04:35:35 pm Martin Jungowski wrote:
Hi everybody,
I've tried to install CentOS 5.5 i386 on an AMD Geode LX 800 processor. That processor, being of the much more recent i586 family, is fully i386- compatible. However, my attempt was brutally shattered when I had to discover that CentOS takes a rather open and surprising attempt at defining x86 compatibility: while claiming to be i386-compatible CentOS 5 requires an i686 processor and does not support the fully i386 but not the least i686 compatible i586 architecture.
This is more of a general issue. i386 does not generally refer to "whatever x86-compatible processor is the most recent" but a very well defined and standardized architecture. Specifically, i386 refers to Intels 80386 processor and its 32-bit x86 architecture (which is why x86 are i386 are often used interchangeably when x86 should instead be referring to the 8086 architecture). Code that claims to be i386 compatible has to run on any given microprocessor that claims to be i386 compatible. It's as simple as that: if it doesn't run on i386 processors then it's not i386 compatible. That's industry standard and thus universally valid. If one would claim i386 compatibility but require a x86_64 compatible processor, which of course would be capable of executing standard i386 code, it'd be the exact same issue. It'd be more radical but at its core not different from CentOS's unmet claim of i386 copmpatibility.
I guess my question is thus quite simple: why does CentOS 5 claim to be i386 when it's not even remotely i386 compatible? And shouldn't the name reflect code and/or processor family compatibility and affiliation?
And in a closely related question of more personal interest: what exactly is it that makes CentOS require an i686 processor?
Thanks, Martin
On Sun, 12 Dec 2010 17:08:24 -0500 Peter A wrote:
Over the past few years, i386 has become a synonym for 32bit rather than "it will run on a 80386". The RPM package for the kernel is correctly labeled as i686, its just the name of the distro that remained i386.
That's why I'm asking whether or not it would make more sense to rename the distro to i686 instead. It might make perfect sense in a very colloquial way but from a technical point of view i386 suggests 32-bit 80386 compatibility. Either way, it's just a suggestion and general wondering since I wasn't aware of what i386 had become in the US.
The main reason for the higher requirements is the CMOV instruction. Search google for i386 CMOV and you will find the reason why and that this affects most other distributions the same way.
I'm familiar with the CMOV instruction. I wasn't aware that it wasn't part of Intel's initial 80386 32-bit instruction set, thanks a lot. Funnily enough I found unanswered questions on the Ubuntu forums inquiring whether their i386 ISO wasn't really i386 because it didn't load on an 80386 processor ;)
I've installed CentOS 4.8 by the way. Takes a while to load but once it's up and running it's surprisingly fast on that 500 MHz 'beast' :)
Best, Martin
Another question just occurred to me: does this i686 limitation also apply to RHEL5?
Thanks, Martin
On Mon, Dec 13, 2010 at 5:18 AM, Martin Jungowski martin@rhm.de wrote:
Another question just occurred to me: does this i686 limitation also apply to RHEL5?
Thanks, Martin
As I wrote to you in the Forum thread[1], RHEL-4 and RHEL-5 provide no support for i586.
Akemi / toracat
[1] http://www.centos.org/modules/newbb/viewtopic.php?topic_id=29278&forum=3...
On Mon, 13 Dec 2010 05:26:14 -0800 Akemi Yagi wrote:
As I wrote to you in the Forum thread[1], RHEL-4 and RHEL-5 provide no support for i586.
Akemi / toracat
Right, I forgot. Thanks again.
Martin
On Mon, Dec 13, 2010 at 5:02 AM, Martin Jungowski martin@rhm.de wrote:
On Sun, 12 Dec 2010 17:08:24 -0500 Peter A wrote:
Over the past few years, i386 has become a synonym for 32bit rather than "it will run on a 80386". The RPM package for the kernel is correctly labeled as i686, its just the name of the distro that remained i386.
That's why I'm asking whether or not it would make more sense to rename the distro to i686 instead. It might make perfect sense in a very colloquial way but from a technical point of view i386 suggests 32-bit 80386 compatibility. Either way, it's just a suggestion and general wondering since I wasn't aware of what i386 had become in the US.
It actually makes more sense to call the distro x86, better to peg it to a particular architecture then a CPU release.
Then one has x86 (32-bit) and x86_64 (64-bit).
But this is all decided by Redhat, CentOS is just a RHEL recompilation with the intellectual property stripped out.
-Ross
On Dec 14, 2010, at 1:14 PM, Ross Walker wrote:
It actually makes more sense to call the distro x86, better to peg it to a particular architecture then a CPU release.
Then one has x86 (32-bit) and x86_64 (64-bit).
Sure there's an appealing symmetry with "x86" <-> "x86_64". The problem is that the names keep changing for marketing and technical reasons. Even "i686" and "i586" are mostly meaningless jargon. E.g. the linux kernel chose to start returning "i686" as a generic, not specific, and rely on precise details in /proc/cpuinfo years and years ago.
But this is all decided by Redhat, CentOS is just a RHEL recompilation with the intellectual property stripped out.
Nothing decided by RedHat (or Intel) prevents using "ia32e" or "i786" as a cpu architecture identifier in CentOS.
It's a "Principle of Least Surprise" wrto users that continues to use "i386" as an identifier.
73 de Jeff
On Tue, 14 Dec 2010 13:29:29 -0500 Jeff Johnson wrote:
Sure there's an appealing symmetry with "x86" <-> "x86_64". The problem is that the names keep changing for marketing and technical reasons. Even "i686" and "i586" are mostly meaningless jargon. E.g. the linux kernel chose to start returning "i686" as a generic, not specific, and rely on precise details in /proc/cpuinfo years and years ago.
This could be because ever since the 1995 introduction of the i686 architecture with the Pentium Pro the core architecture hasn't changed significantly. AMD's K7 is fully i686 compatible, the K8 is a K7 core plus 64-bit features, and the K10 is an improved K8. At it's very core (in terms of instruction set, not in terms of actual silicon implementation) even the latest Phenom II X6 is still a fully i686 compatible K7. Intel tried a new architecture with the Pentium 4 but failed spectacularly as we all know, and returned to an improvied i686 processor with its Pentium M (aka Banias), Core and Core 2 series. The Core i7 is just like the Phenom II - a full i686 instruction set with 64- bit features.
Martin
thus Martin Jungowski spake:
On Tue, 14 Dec 2010 13:29:29 -0500 Jeff Johnson wrote:
Sure there's an appealing symmetry with "x86" <-> "x86_64". The problem is that the names keep changing for marketing and technical reasons. Even "i686" and "i586" are mostly meaningless jargon. E.g. the linux kernel chose to start returning "i686" as a generic, not specific, and rely on precise details in /proc/cpuinfo years and years ago.
This could be because ever since the 1995 introduction of the i686 architecture with the Pentium Pro the core architecture hasn't changed significantly. AMD's K7 is fully i686 compatible, the K8 is a K7 core plus 64-bit features, and the K10 is an improved K8. At it's very core (in terms of instruction set, not in terms of actual silicon implementation) even the latest Phenom II X6 is still a fully i686 compatible K7. Intel tried a new architecture with the Pentium 4 but failed spectacularly as we all know, and returned to an improvied i686 processor with its Pentium M (aka Banias), Core and Core 2 series. The Core i7 is just like the Phenom II - a full i686 instruction set with 64- bit features.
The P6 design in the Pentium Pro was the next big leap after the i386 featured an MMU -- it was the first x86 CPU to feature out of order execution, and it was one of the first x86 CPUs to 'emulate' x86; for doing this, it used an internal RISC-based design (AFAIR the NexGen Nx586 was the first x86 CPU to do this, and it features speculative execution, as well). Mind the extreme 16bit performance problem the Pentium Pro had.
Martin
Timo
All,
As interesting (or not) as this discussion may be, please note that this is the CentOS-devel mailing list and, thus, is not the appropriate venue -- as it has no relevance to the ongoing development of CentOS.
Putting that into perspective, the core components of the CentOS Project are those products that are aimed to be 100% binary compatible with the Upstream Vendor's products. Therefore if i386 is used upstream as a label, it will also be used likewise by the CentOS Project.
Please take the discussion of processors, instruction sets, et al, to the CentOS general m/l.
In peace and friendship, Alan. :-)
Am 12.12.2010 um 22:35 schrieb Martin Jungowski:
Hi everybody,
I've tried to install CentOS 5.5 i386 on an AMD Geode LX 800 processor.
Installing SL5 on AMD Geode LX80
http://wiki.keithl.com/index.cgi?SL5Alix
That processor, being of the much more recent i586 family, is fully i386- compatible. However, my attempt was brutally shattered when I had to
"brutally shattered" - What does that mean? Maybe a thermal issue ?)
This is more of a general issue. i386 does not generally refer to "whatever x86-compatible processor is the most recent" but a very well defined and standardized architecture. Specifically, i386 refers to Intels 80386 processor and its 32-bit x86 architecture (which is why x86 are i386 are often used interchangeably when x86 should instead be referring to the 8086 architecture). Code that claims to be i386 compatible has to run on any given microprocessor that claims to be i386 compatible. It's as simple as that: if it doesn't run on i386 processors then it's not i386 compatible. That's industry standard and thus universally valid. If one would claim i386 compatibility but require a x86_64 compatible processor, which of course would be capable of executing standard i386 code, it'd be the exact same issue. It'd be more radical but at its core not different from CentOS's unmet claim of i386 copmpatibility.
I guess my question is thus quite simple: why does CentOS 5 claim to be i386 when it's not even remotely i386 compatible? And shouldn't the name reflect code and/or processor family compatibility and affiliation?
And in a closely related question of more personal interest: what exactly is it that makes CentOS require an i686 processor?
Thanks, Martin
Sorry Martin but the rest reads like a pressure blowout.
Sincerely
PM
On Mon, 13 Dec 2010 01:09:00 +0100 Paulo Martinez wrote:
Installing SL5 on AMD Geode LX80
Thanks, but I've already installed CentOS 4.8 which does support i586.
Sorry Martin but the rest reads like a pressure blowout.
It's not. It's just a general wondering as to why one would refer to something as i386 when in reality it's i686 instead. I for one can't understand the logic behind it, that's all. No hard feelings, no pressure blowout whatsoever.
Regards, Martin
On Mon, 13 Dec 2010, Martin Jungowski wrote:
It's not. It's just a general wondering as to why one would refer to something as i386 when in reality it's i686 instead.
You should ask Red Hat. You're wasting your time (and ours) asking here.
-
Akemi Yagi -
Alan Bartlett -
Charlie Brady -
Jeff Johnson -
Martin Jungowski -
Paulo Martinez -
Peter A -
Ross Walker -
Timo Schoeler