Alte Zöpfe sollen weg: Intel will x86-Design ohne 16- und 32-Bit bringen

Der Chiphersteller Intel plant eine Vereinfachung seiner x86-Architektur. Alte Elemente, die man seit Jahrzehnten aus Kompatibilitätsgründen mit sich schleppt, sollen nun entfernt und die Leistung dadurch deutlich verbessert werden. mehr... DesignPickle, Logo, Intel, Mainboard, Platine, Intel Logo, Leiterplatte, Neues Intel Logo, Intel Logo 2020

Logo, Intel, Mainboard, Platine, Intel Logo, Leiterplatte, Neues Intel Logo, Intel Logo 2020

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben

[o1] am ++3 --

Der Witz des Tages steht im Artikel: "Es gehörte für Intel zwar immer zum Selbstverständnis, möglichst umfassend abwärtskompatibel zu bleiben".... ahja. Deshalb haben die auch versucht mit Itanium von x86 wegzukommen, deshalb gibts seit nach dem Sockel 775 für jede "neue" Prozessorgenerationen einen neuen Sockel und ein neues Mainboard wird fällig, während AMD über Prozessorgenerationen hinweg die Sockel-Kompatibilität beibehalten hat (AM2 bis AM3+), Ryzen-1000 bis 5000-Generationen auf AM4.... Ryzen 7000 und der kommende 8000 und evtl. Nachfolger auf AM5... AMD hatte sogar die Idee x86 beizubehalten und 64-bit-fähig zu machen, was dann Intel ohne große Ankündigung übernommen hat.

[re:1] am ++--

@mmode7m8: Intel hat es meinem Verständnis nach übernommen, weil es sich am Markt durchgesetzt hat. Wahrscheinlich war das Glück, dass Intel auf wohl schweineteueren Rambus-RAM gesetzt hat, die dann praktisch niemand haben wollte.

[re:2] am ++--3

Was hat Softwareabwärtskompatabilität mit Sockeln und Co zu tun?

[re:1] am ++--1

@Screenzocker13: Nichts. Er wollte was über AMD erzählen, ist nur nicht die gut mit der Sprache zurecht.

[re:1] am ++3 --

@shiversc: Schon - Intels vorgebliche Einstellung zur Abwärtskompatibilität auf Basis der Sockel zu hinterfragen ist völlig legitim (sofern es stimm, habe selbst lange keine Intel-CPUs mehr verbaut).

[re:1] am ++--2

@DRMfan^^: Wenn dir das wichtig ist.

[re:2] am ++2 --

@shiversc: Ob es mir wichtig ist, ob aus Profitgier Millionen unnötiger Motherboards produziert werden? - Ja, das ist es und das sollte uns allen wichtig sein.

[re:3] am ++--

@mmode7m8: "während AMD über Prozessorgenerationen hinweg die Sockel-Kompatibilität beibehalten hat (AM2 bis AM3+)"
Naja, mechanisch Kompatibel waren die schon, für mehr musste aber auch der Mainboard-Hersteller mitspielen und BIOS-Updates bereitstellen (falls die restlichen Komponenten des Boards da überhaupt mitmachen wurden). BIOS-Updates für mein AM2 Board von MSI für die Unterstützung von AM3-CPUs haben nie das Beta-Stadium verlassen.
Sockel A das Gleiche, hatte drei Sockel A CPUs und für jede davon ein neues Board. Das erste Board konnte nur mit 180nm-CPUs umgehen warum auch immer, das zweite Board nicht den 200MHz-FSB für die dritte CPU bereitstellen, ging nur bis 133MHz. Jetzt mal abgesehen davon, wie sinnvoll es wäre die letzte CPU mit 133MHz SD-RAM auf dem ersten Board zu betreiben statt 200MHz DDR-RAM auf dem dritten, wenn dies theoretisch möglich wäre.

[o2] am ++--

Frage: Werden virtualisierte 32Bit-OS dadurch ineffizienter?

[re:1] am ++--1

@DRMfan^^: Gute Frage. Hängt wohl stark von der Qualität des Hypervisor ab. Aber sooo viele 32Bit VMs gibt es ja nicht mehr und Tendenz ist auch klar.

[o3] am ++--

ggf. kann man die alten Teile mittels Softwareemulation in der CPU laufen lassen. Dann sind die alten 16-Bit / 32 Bit-Teile nicht mehr so effizient.

Interessanter wird es, da hier noch alte 16 und 32 Bit-Instruktionen von den Compilern in der 64-Bit-Welt verwendet werden. Im schlimmsten Fall braucht es dann für diese CPU's ein angepasstes Betriebssystem + Software.

Bei Windows 2000 gab es z.B. eine Spezialversion, für Intel Itanium-CPU's. Aber mal sehen wie man, so was den Consumer verkaufen will. Dann fängt es sicher wieder damit an, dass der Kunde checken muss ob seine Hardware für die gekaufte SW passt.

[o4] am ++2 --1

Na endlich.. Das ist sowas von Oldschool der 90er.

[o5] am ++--

Einen Zeitpunkt oder ab welcher CPU-Generation geplant it umzustellen hat Intel wohl noch nicht bekanntgegeben. Kommt wohl frühestens zusammen mit Windows 12,
da sich auch der Bootprozess selber ändert müsste Windows 11 mit einem neuen Bootloader versehen werden. Ältere Betriebssysteme (mit alten Bootloadern) werden auf den neuen 64-Bit only CPUs erst gar nicht mehr starten.

[o6] am ++--

Solange meine in VB6 programmierten Programme weiterlaufen, ist mir egal was Intel macht, ansonsten bye bye Intel.

[re:1] am ++--

@BT-Soft:
wenn windows eine 32-bit emulationsschicht einbaut,
dann wird es dich nicht jucken.

ansonnsten würde ich dir empfehlen alles in 64bit neu zu kompellieren.
ggf. für künftige programme 64bit im fokus halten.

und wenn sich arm64 mal duchsetzen sollte,
vielleicht auch dafür schon eine passende version auf vorrat halten... :P

du hast doch noch deine quellcodes!?

Bearbeitet am 27.05.23 um 22:40 Uhr.

[o7] am ++--

Ja bitte umstellen danke.... Frage mich aber was es an zusatz Leistung bringen kann

[re:1] am ++--

@LittelD:
nix.
würd ich behaupten.

es wird nur der chip entschlackt, also u.u. billiger.
aber brachliegende 16 & 32 bit recheneinhaten stören doch keinen.

zumal die recheneinheiten in den prozessoren, die geringste fläche ausmacht.

dass mal fläche verbraucht, sind diverse zwischenspeicher/caches.

[o8] am ++--

Sehr gut. Schließt es dann zur Effizienz zu Apples Chip auf?

[re:1] am ++--

@zivilist: der war gut ?

[re:1] am ++--

@4ndroid:
nein ;)

das problem ist nicht der leerlauf,
sondern dass (alte) progrmme den chip immer wieder aufwecken/ wach halten.

[o9] am ++--

16bit kann ich vielleicht noch verstehen,
aber die ganzen alten 32bit windows-spiele werden ein problem haben.

ich versteh auch nicht das problem mit der inizalisierungsreihfolgen des cpu's
und der komplette wegfall der 16 & 32bit module?
bei mir frisst das inizalisieren des uefi-bioses am meisten zeit,
sonnst bootet windows, dank ssd, schon extrem schnell.

mit den Itanium cpu's hatte intel ja einen firmware-emulationsmodus,
welche x86/32bit befehle interpretieren konnte, zwar langsam, aber
da heutige cpu's leistungsfähig genug sein sollten,
wäre deren langsame ausführung kein problem.
ggf. könnte man es auch performanter gestalten, ohne firmware-spielereien,
da der befehlssatz ja verwand ist und nicht komplett neu.

außer windows packt ähnlich wie auf arm64
eine native software emulationsschicht ins windows.
was nicht auffällt, das stört auch nicht...

aber ein kompletter verlust von 32bit würde schon auffallen,
und wenn der schrei aus der industrie kommt,
da die u.u. noch mit antiker software arbeiten (müssen).

Bearbeitet am 27.05.23 um 22:53 Uhr.

[re:1] am ++--

@000001a: 32 Bit Programme gibts gar nicht mehr so viele und die es noch gibt werden ein Update rausbringen. Haben ja bestimmt noch 2 Jahre Zeit bis es hier Prozessoren gibt und zudem müssen die Rechner erstmal ersetzt werden.

[re:1] am ++--

@zivilist:
meine alte spielesammlung sagt was anderes.
es gibt genug programme da draußen,
die nicht mehr weiterentwickelt werden.

klar aus endanwendersicht die nur browser & launcher verwenden,
den wird das herzlich egal sein.

darum habe ich das firmen & industrie umfeld mit erwähnt.

die retro spiele szene wird sich mit einem neuem (unnötigen) emulator rumstressen müssen.

der erfolg der x86 platform fußt auf die rückwärtskompatibilität.
und das x86 noch wichtig ist,
sieht man an der emulationsschicht bei windows on arm.
obwohl es schon erstaunlich viele native arm64 programme gibt...

[re:2] am ++--

@zivilist: Das mit den 2 Jahren stimmt zwar, ist aber trotzdem lustig. Denn für viele Leute kommt jedes Jahr Weihnachten auch immer total überraschend und unvorhersehbar. :D

[10] am ++--

Mich würde interessieren was es für Vorteile bringt. ich vermute, dass bestimmte Register usw. wegfallen könnten, die die CPU evtl. sparsamer machen könnten? Oder gibt es da mehr?