Unterschiede zwischen AMD64 und IA-32e

Vor zwei Wochen erst hat Intel angekündigt, noch im ersten Halbjahr 2004 x86-Prozessoren mit 64-Bit Erweiterungen auf den Markt zu bringen (wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077047899">berichteten</a>). Den Anfang soll dabei der Xeon-Prozessor auf Prescott-Basis mit Codenamen Nocona machen. Intel nennt den "neuen" Befehlssatz IA-32e.

In den darauf folgenden Tagen wurde viel über Intels 64-Bit Implementierung <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077793224">diskutiert</a>. Denn obwohl IA-32e im Grunde identisch ist mit AMDs x86-64 Befehlssatz bzw. dem AMD64-Feature und Intel die Technologie bei AMD lizenziert hat, ist in der Präsentation nirgendwo davon zu lesen, dass es sich nur um eine Eigeninterpretation eines AMD-Befehlssatzes handelt. Auch Linux-Chef Linus Tovalds hat dieser Umstand bereits <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077746093">auf die Palme gebracht</a>. Womöglich hat sich AMD keinen Gefallen getan, den Befehlssatz Mitte 2003 von "x86-64" in "AMD64" umzutaufen. x86-64 als gemeinsamer Nenner wäre Intel womöglich leichter über die Lippen gegangen, als auf die Xeon-Verpackungen "compatible with AMD64" zu drucken.

Aber wie auch immer: inzwischen haben Linux-Programmierer den "neuen" Intel IA-32e Befehlssatz <a href="http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/0276.html" TARGET="b">unter die Lupe genommen</a>. Obwohl der Befehlssatz und die Betriebsmodi weitestgehend identisch sind, gibt es doch ein paar kleine Unterschiede. So unterstützt IA-32e beispielsweise das <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077715275">Date-Execution Prevention Feature</A> nicht (NX), welches AMD und Microsoft kürzlich vorgestellt haben. Kunden mit AMD 64-Bit Prozessoren sollen damit besser vor Viren geschützt werden, die sich einen Pufferüberlauf zu Nutze machen wollen, um schädlichen Code ausführen zu können. Logischerweise unterstützt IA-32e auch die 3DNow! Befehle nicht, die auch in den 64-Bit AMD-Prozessoren noch immer zu finden sind. Und noch etliche Kleinigkeiten wie <i>"IA-32e always saves all of the FP state on FXSAVE/FXRSTOR. Does not support FXSAVE/FXRSTOR with reduced FP state"</i> gilt es zu erwähnen.

System-Programmierer und Compiler-Bauer müssen nun Obacht geben. Bisher mussten die Entwickler nur mit einer Art von Prozessor rechnen, sofern sie im 64-Bit x86 Modus programmierten: mit einem AMD K8-Hammer (ob Opteron oder Athlon 64 spielt dabei keine Rolle). Nun jedoch gilt es wieder wie bisher bei den 32-Bit Prozessoren von Intel und AMD zwischen verschiedenen CPU-Architekturen und deren kleinen Besonderheiten bei der Implementierung des ein oder anderen Befehls zu unterscheiden. Da ist Nachsitzen gefragt! Womöglich mit ein Grund, weshalb das 64-Bit Windows von Microsoft noch immer nicht als Final auf dem Markt ist. Ursprünglich sollte es mit dem Athlon 64 zusammen gelauncht werden, der bereits im September 2003 <a href="http://www.planet3dnow.de/artikel/hardware/a64/index.shtml">eingeführt</A> wurde...
THX Alex für den Hinweis

Hm, Software konsequent auf AMD64 trimmen und damit intel mal zeigen, das auch sie sich mal an quasi standarts halten sollen.

Tolle Arbeit Intel...
Ich sehe es kommen, Intels "64 Bit Standard" wird sich durchsetzen, und die AMD User gucken mal wieder in die Röhre...

MfG 8)

Original geschrieben von James Ryan
Tolle Arbeit Intel...
Ich sehe es kommen, Intels "64 Bit Standard" wird sich durchsetzen, und die AMD User gucken mal wieder in die Röhre...

MfG 8)

Zum Vergrößern anklicken....

Wieso sollten die AMD User in die Röhre schauen. Soweit ich das gelesen habe können die Intel 64Bit (irgendwie streubt sich was in mir das so zu bezeichnen) weniger als die AMD64.
Eigentlich hat Intel seine AMD64 Befehle doch nur um einige Funktionen beschnitten.

Zu Intels-Regierungszeiten war es Intels Politik alle CPU's die nicht soviel konnten wie die eigenen als incompatible zu bezeichnen. Wieso sollte das AMD nicht auch können.

Ich denke das ist nen dummer Zug von Intel, mit dem sie sich wiedereinmal selber ins Fleich schneiden.
Vorallem wenn man bedenkt das ihre neuen Chipsets DDR2 unterstützen und auf Grund deren Preisstruktur wohl nicht so schnell eine so große Marktdurchdringung bei AMD64 erreichen wird wie AMD, bei denen in jedem HomePC durch den A64 jetzt diese Befehle schon den Markt erobern.

Original geschrieben von Nero24
Womöglich mit ein Grund, weshalb das 64-Bit Windows von Microsoft noch immer nicht als Final auf dem Markt ist.

Zum Vergrößern anklicken....

Ich vermute mal eher, das liegt an den biarch-Eigenschaften von AMD64. Gerade DirectX, Grafiktreiber und dergleichen dürften da Probleme bereiten.

Original geschrieben von Tigershark78
Wieso sollten die AMD User in die Röhre schauen. Soweit ich das gelesen habe können die Intel 64Bit (irgendwie streubt sich was in mir das so zu bezeichnen) weniger als die AMD64.
Eigentlich hat Intel seine AMD64 Befehle doch nur um einige Funktionen beschnitten.

Zu Intels-Regierungszeiten war es Intels Politik alle CPU's die nicht soviel konnten wie die eigenen als incompatible zu bezeichnen. Wieso sollte das AMD nicht auch können.

Ich denke das ist nen dummer Zug von Intel, mit dem sie sich wiedereinmal selber ins Fleich schneiden.
Vorallem wenn man bedenkt das ihre neuen Chipsets DDR2 unterstützen und auf Grund deren Preisstruktur wohl nicht so schnell eine so große Marktdurchdringung bei AMD64 erreichen wird wie AMD, bei denen in jedem HomePC durch den A64 jetzt diese Befehle schon den Markt erobern.

Zum Vergrößern anklicken....

Mit "AMD User können dann wieder in die Röhre schauen" meinte ich, dass Teile vom A64 einfach brach liegen werden, sollte sich Intels "Standard" durchsetzen (was beim Marktführer eigentlich nicht verwundern dürfte).
Sprich: Die K8 CPUs könnten zwar mehr, wenn die Software dass aber nicht nutzt liegen die Teile brach welche Intel nicht mit eingebaut hat.

MfG 8)

Vielleicht geht Intels Rechnung doch auf..
hoffe ich mal nicht..

neuer prescott launch vor veröffentlichung des ms 64bits..

wer will schon neues os kaufen ..

siehe MS bringt Windows Xp Reloaded.. hui
wer sollte den da noch das original XP in 64 Bit kaufen wenn ich die 2. ausgabe in 32 bit haben kann?

Dann gibts ja noch herr Dau der jeden Samstag in den Media Makrt geht.

1. Mhh AMD 64bit?
2. Ah intel 32 Bit
3. Xp Reloaded (Hey Krasser Film Matrix Karate Voll Brontal)
4. 32 Bit mhhh
5. Intel bitte und Xp Reloaded


Jetzt nur noch die Frage ob es auch ein XP Reloaded in 64 Bit gibt..
und hey hey.. MS macht SP2 und Reloaded klar das da AMD auf der Strecke bleibt.

Original geschrieben von James Ryan
Mit "AMD User können dann wieder in die Röhre schauen" meinte ich, dass Teile vom A64 einfach brach liegen werden, sollte sich Intels "Standard" durchsetzen (was beim Marktführer eigentlich nicht verwundern dürfte).
Sprich: Die K8 CPUs könnten zwar mehr, wenn die Software dass aber nicht nutzt liegen die Teile brach welche Intel nicht mit eingebaut hat.

MfG 8)

Zum Vergrößern anklicken....

Also zumindest das NX-Flag wird MS nutzen, da bin ich mir sicher. Ich glaube zwar nicht, dass ihnen das gross helfen wird, aber sie werden es erst einmal versuchen. Was der FXSAVE/FXRSTOR-Teil soll weiß ich zwar auch noch nicht so genau, aber ich glaube kaum, dass AMD hier ein Nachteil erwachsen wird.

Ich kann den Code zwar nicht analysieren, hätte aber ein paar Fragen:

Gibt es bei den µ-Befehlen einige, die prinzipiell besser in die Architektur der kurzen AMD Pipeline passen und somit von Intel mit den HT Konzept gescheut werden - wie der Teufel das Weihwasser?

Original geschrieben von Friday69
Jetzt nur noch die Frage ob es auch ein XP Reloaded in 64 Bit gibt..

Zum Vergrößern anklicken....

Wenn das original XP für AMD64 schon auf dem Stand von Reloaded ist, was will man dann noch nachladen?

das wäre natürlich auch eine antwort..

kurz gesagt das beste.. und für mich der allererste grund ein solches windows legal zu erwerben.. und dann noch XP

Intel Xeon: "compatible with AMD64"

Das wäre ja mal was...!

Hmmm das NX Feature bei intel eben nicht eingebaut?

Und dies, obwohl MS in jüngster Zeit verstärkt Sicherheit als Thema für sich entdeckt? ...

Tsch... Tsch... Tsch... da fährt glaube ich der Zug ohne intel ab. Und im Workstationsektor/Serversektor dürfte dies noch viel wichtiger sein. Dort zählt Sicherheit mehr, als die ultimative Geschwindigkeit.

Kann jemand erzählen was

"IA-32e always saves all of the FP state on FXSAVE/FXRSTOR. Does not support FXSAVE/FXRSTOR with reduced FP state"

Zum Vergrößern anklicken....

genau bedeutet?

Allerdings halte ich diese Einschränkung für unbedeutend solange die Entwicklerbasis von Intel bei 0 ist.

AMD hat ja schon mehr als 100.000 Argumente auf dem Markt, abgesehen davon, dass praktisch alle wesentlichen Firmen Unterstützung für AMD64 gegeben haben.

Ist bekannt wer denn auch schon Unterstützung für die Intelvariante gegeben hat (ausser MS)?
Normalerweise kommen solche Launches immer auch mit einer Handvoll Fremdentwickler ... da war aber eigentlich Sendepause

MFG Bokill

Hehe Intel Prozessor mit aufdruck AMD64 compatible, hrhr das wär echt was. Aber das wird nie kommen. Aber die technik von AMD als eigene zu verkaufen, das ne echtes Stück. Aber bei denen wundert mich nix mehr.

So unterstützt IA-32e beispielsweise das Date-Execution Prevention Feature nicht (NX), welches AMD und Microsoft kürzlich vorgestellt haben

Zum Vergrößern anklicken....

Heißt NX nicht No Execution Prevention Feature? Ist das nen Tippfehler oder bin ich unterinformiert?
Aber mich würde es auch interessieren was das FP dings wie Bokill schon gefragt hat genau auf sich hat.

Mfg maex

Original geschrieben von maex Aber die technik von AMD als eigene zu verkaufen, das ne echtes Stück. Aber bei denen wundert mich nix mehr.[/B]

Zum Vergrößern anklicken....

Sagt dir der Intel Opteron was ?

Original geschrieben von maex
Heißt NX nicht No Execution Prevention Feature? Ist das nen Tippfehler oder bin ich unterinformiert?

Zum Vergrößern anklicken....

Nein, NX heißt einfach nur No-Execution. So heißt z.B. auch das zugehörige Flag. MS und AMD vermarkten das Feature jedoch unter der Bezeichnung "Data-Execution Prevention Feature". Im Endeffekt ist es aber das selbe

Weitere Infos zu Intel & NX gerade per eMail bekommen (THX @Siegfried)

Subject: OpenBSD/amd64 on new Intel hardware


> So we've had OpenBSD/amd64 tested on not-yet-released Intel ia32e
> hardware. That's the new Intel hardware that has the AMD64
> instructions added.
>
> And the boot floppy works ...
>
> Of course, it is working without W^X protection. This is because
> Intel decided against adding the MMU page table bit for NXE -- per
> page non-execute. On most processors this is about 180 logic gates to
> block loading of ptes which have NXE set into the ITLB (and cause a
> fault instead).
>
> In 64 bit mode, of course, the processor architecture entirely lacks
> segmentation, so i386 trick with the CS limit is not possible.
>
> Intel might have some hidden non-executable feature that we are not
> yet aware of, but that is the entire problem with Intel: Secrecy,
> secrecy, fucking bullshit secrecy.
>
> Therefore, if anyone is unfortunate and gets their hands on one of
> these, I might urge you to run OpenBSD/i386 on it instead.
> OpenBSD/i386 has the standard CS-limit W^X protection. But the way we
> see it now, Intel crippled their processor by making it IMPOSSIBLE to
> make tag memory as non-executable in 64 bit mode.
>
> On the other hand, OpenBSD/amd64 on our AMD cpus are doing W^X just
> fine.
>
> Apparently Intel cloned the entire AMD64 architecture but missed out
> on a very small but crucially important piece.

Zum Vergrößern anklicken....

Tsch... Tsch... Tsch...

good bye intel

MFG Bokill

@PapaSchlumpf - ach, ich meine doch Nero

Was ist eigentlich dieses "CS" in deiner Mail?

Original geschrieben von Seemann
@PapaSchlumpf - ach, ich meine doch Nero

Was ist eigentlich dieses "CS" in deiner Mail?

Zum Vergrößern anklicken....

Code Segment

Ich gewinnne immer mehr den Eindruck, das Intel ein ganz schlechter Verlierer ist

Original geschrieben von Todiefor
Ich gewinnne immer mehr den Eindruck, das Intel ein ganz schlechter Verlierer ist

Zum Vergrößern anklicken....

Überleg mal wie du dich verhalten würdest, wenn du jahrelang den Ton angeben würdest, und plötzlich zieht dein Nebenbuhler an dir vorbei und über nimmt die Führung. Irgendwo ist das Verhalten schon logisch.

Intel sitzt in der Ecke und schmollt.
Der Branchenprimus hat sich eben auf sein Quasimonopol ausgeruht und will jetzt nicht anerkennen, das der ewig Zweite ihnen die Show gestohlen hat.

Ne Ne ich denke noch.. "im bezug auf noch"
fühlt sich Intel sicher.
ich meine immerhin haben sie noch 80%.. sehen wir Ende Jahr weiter.. da gehts dann erst richtig los mit der Schlacht.

@James Ryan
> Ich sehe es kommen, Intels "64 Bit Standard" wird sich durchsetzen, und die AMD User gucken mal wieder in die Röhre...

Keine Sorge, denn:

1) NX Feature: Solange Intel es nicht Anbietet ein klarer Vorteil für AMD

2) Kein reduced FP state unter IA-32e FXSAVE/FXRSTOR. Ziemlich irrelevant. Diese Befehle werden v.a. vom OS bei Prozesswechsel zum sichern des Media Kontexts verwendet, dort will man aber immer den vollständigen Kontext sichern/widerherstellen. Ich kenne keine normale Anwendung in der es Sinn macht den FP/SSE Kontext zu sichern.

3) Fast System Calls (SYSENTER/SYSEXIT, SYSCALL/SYSRET): Solange das OS SYSENTER/SYSEXIT für Legacay Mode und SYSCALL/SYSRET im Compatibility/64-Bit Mode verwendet funktioniert der gleiche Code auf beiden Prozessoren. Das ist übrigens sowieso die "natürliche" Nutzung dieser Befehle, weil sie dann optimal eingesetzt werden. BTW. Für den normalen Programmierer spielt das auch wider keine Rolle, denn das OS alleine entscheidet wie es seine Schnittstellen realisiert. D.h. ein Anwenderprogramm springt nur in Stubs, die dann den OS Call ausführen.

4) Operand Size Overide Prefix bei near Jumps: Irrelevant, denn warum sollte ein Compiler ein Prefix generieren, das keinen Vorteil bringt und nur den Code aufbläht. So gesehen wird das verhalten von AMD CPUs in diesem speziellen Fall kein Problem werden

5) Grabage in upper 32 Bit of 64 Bit Register when BSR/BSR on source=0 with 32 bit operand size: Auch kein wirkliches Problem, denn vernünftiger Code prüft das ZF Flag sowieso, denn sonst ließe sich "Bit 0 gesetzt" nicht von "kein Bit gesetzt" unterscheiden. Ich wette fast darauf das die Compiler genau das jetzt schon machen.

Kurz: die Unterschiede sind nur für OS-Entwickler von Interesse, aber die müssen schon auf Grund der verschiedenen MSRs viel mehr unterscheiden. Normal-Programierer werden davon nichts mitbekommen. Darum sind die Ängste von wegen zwei verschiedenen Entwicklungsrichtungen für x86-64 unberechtigt.