| |
 |
| 64-Bit-Erweiterungen des Prescott inkompatibel mit AMD64? |
|
|
Veröffentlicht durch tbf am Dienstag 28. Oktober, 19:45
Aus der schmutzige-Tricks Abteilung
|
|
|
|
|
Gemäss X-bit Labs wird Intels Pentium-IV-Nachfolger (Codename "Prescott") definitiv 64-Bit-Befehle beherrschen. Vorerst sollen sie aber deaktiviert bleiben, um die erfolglose Itanium-Linie nicht noch mehr zu gefährden. Entgegen allen Spekulationen sollen die neuen Befehle aber nicht kompatibel zum AMD64-Befehlssatz des Opteron sein! (Gefunden durch The Register)
|
|
|
|
|
|
|
Die Gerüchte klingen erst mal recht plausibel, erlauben sie doch Intel kurzfristig mit AMD gleichzuziehen, sollte 64-Bit auf dem Desktopmarkt gefragter sein, als von Intels Analysten vorhergesehen: Geheimen Activator-Code publizieren, fertig. Maureen O'Gara, Quelle der gestrigen SuSE-Übernahmegerüchte, glaubt übrigens, dass Intel diesen Schritt bereits im ersten Halbjahr 2004 vollziehen wird.
Extrem hinterlistig wäre es aber, sollten die Befehle wirklich inkompatibel zu AMD64 sein: Per Patentaustausch hatte Intel vollen Zugriff auf die Erweiterungen. Argumentationen "man wolle nicht das Gesicht verlieren, indem man AMD-Technik implementiert" wirken fadenscheinig: Laut Intels Itanium-Marketingaussagen sind die x86-Prozessoren doch eh nur Spielkram.
Paranoid gesponnen sehe ich ja eine andere Variante: Microsoft sagte einst aus, für Windows XP/64 nur einen 64-Bit-Befehlssatz unterstützen zu wollen. AMD und Intel sollen sich gefälligst einigen, wenn sie 64-Bit in Windows XP haben wollen. Könnte es nicht auch so gelaufen sein, dass man Intel irgendwann zusagte in Windows XP/64 exklusiv die Prescott-Variante zu unterstützen? Wäre auf jeden Fall eine plausible Erklärung für die andauernden Verzögerungen beim Windows/AMD64-Port: Die im Vergleich zu Microsoft winzige SuSE AG schaffte den Linux-Port innerhalb weniger Wochen und die Microsoft-Compiler nerven mich seit Version 7.0 (anno 2002), wenn mein Code nicht 64-bit-kompatibel ist...
|
|
|
|
< US-Post will digitale Absenderidentifikation | Druckausgabe | Opie 1.0.2 erschienen > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
Von Anonymer Feigling am Wednesday 29. October, 01:30 MET (#1)
|
|
|
|
|
also die paranoide Ansicht ist mir nun wirklich, nun, zu paranoid. Die einzige Inkompatibilität die ich mir vorstellen könnte wäre dass intel keinen FPU-Code im 64bit Long-mode unterstützt, sondern nur SSE2 (das ist nämlich genau das was die x86-64 Version von XP nicht kann, obwohl der Athlon 64 keine Probleme damit hat, und normalerweise auch erst noch genau so schnell wie mit SSE2-Code ist). Im Gegensatz dazu ist die FPU (bzw. der FPU-Decoder) beim P4 eine ziemliche Krücke, intel hat da offensichtlich massiv gespart und hofft darauf dass alle SSE2 verwenden.
Aber diese Gerüchte mit den zuschaltbaren 64bit Features halte ich trotzdem für ausgemachten Blödsinn, da sie aber immer wieder auftauchen vermute ich FUD von intel gesteuert.
Tejas (der soll ja bloss ein halbes Jahr später als Prescott erscheinen) hingegen könnte sehr wohl x86-64 kompatibel sein - persönlich vermute ich sogar das wird der Fall sein, auch wenn's intel natürlich zum jetzigen Zeitpunkt nie zugeben würde...
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 29. October, 02:11 MET (#2)
|
|
|
|
|
um das zu präzisieren: dass Prescott 64bit Erweiterungen enthält halte ich nicht für gänzlich ausgeschlossen, bloss dass die später per Software aktiviert werden können - aber davon ist ja eigentlich auch gar keine Rede in der verlinkten Story, also kein FUD von intel, bloss ein Story poster mit Fantasie.
Schliesslich enthalten die Willamette-P4 auch schon HT, mit Einschalten ist da aber ebenfalls nix...
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 29. October, 14:38 MET (#4)
|
|
|
|
|
technisch möglich wäre das sicher, aber für intel macht das doch keinen Sinn - schliesslich wollen die neue CPUs verkaufen, und nicht nachträglich ein Feature das offiziell gar nie existierte freischalten, das bringt doch keine $ in die Kasse.
Abgesehen davon wären mindestens in den ersten CPU-Steppings wohl ein paar Bugs zu viel zu erwarten (da zuwenig getestet). HT das ja bei den ersten P4 Xeons schon aktiviert war, hatte anfangs einen relativ grossen Performanceverlust bei typischem Desktop-Einsatz zur Folge (wohl mit ein Grund wieso es bei den Desktop-CPUs erst einige Steppings und ein paar kleinere Aenderungen später unterstützt wurde).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Features im Nachhinein Freischalten ist spätestens möglich, seit es das Konzept Microcode gibt
Microcode erlaubt nicht Features "freizuschalten" (= Hardware die bisher nicht lief einzuschalten), sondern Features "nachzuimplementieren" oder patchen (= in Software zu emulieren, aber es sieht danach doch aus wie Hardware, wenn auch langsamere). Die beruehmten fehlenden "guard bits" bei den 360ern nachzusimulieren, welches FP Rechnungen genauer machte (auf Kosten der Geschwindigkeit), war da der klassische Fall.
Bei IBMs RISC-Server gehört das nachträgliche Freischalten
Das hat bei IBM auch lange Tradition. Extremfall waren 2 360er (oder waren das 370er?) Modelle, wo man vom vorhandenen kleineren ausgehend $25'000 zahlte fuer den groesseren, und dann kam der Servicetechniker vorbei und zog einen Stecker raus, oder steckte einen rein (kann mich nicht mehr genau errinneren). Beide Modelle waren identische Hardware, fuer $25'000 weniger bekam man einfach ein kastriertes (vermutlich Taktfrequenz verringerte) Exemplar.
Bin mir gerade nicht sicher, ob ich Ähnliches auch von Sun oder HP
Waer mir nichts bekannt, das Sparcs oder PA-RISC ueberhaupt je Microcode gehabt haben sollen. Die waren als "Vorzeige-RISC" stets voll hart verdrahtet.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
