Weitere Inkompatibilität bei Intels EM64T
- Ersteller mtb][sledgehammer
- Erstellt am
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Schon zweimal haben wir darüber berichtet (<a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1078152128">hier</a> und <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1088503188">hier</a>), dass Intels Implementierung der AMD64-Technolgie, EM64T, nicht vollständig zum ursprünglichen 64 Bit Befehlssatz kompatibel ist. So ist es beispielsweise nicht möglich die aktuelle Beta von Microsofts Beta Version des 64 Bit Windows auf dem neuen Xeon mit Nocona Kern zu installieren.
In einer aktuellen <a href="http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129" target="b">Diskussion</a> der Webseite <i>Silicon Investors</i> wird nun ein weiterer Untschied von EM64T genannt. Nach der Fehlerliste des Nocona ist die neue CPU nur in der Lage einen physikalisch 36 Bit großen Adressraum anzusprechen, während AMD64-CPUs aktuell einen 40 Bit großen physikalischen Adressraum bereitstellen. Unglücklicherweise gibt die "Extended Address Sizes Function" des Xeon jedoch den falschen Wert 40 Bit aus.
In einer aktuellen <a href="http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129" target="b">Diskussion</a> der Webseite <i>Silicon Investors</i> wird nun ein weiterer Untschied von EM64T genannt. Nach der Fehlerliste des Nocona ist die neue CPU nur in der Lage einen physikalisch 36 Bit großen Adressraum anzusprechen, während AMD64-CPUs aktuell einen 40 Bit großen physikalischen Adressraum bereitstellen. Unglücklicherweise gibt die "Extended Address Sizes Function" des Xeon jedoch den falschen Wert 40 Bit aus.
nobody4ever
Lieutnant
- Mitglied seit
- 02.08.2002
- Beiträge
- 82
- Renomée
- 0
Hmpf, Intel versucht wirklich mit allen Mitteln 64bit solange wie möglich zu verhindern. Wenn Microsoft sooft Extracode für die Intel Prozessoren machen muß, dann kommt noch Windows Longhorn früher 
PuckPoltergeist
Grand Admiral Special
Ok, das ist keine Inkompatibilität, sondern ein Fehler. Unter inkompatibel würde ich verstehen, wenn die CPU sowohl 36bit kann als auch ausgibt. Da die beiden Werte nicht stimmen, fällt das bei mir unter bug.
At slider: Nicht nur virtuell, sondern sogar physikalisch! Dank des PAE-Krams kann seit dem PentiumPro 64GB physikalischer Speicher angesprochen werden. Wird dann (wie damals EMS in Dos) scheibchenweise in den Speicherbereich unter 4GB eingeblendet.
Intel wollte ja keine neuen Pins, da ist klar, dass auch nur 36bit für den Speicher extern zur Verfügung stehen. Ist aber für die Software egal, solange das virtuelle Speichermanagement mit den AMDs identisch ist. Und solange 64GB noch reichen.......
Ist einfach ein Fehler in der Dokumentation und der cpuid, mehr eigentlich nicht.
Intel wollte ja keine neuen Pins, da ist klar, dass auch nur 36bit für den Speicher extern zur Verfügung stehen. Ist aber für die Software egal, solange das virtuelle Speichermanagement mit den AMDs identisch ist. Und solange 64GB noch reichen.......
Ist einfach ein Fehler in der Dokumentation und der cpuid, mehr eigentlich nicht.
mtb][sledgehammer
Grand Admiral Special
Im Prinzip ist es beides: Opteron und Athlon 64 haben einen 40 Bit Adresraum, der Xeon jedoch nur 36 Bit. Eine Software die 40 Bit reservieren will, wird auf einem Xeon nicht funktionieren.
Wenn ich das richtig verstanden habe, geht es nur um den physikalischen Adressraum, letztlich also, wie viele Adress-Pins der Prozessor hat. Die Software arbeitet eh nur mit virtuellen Adressen, und selbst das OS wird nischt davon merken. Nur dass halt nicht mehr als 64GB eingebaut werden können.
Ist wie wenn du einem 32bit Prozzi nur 1GB physikalisch gibst. Dann sind auch nur 30 Adress-bits in Betrieb. Man könnte auch einen 32bit Prozessor bauen, der nur 30 bits nach außen führt. Wäre dann so wie EM64T zu AMD64.
Korrigiert mich, wenn ich falsch liege!
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
jeder Prozess hat dann aber maximal 4Gb...
abgesehen von dieser Beschränkung ist PAE lahm, und nicht sauber.
Bei einer Maschine die mehr als 4GB Ram hat, wäre ein System, dass nativ soviel Ram adressieren kann angebracht.
Also entweder will Intel einfach nicht, oder die sind unfähig einen fremden Standard zu implementieren. Bei NX hat man ja inzwischen nachgezogen, hätte mir ehrlich gedacht, dass gerade ein marketingtechnisch sehr aktiver Verein wie Intel die Vorzüge davon rechtzeitig erkennen würde... aber nein, erst als es zu spät war hat man das erkannt.
Und jetzt machen die so einen Murks. Mein Vorschlag: Jede Software sollte auf AMD64 gebaut werden, wenns auf einem Intel nicht läuft - pech. Vielleicht schafft es Intel dann AMD64 ordentlich zu implementieren.
Ich freu mich schon auf den nächsten Intel-Themenabend
Und jetzt machen die so einen Murks. Mein Vorschlag: Jede Software sollte auf AMD64 gebaut werden, wenns auf einem Intel nicht läuft - pech. Vielleicht schafft es Intel dann AMD64 ordentlich zu implementieren.
Ich freu mich schon auf den nächsten Intel-Themenabend
Die Vorstellung hat in der Tat was 8)
Nein aber mal im Ernst, AMD64 hat die Möglichkeit geboten endlich mal aufzuräumen. Sogar 3DNow! hätte man mit aufnehmen können, was besseres gibts doch nicht - endlich bekommt x86 Standard-SIMD Befehle, die auf jedem Rechner verfügbar sind.
Und? Intel implementierts natürlich nicht, wobei sie ja sogar die Lizenz dazu haben. Vielleicht ist 3DNow nicht so leistungsfähig wie SSE (vielleicht liegt das aber auch nur daran, dass es sich nicht durchgesetzt hat) - aber besser als nix ist es auf jeden Fall. Was der Mac so mit seinem Altivec erreicht weil es das auf jeder CPU gibt...
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
interessanter Artikel zu dem Thema:
http://www.sudhian.com/showdocs.cfm?aid=564
http://www.sudhian.com/showdocs.cfm?aid=564
Also auf die Gefahr hin, dass ich nerve....
Intel hat hier eigentlich nichts falsch gemacht außer die Dokumentation und den cpuid-Befehl!
Intel hatte ja einen vorhandenen Sockel und vorhandene Prozessoren, die nur auf EM64T/AMD64 umgerüstet werden sollten. Da ist doch klar, dass die nur die vorhandenen 36 Adress-Pins nutzen konnten. Wie ich aber schon sagte ist das für die Software erstmal wurscht, wie viel physikalischen Speicher der Prozzi ansprechen kann.
Ich erinnere nur an den 386SX: Der war extern komplett 16 bit, trotzdem ist er voll Software-Kompatibel zum 386DX.
gruß
larsbo
Intel hat hier eigentlich nichts falsch gemacht außer die Dokumentation und den cpuid-Befehl!
Intel hatte ja einen vorhandenen Sockel und vorhandene Prozessoren, die nur auf EM64T/AMD64 umgerüstet werden sollten. Da ist doch klar, dass die nur die vorhandenen 36 Adress-Pins nutzen konnten. Wie ich aber schon sagte ist das für die Software erstmal wurscht, wie viel physikalischen Speicher der Prozzi ansprechen kann.
Ich erinnere nur an den 386SX: Der war extern komplett 16 bit, trotzdem ist er voll Software-Kompatibel zum 386DX.
gruß
larsbo
Original geschrieben von larsbo
Also auf die Gefahr hin, dass ich nerve....
Intel hat hier eigentlich nichts falsch gemacht außer die Dokumentation und den cpuid-Befehl!
Intel hatte ja einen vorhandenen Sockel und vorhandene Prozessoren, die nur auf EM64T/AMD64 umgerüstet werden sollten. Da ist doch klar, dass die nur die vorhandenen 36 Adress-Pins nutzen konnten. Wie ich aber schon sagte ist das für die Software erstmal wurscht, wie viel physikalischen Speicher der Prozzi ansprechen kann.
Ich erinnere nur an den 386SX: Der war extern komplett 16 bit, trotzdem ist er voll Software-Kompatibel zum 386DX.
gruß
larsbo
Nein, ist der nicht. der 386SX kann zb. keinen Protected Mode (bzw. afaik nicht den 32bit PM sondern nur den 16bit PM vom 286) - der 386DX schon. Da hängt noch ein riesiger Sack voll anderen Dingen dran.
Besser wäre es gewesen Intel hätte auch 36 Adressbits gemeldet. Genauso die Sache mit DMA Zugriffen über 4GB.
nobody4ever
Lieutnant
- Mitglied seit
- 02.08.2002
- Beiträge
- 82
- Renomée
- 0
Also mein 386 SX konnte damals Windows 3.1 ohne Probleme im 386er Modus laufen lassen. Dazu brauchte der Prozessor auch den 32 bit Protected Mode oder ?
Die Win32-S Erweiterung konnte ich auch installieren ........
Die Win32-S Erweiterung konnte ich auch installieren ........
Ok, kann auch sein das ich mich jetzt irre. Auf jeden Fall ist das was leicht anderes, da damals viele Dinge völlig anders geregelt wurden (angefangen bei der CPU Erkennung, CPUID gabs erst ab dem Pentium1).
Ähnliche Themen
