Intel vs AMD x86-64

Kernel

Nemrég az Intel bejelentette az x86 architektúra 64 bites kiterjesztését. A kernel listán egy érdekes thread alakult ki ezzel kapcsolatban. A fejlesztők elkezdték összehasonlítani az Intel által bejelentett új kiterjesztést az AMD már meglevő AMD64 technológiájával.

Számos fejlesztő - köztük Linus - nemtetszését fejezte ki az Intel üzletpolitikájával kapcsolatban. Linus felháborítónak találta, hogy az Intel nem említi meg az AMD-t sem a dokumentációiban, sem a kiadásaiban. Többen kérdezték, hogy most, hogy az Intel is kijön a saját 64 bites anyagával, mi lesz az architektúra neve. Az eddig felmerült jelölések közül egy olyat kellene választani, amelyik mindegyik megoldást jól jellemzi. Az elnevezések, amelyek felmerültek: IA-64 - már foglalt, IA-32e (e, mint extension) - túl homályos, az AMD64 - túl általános, az x86-64 / x86_64-et túl nehéz leírni.

Linus írta, hogy kezd hajlani arra, hogy az egészet elnevezi AMD64 architektúrának (utalva az Intellel kapcsolatos elégedetlenségére).

Felmerült a kérdés, hogy vajon az Intel új processzorán, futnak-e majd az AMD64-re írt programok. Többen olvasták a dokumentációkat, de konkrét választ nem kaptak a kérdésre.

Erre Linus kifakadt, és azt írta, hogy számára irritáló, hogy órákkal az Intel bejelentése után az emberek még mindig bizonytalanok abban, hogy az Intel chip-je kompatibilis lesz-e az AMD chipjével. Arra a kérdésre keresték a választ, hogy vajon az Intel ``ia32e'' chipje ugyanaz-e, mint az ``amd64'', kivéve azokat a minimális különbségeket, amelyek mindig is megvoltak az Intel és az AMD processzorok között.

A thread vége fele Nakajima Jun, az Intel munkatársa eloszlatta a ködöt, és beidézte az Intel oldalán olvasható FAQ-t:

"Q9: Is it possible to write software that will run on Intel's processors

with 64-bit extension technology, and AMD's 64-bit capable processors?

A9: With both companies designing entirely different architectures, the

question is whether the operating system and software ported to each

processor will run on the other processor, and the answer is yes in most

cases."

Egyelőre itt tart az ügy, határozott döntés még nincs az architektúra nevét illetően.

Az érdekes thread itt kezdődik.

( tamaas | 2004. 02. 24., k – 15:16 )

Nem.

Tudtommal egy régebbi keresztlicensz megállapodás folytán kapták meg a felépítés leírását. Csak ezt elég nehéz nekik beismerni.
Az AMD-töl a nagy INTELnek valamit vennie kellett.

Gondolom nem cseng túl jól a köreikben.



Isten hozott a szép, új világban.



Üdv.: Tamaas

( kisindian | 2004. 02. 24., k – 15:21 )

Nezopont kerdese: mondhatnank azt is, hogy most az Intel tanult a konkurencia hibaibol es ugy alkotta az uj architecturat.

Tartok tole, hogy azert nem igy lesz :)

( trey | 2004. 02. 25., sze – 13:39 )

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)