News Intel × AMD: x86-Allianz feiert 1-Jähriges, AVX10 und ACE kommen für alle

adfsrg schrieb:
Nein, hast du nicht.

Die erste 64-Bit Architektur von Intel war IA64 und war EPIC/VLIW. Alles was Itanium war.

AMD hat dann zur Jahrtausendwende AMD64 vorgestellt, was eine Erweiterung der x86 war.

Intel hat dann - nach den Erfolgen von Opertron im Server-Bereich - ihre EMT64 vorgestellt. Anfangs wollte Intel hier noch was eigens mache , nur den Zahn hat ma ihn gezogen, wodurch es zu einem Lizenzabkommen mit AMD kam.

Intel nennt ihre „Erweiterung“ Intel 64, AMD eben AMD 64, beides ist jedoch das, was Jim Keller unter AMD federführend für Athlon 64 und Opertron entwickelt hat.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai, NEO83, ETI1120 und eine weitere Person
DevPandi schrieb:
Nein, hast du nicht.
Doch, habe ich
DevPandi schrieb:
Die erste 64-Bit Architektur von Intel war IA64 und war EPIC/VLIW. Alles was Itanium war.
Das ist größtenteils* korrekt. Hier war aber die Rede von der 64-Bit-Erweiterung und das ist nicht IA64 sondern Intel 64

*iAPX 432 hatte Teile in 64 Bit und konnte 1 TB adressieren, trotzdem gilt er als 32 Bit und das war Anfang der 80er und hat hiermit nichts zu tun
DevPandi schrieb:
EMT64 vorgestellt
Und das ist Intel 64, es wurde nur umbenannt. https://de.wikipedia.org/wiki/Intel_64
DevPandi schrieb:
beides ist jedoch das, was Jim Keller unter AMD federführend für Athlon 64 und Opertron entwickelt hat.
Beides ist weitgehend kompatibel, aber nicht identisch. Intel 64 basiert nur auf AMD64.
 
2 Truthähne machen keinen Adler, die x86 Plattform ist veraltet, mein M2 ist schneller und säuft gleichzeitig deutlich weniger Strom. Schachmatt
 
adfsrg schrieb:
Beides ist weitgehend kompatibel, aber nicht identisch. Intel 64 basiert nur auf AMD64.
Die Sache war ganz einfach, Microsoft hat gesagt wir unterstützen nur eine 64 Bit Erweiterung für X86 in Windows. Und als sich Intel nicht gerührt hat, hat Microsoft AMD64 in Windows unterstützt.

Als dann Intel verspätet kam, hat Microsoft sie auflaufen lassen. In der Folge musste Intel ein Patenttauschabkommen mit AMD schließen.

Es heißt im übrigen überall X86-64. Intel 64 ist eine Fiktion.

Die Geschichte hat übrigens noch eine nette Pointe. Mehr heute Abend.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai
ETI1120 schrieb:
Es heißt im übrigen überall X86-64. Intel 64 ist eine Fiktion.
Ist dir das nicht peinlich sowas zu behaupten, nachdem ich schon die Links zu Wikipedia und zu Intel Ark gepostet habe, die das eindeutig widerlegen?
 
adfsrg schrieb:
Hatte Intel das echt nur bis zur Core-i-Serie? Hast du eine Quelle, die belegt, dass Arrow-Lake nicht mehr Intel 64 nutzt sondern AMD 64?
Intel 64 ist mehr oder weniger die von AMD entwickelte x86_64 Erweiterung, hieß nur zu unterschiedlichen Zeiten jeweils anders (IA-32e und EM64T).

Intel 64 ist die x64-Implementierung der IA-32-x86-Architektur von Intel. Sie ermöglicht, direkt mehr als 4 GiB Arbeitsspeicher zu adressieren. Die Befehlssatzerweiterung ist weitgehend zu AMD64 von AMD kompatibel und basiert grundlegend auf dieser.
https://de.wikipedia.org/wiki/Intel_64
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai und DevPandi
mibbio schrieb:
Intel 64 ist mehr oder weniger die von AMD entwickelte x86_64 Erweiterung, hieß nur zu unterschiedlichen Zeiten jeweils anders (IA-32e und EM64T).
Exakt. Intel 64 basiert auf AMD64 und ist das, was Intel noch heute nutzt. Ich schrieb doch:
adfsrg schrieb:
Die 64-Bit-Erweiterung von Intel ist Intel 64. Die ist nicht gescheitert, sondern bis heute im Einsatz. AMDs 64-Bit-Erweiterung kam übrigens davor.
 
Grundkurs schrieb:
Und es gibt weniger Anwendungssoftware für Apple Silicon als für x86-64, AMD64, EM64T oder wie es auch immer genannt wird.
Beide Architekturen haben ihre Berechtigung, und x64 CPUs funktionieren intern teilweise wie RISC CPUs was nichts mit dem Befehlssatz zu tun hat.
Bei einer so umfassenden Integration, wie die Apple CPUs haben, würden auch x64 CPUs effizienter, aber auch weniger flexibel für Erweiterungen.
Es werden eben 2 verschiedene Bereiche des Marktes mit unterschiedlichen Anforderungen bedient.
 
Zuletzt bearbeitet:
Grundkurs schrieb:
die x86 Plattform ist veraltet, mein M2 ist schneller
Die ist nicht wirklich veraltet bzw. wenn dann nur in Teilen. Man müsste nur mal die Idee von X86S umsetzen und den ganzen Legacy-Kram aus der Architektur rauswerfen. Denn aktuelle CPU mit der x86_64 Architektur schleppen immer noch den uralten 16-Bit "Real Mode" und den 32-Bit "Legacy Protected Mode" mit. Wenn die CPU beim Einschalten des PCs initialisiert wird, durchläuft die immer diese Modis, bis sie dann letztendlich in der 64-Bit Long Mode geschaltet wird.

Das bedeutet eben auch, dass in den Chips auch noch die ganze dafür benötigten Logischaltungen und Befehlsdecoder vorhanden sind, was die Architektur in der aktuellen Form unnötig komplex macht und Chipfläche verbraucht.

Würde man diese 16- und 32-Bit Betriebsmodi hingegen rauswerfen und die CPU direkt in den 64-Bit Long Mode schalten lassen, entfiele sehr viel Komplexität im Design von CPU und Microcode. Damit kann man dann auch die Effizienz der CPUs steigern. Auch wäre es der Sicherheit der CPUs zuträglich, weil man keine schwer zu sichernden Legacy-Mechanismen, wie bspw. Segmentierung oder 16-Bit Interrupts, mehr hätte.

Übrigens wäre damit auch 32-Bit Software nicht per se inkompatibel, sie müsste halt nur dafür kompiliert sein, im Long Mode zu laufen.

Die Schwäche von x86_64 ist also nicht, dass sie veraltet wäre, sondern dass dort schlicht immer noch haufenweise Altlasten bis runter zum 16-Bit Real Mode im CPU-Design mitgeschleppt werden (müssen).

Dieses Problem mit den Altlasten haben Apples M SoC bzw. ARM allgemein einfach nicht, weswegen die dort effizientere Designs möglich sind. Dazu kommt noch, dass ARM als RISC ein weniger komplexes/umfangreiches Instruction Set hat. Aber dass Betrifft erstmal nur das grundlegende Instruction Set und je nach konkreter CPU-Architektur kommen da noch diversere Befehlssatz-Erweiterungen (bspw. AVX) hinzu. Bei modernen ARM-CPUs, wie beispielsweise den M1-M4 ist man dann schon recht weit weg vom grundlegenden Instruction Set und die Grenzen verschwimmen Richtung CISC. Auch hat RISC nicht nur Vorteile, sondern je nach Einsatzzweck auch Nachteile, denn ansonsten wäre nicht auch CISC bis heute erfolgreich am Markt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Poulton, Kitsune-Senpai, adfsrg und eine weitere Person
TPD-Andy schrieb:
Beide Architekturen haben ihre Berechtigung, und x64 CPUs funktionieren intern teilweise wie RISC CPUs was nichts mit dem Befehlssatz zu tun hat.
Das Problem liegt darin dass viele im englischen nicht verstehen was eine Instruktion Set Architekture ist. Das deutsche Wort Befehlssatz ist viel besser.

Die Architektur die tatsächlich für die Performance verantwortlich ist heißt Microarchitektur.

Es stimmt im übrigen nicht dass die Micro Ops die X86 seit dem PentiumPro intern verwendet dasselbe wie RISC Befehle ist.

Die RISC vs CISC Debatte wurde im Grunde durch den PentiumPro beendet.
Ergänzung ()

mibbio schrieb:
Die ist nicht wirklich veraltet bzw. wenn dann nur in Teilen.
Das Problem ist dass In den letzten 20 Jahren nur neue Erweiterungen hinzukamen, aber nie wirklich geschaut wurde was wirklich notwendig ist und was weg kann oder weg muss.

X86S kam eben reichlich spät. Ich gehe davon aus dass die Gespräche darüber schnell klar gemacht haben dass dies in größerem Rahmen stattfinden muss.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Kitsune-Senpai und TPD-Andy
ETI1120 schrieb:
Es stimmt im übrigen nicht dass die Micro Ops die X86 seit dem PentiumPro intern verwendet dasselbe wie RISC Befehle ist.
Ähnliche Funktionsweisen werden aber umgesetzt.

Zum eigentlichen Thema: Die x86 Allianz wurde vermutlich u.a. auch als Reaktion auf das ARM Lizenzmodell und die Entwicklung anderer CPU Architekturen wie RISC V gegründet.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai
TPD-Andy schrieb:
Ähnliche Funktionsweisen werden aber umgesetzt
Heute Abend mehr dazu.
TPD-Andy schrieb:
Zum eigentlichen Thema: Die x86 Allianz wurde vermutlich u.a. auch als Reaktion auf das ARM Lizenzmodell und die Entwicklung anderer CPU Architekturen wie RISC V gegründet.
Was RISC-V anbelangt ganz sicher.
Am Lizenzmodell von Arm hat sich eigentlich noch nichts geändert.

Ich denke wenn man die Situation ganz nüchtern betrachtet ist es so, dass X86 sehr verwundbar geworden ist. Es war höchste Zeit dass AMD und Intel begonnen haben gemeinsam an der ISA zu arbeiten.
 
  • Gefällt mir
Reaktionen: TPD-Andy und Kitsune-Senpai
IDontWantAName schrieb:
X86S [...] alten 16 Bit Kram mal zu entfernen. Aber das wurde wohl aufgegeben.

X86S wird wohl nicht so viel bringen wie sich manch einer hier verspricht. Und es wuerde den 16-bit-Kram nicht entfernen, der ist Teil von IA-32 (auch wenn man das IA-32-Programmen normalerweise nicht ansieht). Es wuerde den Legacy Mode entfernen, also die Moeglichkeit IA-32-Betriebssysteme laufen zu lassen. Der Compatibility Mode (IA-32-Programme auf einem 64-bit Betriebssystem) waere immer noch da.

IA-32 (also den Compatibility Mode) komplett zu entfernen, dazu gibt's wohl noch zuviel 32-bit-Software. Das ist halt der Unterschied zwischen PCs und Smartphones: Auf PCs laesst man Jahrzehnte alte IA-32-Programme laufen, und Jahrzehnte alte IA-32-Programme werden noch immer gewartet; und wenn man diese Nutzer nicht in Richtung Windows-on-ARM vertreiben will, dann unterstuetzt man diese Software weiter. Wer hat eine 10 Jahre alte Smartphone-App, die ohne Update laeuft?
 
  • Gefällt mir
Reaktionen: ETI1120
mae schrieb:
IA-32 (also den Compatibility Mode) komplett zu entfernen, dazu gibt's wohl noch zuviel 32-bit-Software.
Das sieht man z.B. an der Entscheidung von Microsoft den Internet Exporer aus Kompatibilitätsgründen als IE-Modus im Browser Edge zu belassen wegen der Abwärtskompatibilität auf Softwareseite, genau wie das noch der Real Mode und Protected Mode in den aktuellen x86-64 CPUs enthalten sind auch wen diese selten verwendet werden. Wobei das mehr eine Vermutung ist da ich dazu keine Zahlen habe.
 
TPD-Andy schrieb:
Ähnliche Funktionsweisen werden aber umgesetzt.
Das sieht Robert P. Colwell anders. Der sollte es wissen, denn er hat maßgeblich am PentiumPro mit gearbeitet.

Stimmt es, dass moderne x86-Chips ihre CISC-Befehle in RISC-Befehle umwandeln? Wenn ja, wozu werden dann überhaupt „x86”-Chips hergestellt und warum werden keine reinen CISC-Chips verwendet?
https://www.quora.com/Is-it-true-th...-x86-chips-and-why-arent-pure-CISC-chips-used

Es ist NICHT wahr, dass x86 „ihre CISC-Befehle in RISC-Befehle umwandeln”. Diese Prämisse deutet auf Verwirrung auf mehreren Ebenen hin. x86-Prozessoren ab dem Pentium Pro decodieren x86-Befehle in Mikrooperationen. Mikrooperationen lassen sich am besten als Operationen verstehen, die vom Mikrocode-ROM ausgegeben worden sein könnten. Sie können nicht als Befehle betrachtet werden, weder als RISC-Befehle noch als andere Befehle, da sie (a) nicht von einem Compiler generiert werden können, (b) keineswegs einfach sind (über 100 Bit breit), (c) nicht unbedingt einen einzigen Zyklus benötigen und (d) einen mikroarchitektonischen Mechanismus darstellen, der auf der Ebene des Befehlssatzes nicht sichtbar ist. Es ist absolut unerlässlich, architektonische und mikroarchitektonische Fragen getrennt zu behandeln. Dies ist in der Tat der Schlüssel zum langfristigen Erfolg für Unternehmen wie Intel und AMD – die Kompatibilität des Objektcodes aufrechtzuerhalten und gleichzeitig die Vorteile des „Moore'schen Gesetzes“ geschickt zu nutzen, indem die zugrunde liegende Mikroarchitektur an die Kapazität des aktuellen Siliziumprozessknotens angepasst wird.

Und für jeden der sich für Microprozessoren interessiert empfehle ich einfach Mal durch die Antworten von Robert P. Colwell auf Quora zu browsen.

https://www.quora.com/profile/Bob-Colwell-1
Ergänzung ()

Chesterfield schrieb:
Trotz beeindruckender Performance konnte sich der Standard nie wirklich durchsetzen, da es an Kompatibilität zu älteren AVX-Versionen mangelte und AMD lange Zeit kein echtes AVX-512 unterstützte.
Intel hatte tolle Benchmarks. Auf dem Papier sah alles ganz toll aus. Mit realem Code war dies ganz anders.

Ein Problem war, dass Intel selbst AVX-512 nur sehr zögerlich auf die Client-CPUs brachte. Als es endlich auf den Client-CPUs war, musste Intel AVX-512 in der nächsten Generation, Alder Lake wegen den E-Cores deaktivieren.

Und dann kam hinzu dass die Implementierung von Intel
Chesterfield schrieb:
Das ist so nicht richtig !!

Intel ist aktuell der einzige große Anbieter von echtem AVX-512, das in vielen High-End- und Server-CPUs wie Skylake-X, Ice Lake oder Sapphire Rapids unterstützt wird. AMD hingegen setzt statt AVX-512 auf 2×256-Bit AVX, also zwei 256-Bit-Pfade, und unterstützt AVX2 vollständig, hat aber kein echtes AVX-512 in Ryzen- oder EPYC-Prozessoren integriert.


Es gab zwar Berichte, dass AMD bei Zen 4 (Ryzen 7000) AVX-512 intern testweise implementiert hat, aber in der finalen Version ist es deaktiviert und für Nutzer nicht verfügbar. Auch bei Zen 4c und anderen Varianten bleibt AVX-512 außen vor.
Wer hat Dir das erzählt?

https://www.phoronix.com/review/zen4-avx512-7700x/11

Die Implementierung bei Zen 4 ist ausdrücklich gelobt worden und der Umstand dass Seit Zen 4 AVX-512 endlich durchgehend für Clients verfügbar wurde, hat dazu geführt dass die Verwendung von AVX-512 deutlich zugenommen hat.

Bei Phoronix waren in diesem Jahr einige Posts dazu.

Chesterfield schrieb:
Kurz gesagt: AMD liefert bisher keine echten AVX-512-Befehlssätze in seinen CPUs. Wer AVX-512 braucht, muss aktuell zu Intel greifen.
Die Umsetzung von AVX-512 bei Zen 5 ist nochmal besser geworden.

Alexander J. Yee der Autor von y-cruncher hat eine sehr lesenswerte Rezension von Zen 5 und vor allem vom AVX-512 mit Zen 5 geschrieben
https://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/

Eine sehr hübsche Passage daraus:
AVX512-VP2INTERSECT:

Ah yes, the black sheep of the AVX512 family...

There is a lot of history here, but to summarize:
  1. Intel added AVX512-VP2INTERSECT to Tiger Lake. But it was really slow. (microcoded ~25 cycles/46 uops)
  2. It was so slow that someone found a better way to implement its functionality without using the instruction itself.
  3. Intel deprecates the instruction and removes it from all processors after Tiger Lake. (ignoring the fact that early Alder Lake unofficially also had it)
  4. AMD adds it to Zen5.
So just as Intel kills off VP2INTERSECT, AMD shows up with it. Needless to say, Zen5 had probably already taped out by the time Intel deprecated the instruction. So VP2INTERSECT made it into Zen5's design and wasn't going to be removed.

But how good is AMD's implementation? Let's look at AIDA64's dumps for Granite Ridge:

AVX512VL_VP2INTERSE :VP2INTERSECTD k1+1, xmm, xmm L: [diff. reg. set] T: 0.23ns= 1.00c
AVX512VL_VP2INTERSE :VP2INTERSECTD k1+1, ymm, ymm L: [diff. reg. set] T: 0.23ns= 1.00c
AVX512_VP2INTERSECT :VP2INTERSECTD k1+1, zmm, zmm L: [diff. reg. set] T: 0.23ns= 1.00c
AVX512VL_VP2INTERSE :VP2INTERSECTQ k1+1, xmm, xmm L: [diff. reg. set] T: 0.23ns= 1.00c
AVX512VL_VP2INTERSE :VP2INTERSECTQ k1+1, ymm, ymm L: [diff. reg. set] T: 0.23ns= 1.00c
AVX512_VP2INTERSECT :VP2INTERSECTQ k1+1, zmm, zmm L: [diff. reg. set] T: 0.23ns= 1.00c

Yes, that's right. 1 cycle throughput. ONE cycle. I can't... I just can't...

Intel was so bad at this that they dropped the instruction. And now AMD finally appears and shows them how it's done - 2 years too late.


At this point, I have no idea if VP2INTERSECT will live or die. Intel has historically led the way in terms of instruction sets with AMD playing copycat while lagging behind by a few years. Will AMD continue playing copycat and drop their amazing implementation of VP2INTERSECT? Or will they keep it alive going forward to Zen 6 and beyond? AMD has hinted to me that they may keep it, though I'm not entirely sure it's actually decided yet.

AFAIK wird AMD AVX512-VP2INTERSECT beibehalten da es Anwendungsfälle dafür gibt
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Piktogramm
DevPandi schrieb:
Kannste mal verlinken.
https://www.sigmicro.org/media/oralhistories/colwell.pdf

das Interview ist von der ACM nicht vom CHM

Es sind 164 Seiten also ziehe ich die Passage raus, die ich meinte:

Seite 85 unten 86
0:11:29 BC: Ja, das habe ich, und es hat immer Spaß gemacht. Gordon Moore hat mich sehr inspiriert. Ich habe ihn nichtoft gesehen, vielleicht fünf oder sechs Mal während meiner gesamten Zeit dort. Aber es waren unvergesslicheMomente, das war das Lustige daran. Eine Erinnerung, die mir besonders im Gedächtnis geblieben ist, ist, als das Itanium-Projekt geradeanlief. Wir aus Oregon wurden systematisch und absichtlich von diesem Projekt ausgeschlossen. HP befürchtete, dass HP eine Art geistiges Eigentum für Itanium eingebracht hatteund wollte nicht, dass dieses geistige Eigentum in einer konkurrierenden Reihe von x86-Prozessoren auftauchte . Daher achtete man damals sehr darauf, diese beiden Bereiche voneinander zu trennen. Wir wussten daher nur sehr wenig darüber, was Itanium war, wir hörten nur Gerüchte, dass es so etwas wie ein VLIW sei, was wir bei Multiflow gemacht hatten. Papworth und ich sahen uns an und dachten, soweit wir wissen, gibt es nur zwei Leute in diesem Unternehmen, die etwas über VLIWs wissen, und das sind wir beide ...

Seite 86 unten Seite 87:
... Jedenfalls steht dieser Chip-Architekt vor dieser Gruppe und verspricht ihnen das Blaue vom Himmel. Schließlich hebe ich meine Hand und sage, dass ich einfach nicht verstehen kann, wie Sie diese Leistung erreichen wollen. Er antwortet, dass sie eine Simulation haben, und ich denke: Ah, okay. Das bringt mich für einen Moment zum Schweigen, aber dann fällt mir etwas ein und ich unterbreche ihn erneut. Ich sagte:„Entschuldigen Sie, dass ich diese Besprechung unterbreche. Aber wie wollen Sie einen Simulator einsetzen, wenn Sie keinen Compiler haben?“ Er sagte: „Das stimmt, wir haben noch keinen Compiler, also habe ich meine Simulationen von Hand zusammengestellt.“ Ich fragte: „Wie haben Sie Tausende von Codezeilen auf diese Weise geschrieben?“ Er sagte: „Nein, ich habe 30 Zeilen Code geschrieben.“ Verblüfft sagte ich: „Sie sagen die gesamte Zukunft dieser Architektur anhand von 30 Zeilen handgeschriebenem Code voraus?“ [kichern], Ich habe das einfach so gesagt, ich wollte nicht beleidigend sein, aber ich war einfach sprachlos. Andy Grove mischte sich ein und sagte: „Wir sind jetzt nicht hier, um die Zukunft dieses Vorhabens zu überdenken, also lassen Sie uns weitermachen.“ ...

... Gordon Moore sitzt neben mir und hat noch kein Wort gesagt, ersieht aus, als würde er schlafen. Er hat die meiste Zeit die Augen geschlossen, man denkt sich, okay, der Mann ist müde, er ist alt. Aber nein, nach 20 Minuten öffnet er plötzlich die Augen, zeigt auf mich und fragt: „Haben Sie jemals eine Antwort auf Ihre Frage bekommen?“ Und Ich sagte: „Eigentlich nein, keine, die ich verstehen kann.“ Gordon sah sich um und sagte: „Wie wollen wir damit weitermachen, wenn die Antworten keinen Sinn ergeben?“ Und diesmal sagte Andy Grove zu ihm: „Wir sind nicht hier, um darüber zu diskutieren, Gordon.“ [Gelächter]. Gordon hat mich wirklich beeindruckt mit seiner Fähigkeit, direkt zum Kern der Sache vorzudringen. Ich habe das mehr als einmal bei ihm beobachtet. Man denkt, er hört nicht zu, aber wenn er sich zu Wort meldet, trifft er genau ins Schwarze. Er hat nicht nur die Diskussion verfolgt, sondern erkennt auch, wo das eigentliche Problem liegt, und weist darauf hin. Dieser Mann war beeindruckend.

Anderer Stelle meint Robert P Colwell, dass die von HP erzwungene Abschottung zwischen den Teams Intel sehr geschadet hat.

Das Interview bezieht sich des öfteren auf das Buch "The Pentium Chronicles" das Robert P Colwell

Ein kurzes Zitat aus dem ersten Kapitel:
Meine eigene Analyse der RISC/CISC-Debatten ergab jedoch, dass wir tatsächlich fast alle technischen Vorteile von RISC in ein CISC-Design übernehmen konnten. Den Rest konnten wir durch zusätzliche technische Maßnahmen, eine etwas größere Chipgröße und die schiere Wirtschaftlichkeit großer Produktliefermengen überwinden.

In der Zeit vor 1990 war Robert P Colwell maßgeblich an einigen Papieren in der CISC/RISC Debatte beteiligt.
 
  • Gefällt mir
Reaktionen: DevPandi und Piktogramm
phm666 schrieb:
Abwarten, ob es mit AVX10 dann besser wird
Zumindest bei AMD sicherlich. Das war bei denen von jeher Firmenphilosopie ihre Consumer Serie nicht künstlich zu beschneiden, zumal das ja eh die gleichen Chiplets sind, die auch die Workstation und Server CPUs befeuern.... anders als bei Intel.
 
  • Gefällt mir
Reaktionen: TPD-Andy und phm666
mibbio schrieb:
Würde man diese 16- und 32-Bit Betriebsmodi hingegen rauswerfen und die CPU direkt in den 64-Bit Long Mode schalten lassen, entfiele sehr viel Komplexität im Design von CPU und Microcode. Damit kann man dann auch die Effizienz der CPUs steigern. Auch wäre es der Sicherheit der CPUs zuträglich, weil man keine schwer zu sichernden Legacy-Mechanismen, wie bspw. Segmentierung oder 16-Bit Interrupts, mehr hätte.
Allerdings ist dieser Punkt auch der grosse Pluspunkt der x86 Architektur.

Würde man diesen aufgeben, dann hätte man kaum noch ein Vorteile gegenüber starken ARM Designs wie Qualcomm Snapgragon Elite, Nvidia Tegra, Huawei HiSilicon Kirin, etc.
 
Zurück
Oben