PC Review
Forums
Newsgroups
Hardware
Processors
IA32e==AMD64 (but Intel doesn't want you to know that)
Forums
Newsgroups
Hardware
Processors
IA32e==AMD64 (but Intel doesn't want you to know that)
![]() |
IA32e==AMD64 (but Intel doesn't want you to know that) |
|
|
Thread Tools | Rate Thread |
|
|
#1 |
|
Guest
Posts: n/a
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 http://kerneltrap.org/node/view/2466 With Intel's recent announcement of the 64-bit extension to their x86 architecture, a discussion began on the lkml comparing Intel's new offering to AMD's existing AMD64 offering. Linux creator Linus Torvalds expressed extreme annoyance that AMD's involvement in developing this new technology was not mentioned. The Linux kernel will refer to both 64-bit x86 technologies as x86-64, though Linus suggested, "actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in their documentation or their releases, so I'd almost be inclined to rename the thing as 'AMD64' just to give credit where credit is due. However, it's just not worth the pain and confusion." Linus went on to clarify: "What I found so irritating is that _hours_ after the Intel announcement, people were _still_ confused about whether the new intel chip was actually compatible with AMD's chips. Why the f*ck not just come out and say so, and talk about it? It took people actually reading the manuals (which didn't mention it either) to convince some people on the architecture newsgroups that yes, 'ia32e' was really the same as 'amd64' except in the small details that have always set Intel and AMD apart." The only difference appears to be that AMD64 supports 3DNow! and IA32e supports something called SSE3. Everything else (which is all that most apps would use anyway) is the same between them. It seems rather small of Intel that it would try to obfuscate the origins of what it's calling IA32e. _/_ Scott Alfter (address in header doesn't receive mail) / v \ send mail to $firstname@$lastname.us (IIGS( http://alfter.us/ Top-posting! \_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Linux) iD8DBQFAO8A/VgTKos01OwkRAnBGAJwNOh3G3DNj77AJYc1g+Mma4/uCFACfeaxA nZuYaM2U6ldL/kN3zZpyjf0= =sHRc -----END PGP SIGNATURE----- |
|
|
|
#2 |
|
Guest
Posts: n/a
|
Scott Alfter wrote:
> The only difference appears to be that AMD64 supports 3DNow! and IA32e > supports something called SSE3. Everything else (which is all that most > apps would use anyway) is the same between them. It seems rather small of > Intel that it would try to obfuscate the origins of what it's calling IA32e. An Intel guy, "Nakajima, Jun" <jun.nakajima () intel ! com>, wrote in linux-kernel: --cut-- Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced SpeedStep, etc.), there are few differences between the implementations of IA-32e and AMD64. The software visible ones are: Fast system calls: Syscall/sysret is supported only in 64-bit mode (not in compatibility mode). Sysenter/Sysexit is supported in both 64-bit and compatible mode. CPUID: If you look at Table 2-8 of Volume 1, you will find IA-32e specific things, including, GenuineIntel, HT, SSE3, monitor/mwait, Intel Enhanced SpeedStep, and cmpxchg16b. The function 8000_0001h doesn't duplicate standard-feature bits from function 1 in EDX. It sets only the new features that are implemented. MSRs: Not all MSRs are architectural, and IA-32e does not implement SYSCFG, TOP_MEM, TOP_MEM2, for example. MSR usage should be vendor specific and be guarded with CPUID.Model Fast-FXSAVE/FXRSTOR: IA-32e always saves all of the FP state on FXSAVE/FXRSTOR. Does not support FXSAVE/FXRSTOR with reduced FP state. Microcode Update: IA-32e supports microcode update as the 32-bit mode does, as you already found the discussions in the mailing list. NX (No-Execute) bit: Initial implementation will not support the NX bit. BSF/BSR when source is 0 & operand size is 32: In 64-bit mode, the processor sets ZF, and the upper 32 bits of the destination are undefined. Should always check the ZF or do not use 32-bit operand size. Near branch with 66H prefix: As documented in PRM the behavior is implementation specific and should avoid using 66H prefix on near branches. Not supported in IA-32e ======================= 3DNow instructions (including prefecthw or prefetch with the opcode 0f 0d) Thanks, Jun --end-- |
|
|
|
#3 |
|
Guest
Posts: n/a
|
On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez
<xoseDELETE@wanadoo.es> wrote: >Scott Alfter wrote: > >> The only difference appears to be that AMD64 supports 3DNow! and IA32e >> supports something called SSE3. Everything else (which is all that most >> apps would use anyway) is the same between them. It seems rather small of >> Intel that it would try to obfuscate the origins of what it's calling IA32e. > >An Intel guy, "Nakajima, Jun" <jun.nakajima () intel ! com>, >wrote in linux-kernel: > >--cut-- >Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced >SpeedStep, etc.), there are few differences between the implementations >of IA-32e and AMD64. The software visible ones are: > <snip> Thanks for passing that along. Linus surely had to be aware that there were software-visible differences and had to be consulted about how they would be handled. Would his life be made any easier by confusing two nearly-identical but nevertheless slightly different ISA's? Bizarre. RM |
|
|
|
#4 |
|
Guest
Posts: n/a
|
Xose Vazquez Perez <xoseDELETE@wanadoo.es> wrote :
[cut the part how they cant deliver] this is funny : > NX (No-Execute) bit: > Initial implementation will not support the NX bit. this is one of those literally few things statistical luzer would benefit most from. [cut the part how they cant deliver] So basically this Intel guy said "Intel implementation of AMD64 is HEAVY Handicapped". At least he is a honest man. woohoo Pozdrawiam. -- RusH // http://pulse.pdi.net/~rush/qv30/ Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know -- UNTIL IT'S TOO LATE. |
|
|
|
#5 |
|
Guest
Posts: n/a
|
RusH <rush@pulse.pdi.net> wrote:
>So basically this Intel guy said "Intel implementation of AMD64 is >HEAVY Handicapped". At least he is a honest man. >woohoo Okay, let's pretend for a moment that we aren't all CPU and/or kernel experts who understand the impact of the differences outlined. 8) Is the Intel part really significantly handicapped compared to the AMD? If so, considering the fact that software will have to run on both AMD and Intel, will this negatively impact the performance of software that is written for the 64-bit chips? |
|
|
|
#6 |
|
Guest
Posts: n/a
|
RusH wrote:
> Xose Vazquez Perez <xoseDELETE@wanadoo.es> wrote : > > [cut the part how they cant deliver] > > this is funny : > > >>NX (No-Execute) bit: >> Initial implementation will not support the NX bit. > > > this is one of those literally few things statistical luzer would > benefit most from. > > [cut the part how they cant deliver] > > So basically this Intel guy said "Intel implementation of AMD64 is > HEAVY Handicapped". At least he is a honest man. > woohoo > > Pozdrawiam. Boy are you biased. I read a laundry list of very minor differences, half of which are things I thought were always different between processors, such as CPUID and MSRs. You somehow got "HEAVY Handicapped" out of it. What's the opposite delusion of "rose-colored glasses"? You suffer from that. Alex -- My words are my own. They represent no other; they belong to no other. Don't read anything into them or you may be required to compensate me for violation of copyright. (I do not speak for my employer.) |
|
|
|
#7 |
|
Guest
Posts: n/a
|
On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <rmyers@rustuck.com>
wrote: >On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez ><xoseDELETE@wanadoo.es> wrote: >>Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced >>SpeedStep, etc.), there are few differences between the implementations >>of IA-32e and AMD64. The software visible ones are: > >Thanks for passing that along. Linus surely had to be aware that >there were software-visible differences and had to be consulted about >how they would be handled. Would his life be made any easier by >confusing two nearly-identical but nevertheless slightly different >ISA's? Bizarre. I doubt it, he's had to deal with it since the very beginning. The 486 was slightly different from the 386, the Pentium slightly different from both, the PPro/PII/PIII slightly different again and the Pentium 4 is different again. The Athlon follows the PPro/PII/PIII standard specification more closely than any of the others, but it's not identical there either. Cyrix had their own set of differences, as do the newer VIA chips, and I wouldn't even want to get into Transmeta (which very likely makes changes to the ISA based on which revision of the Code Morphing software is being used). The differences between Intel's x86-64 implementation and AMD's original AMD64 aren't really any more significant than the differences between existing IA-32 chips. Most of the stuff is only encountered at the low-level of the kernel or while doing some pretty intense optimizations, and they can be checked by using CPUID. ------------- Tony Hill hilla <underscore> 20 <at> yahoo <dot> ca |
|
|
|
#8 |
|
Guest
Posts: n/a
|
In article <b09p3018mekknr5bvgcm21gp99217ec53c@4ax.com>,
chrisv@nospam.invalid says... > RusH <rush@pulse.pdi.net> wrote: > > >So basically this Intel guy said "Intel implementation of AMD64 is > >HEAVY Handicapped". At least he is a honest man. > >woohoo > > Okay, let's pretend for a moment that we aren't all CPU and/or kernel > experts who understand the impact of the differences outlined. 8) > > Is the Intel part really significantly handicapped compared to the > AMD? If so, considering the fact that software will have to run on > both AMD and Intel, will this negatively impact the performance of > software that is written for the 64-bit chips? I would guess that the lack of the NX bit wouldn't cause software to break, since all pages would be executable (even those marked otherwise). However, the lack of the NX bit would seem to mean that various viri would prefer the Intel host than the AMD host. ;-) -- Keith |
|
|
|
#9 |
|
Guest
Posts: n/a
|
On Wed, 25 Feb 2004 14:18:20 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote: >On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <rmyers@rustuck.com> >wrote: >>On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez >><xoseDELETE@wanadoo.es> wrote: >>>Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced >>>SpeedStep, etc.), there are few differences between the implementations >>>of IA-32e and AMD64. The software visible ones are: >> >>Thanks for passing that along. Linus surely had to be aware that >>there were software-visible differences and had to be consulted about >>how they would be handled. Would his life be made any easier by >>confusing two nearly-identical but nevertheless slightly different >>ISA's? Bizarre. > >I doubt it, Did Intel consult Linus or give him any kind of courtesy notice? Plainly not, and in failing to do so, they missed an opportunity. Intel had to have consulted Microsoft. Even if Intel had a full set of source code (and who knows), they wouldn't know what might be cooking and what kinds of problems small discrepancies might cause. No need to consult the open source community, because it's all, um, open. Not just the source code, but the entire process. From a practical point of view, Intel could afford to ignore Linus. As a matter of public relations, it was a blunder. Linus, showing that he, too, is human, is exacting his pound of flesh. >...he's had to deal with it since the very beginning. Which is why his current statements sound more like resentment than anything else. You know that, as soon as the actual documentation became available, he and his colleagues started scouring it for potential problems, and I find it hard to believe that, with so much high-quality gray matter at his disposal, he and his colleagues would have missed anything. It would be nice to think that Intel would notice the potential lesson and internalize it, to both the benefit of Intel and Linux, but that's probably hoping for too much. RM |
|
|
|
#10 |
|
Guest
Posts: n/a
|
Doesn't Intel invest in LINUX flavors... specifically Redhat?
"Robert Myers" <rmyers@rustuck.com> wrote in message news:vrkp30t1j676barmep9q6critahgnsg2uh@4ax.com... > On Wed, 25 Feb 2004 14:18:20 GMT, Tony Hill <hilla_nospam_20@yahoo.ca> > wrote: > > >On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <rmyers@rustuck.com> > >wrote: > >>On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez > >><xoseDELETE@wanadoo.es> wrote: > >>>Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced > >>>SpeedStep, etc.), there are few differences between the implementations > >>>of IA-32e and AMD64. The software visible ones are: > >> > >>Thanks for passing that along. Linus surely had to be aware that > >>there were software-visible differences and had to be consulted about > >>how they would be handled. Would his life be made any easier by > >>confusing two nearly-identical but nevertheless slightly different > >>ISA's? Bizarre. > > > >I doubt it, > > Did Intel consult Linus or give him any kind of courtesy notice? > Plainly not, and in failing to do so, they missed an opportunity. > > Intel had to have consulted Microsoft. Even if Intel had a full set > of source code (and who knows), they wouldn't know what might be > cooking and what kinds of problems small discrepancies might cause. > > No need to consult the open source community, because it's all, um, > open. Not just the source code, but the entire process. > > From a practical point of view, Intel could afford to ignore Linus. > As a matter of public relations, it was a blunder. Linus, showing > that he, too, is human, is exacting his pound of flesh. > > >...he's had to deal with it since the very beginning. > > Which is why his current statements sound more like resentment than > anything else. You know that, as soon as the actual documentation > became available, he and his colleagues started scouring it for > potential problems, and I find it hard to believe that, with so much > high-quality gray matter at his disposal, he and his colleagues would > have missed anything. > > It would be nice to think that Intel would notice the potential lesson > and internalize it, to both the benefit of Intel and Linux, but that's > probably hoping for too much. > > RM > > |
|
![]() |
|
| Thread Tools | |
| Rate This Thread | |
|
|

Main Page 

