Bereits vor einigen Wochen haben wir in einer ausführlichen Meldung erläutert, dass die 64-Bit Erweiterungen des x86-Befehlssatzes von AMD und Intel offenbar nicht 100-prozentig kompatibel sind, es also feine Unterschiede - in der Implementierung sowieso - aber auch im Resultat gibt; und das, obwohl AMD64 alias x86-64 (im April 2003 vorgestellt) und EM64T alias IA-32e (letzten Montag vorgestellt) eigentlich softwarekompatibel sein sollten.
Inzwischen hat Intel den 64-Bit Xeon mit Nocona-Kern vorgestellt (wir berichteten) und da es sich um eine Workstation-CPU handelt, die zusammen mit einem brandneuen PCI-Express Mainboard verkauft werden soll und mit einem Betriebssystem (Windows XP 64-Bit Edition) arbeitet, das noch gar nicht auf dem Markt ist, war die Anzahl an Reviews zur Markteinführung natürlich nahe Null. Lediglich ein paar "Big Player" unter den Hardware-Magazinen wie INQ haben versucht, ein Review rechtzeitig zum Launch anzufertigen - und stießen dabei auf zahlreiche Probleme, die bisher nicht zu lösen waren.
Man versuchte das 64-Bit Windows für den Opteron, welches man kostenlos als Preview bei Microsoft herunterladen kann, auf dem Xeon Nocona zum Laufen zu bringen. Allerdings stürzte das System bereits bei der Installation nach der Einbindung der SCSI-Treiber ab. Recherchen bei Microsoft ergaben, dass die Preview-Version zwar für den AMD Opteron und den Athlon 64 freigegeben sei, nicht jedoch für den 64-Bit Intel Xeon.
Nachdem Microsoft offenbar noch nicht so weit ist, lag die Alternative nahe, den Nocona mit einem 64-Bit Linux zu testen, das bereits seit dem Opteron-Launch im April 2003 verfügbar ist und mittlerweile Zeit hatte zu reifen. Da es schnell gehen musste, nahm man die Knoppix-Version, die von CD gebootet werden kann. Zu allem Erstaunen des Autors jedoch verweigerte Knoppix den Start mit der Meldung, dass der 64-Bit Long-Mode nicht unterstützt würde und man stattdessen eine 32-Bit Distribution verwenden solle.
Weitere Informationen zu dieser Problematik fand der Autor bei Red Hat, wo man sich bereits mit der Anpassung an EM64T befasst hatte. Dort ist schwarz auf weiß zu lesen, wo das Problem bei Intels 64-Bit Umsetzung liegt:
"Software IOTLB — Intel® EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel® EM64T as compared to AMD64 processors
In Anbetracht dessen kann man sicher sagen, dass EM64T und AMD64 nicht softwarekompatibel sind, was den Entwicklern und Compilerbauern sicherlich noch etliche schlaflose Nächte bereiten wird! Autor Andrew Miller verleitete der Status-Quo zu der Aussage, Intels 64-Bit Erweiterung erinnere ihn an einen "hack job". Das erklärt allerdings auch, weshalb sich Microsofts 64-Bit Windows erneut verzögert und nun erst im Q4 2004 erscheinen soll (wir berichteten). Im Gegensatz zum offenen Linux, was praktisch fließend durch das Open-Source Konzept reift, muss Microsoft dafür sorgen, dass Windows "out-of-the-box" mit beiden Umsetzungen der 64-Bit x86-Erweiterungen zurecht kommt.
Um einen ähnlichen Fall wie diesen zu finden, wo ein Betriebssystem mit einem auf dem Papier augenscheinlich kompatiblen Prozessor nicht arbeiten konnte, muss man weit zurückgehen - und selbst hier ist der Fall nicht wirklich vergleichbar. Als AMD Ende der 90er Jahre den K6-2 Kern mit CXT-Core vorstellt, weigerte sich Windows 95B/C damit zu booten. Grund war damals, dass Microsoft eine Zeitverzögerungschleife, die das System benötigte, um die Geräte zu erkennen, mit dem LOOP-Befehl umgesetzt hatte - unter der Annahme, dass der Prozessor genügend Zeit dafür brauchen würde, um alle Geräte erkennen zu können. Da AMD jedoch beim K6 den LOOP-Befehl "in Hardware" verdrahtet hatte, war das System ab 350 MHz mit der Schleife schon fertig, bevor das Betriebssystem alle Geräte initialisieren konnte und das System stürzte ab. Microsoft bot dafür einen Patch an. Allerdings war es in diesem Fall keine echte Inkompatibilität, sondern schlampige Programmierung bei Microsoft. Beweis: auch der Pentium 4 ab 2.0 GHz ist schnell genug, um Microsofts Zeitschleife schneller als erlaubt zu "durchloopen" (wir berichteten). Kein Vergleich also mit den jetzt entdeckten echten Inkompatibilitäten zwischen AMD64 und EM64T...
Diesen Artikel bookmarken oder senden an ...