Re: IA32e==AMD64 (but Intel doesn't want you to know that)

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--

On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez
<> 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

Xose Vazquez Perez <> 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.

RusH <> 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?

RusH wrote:
> Xose Vazquez Perez <> 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.)

On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <>
wrote:
>On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez
><> 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

In article <>,
lid says...
> RusH <> 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

On Wed, 25 Feb 2004 14:18:20 GMT, Tony Hill <>
wrote:

>On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <>
>wrote:
>>On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez
>><> 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

Doesn't Intel invest in LINUX flavors... specifically Redhat?


"Robert Myers" <> wrote in message
news:...
> On Wed, 25 Feb 2004 14:18:20 GMT, Tony Hill <>
> wrote:
>
> >On Tue, 24 Feb 2004 23:34:31 -0500, Robert Myers <>
> >wrote:
> >>On Wed, 25 Feb 2004 01:33:00 +0100, Xose Vazquez Perez
> >><> 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
>
>

On Wed, 25 Feb 2004 10:35:57 -0700, "Judd" <>
wrote:

>Doesn't Intel invest in LINUX flavors... specifically Redhat?
>

Don't know about RedHat, but Intel has a significant stake in
MontaVista Linux, which, were I Microsoft, I would find very
threatening.

Intel isn't hostile to Linux. It plainly puts money into Linux.

Given the way that Linux fits so nicely into Intel's commodity
hardware model, though, it seems like a faux pas that they would have
left Linus with his feathers ruffled at a time when they don't need
someone like him saying critical things. That's all.

RM