Intel plant x86-Zukunft ausschließlich mit 64 Bits

[dildo4u]

Ältere OS/Software soll per Virtualisierung laufen.

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

[Shink]

Gibt es denn noch performancekritische 32 Bit Sachen? Für ältere Software wäre das ja egal.

[basix]

Für Consumer sehe ich keine wesentlichen Probleme. Bei Enterprise ist manchmal erstaunlich, wie alt systemkritische SW-Pakete sind.

Generell:
64bit only würde ich begrüssen. Das könnte die CPU-Cores entschlacken. Und die Zukunft wird sowieso 64bit sein.

[Corny]

Für Consumer sehe ich keine wesentlichen Probleme. Bei Enterprise ist manchmal erstaunlich, wie alt systemkritische SW-Pakete sind.


Sind diese systemkritischen 32-bit Pakete dann auch derart Performancehungrig?


Ich hab gerade mal den Taskmanager in Windows 11 aufgemacht: 14 von 264 Prozessen laufen als 32-bit Prozess.

[Radeonfreak]

Ältere OS/Software soll per Virtualisierung laufen.

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

So Anwandlungen haben sie alle paar Jahre mal. Lief beim Pentium Pro auch nicht so dolle.

[Thunder99]

Wird kommen, da ja in der Vergangenheit der 16bit Zopf abgeschnitten worden ist.
Basis bleibt ja x86 aber nur noch als 64Bit Edition. Windows "Next" muss dann entsprechend umgeschrieben werden damit es für Otto-normal Verbraucher läuft.

[dildo4u]

So Anwandlungen haben sie alle paar Jahre mal. Lief beim Pentium Pro auch nicht so dolle.
Da gab es kein Macbook mit Apple Chip, ich vermute das hier hat vor allem im Mobile Bereich Vorteile um endlich vergleichbare Verbräuche zu erreichen.

[ryan]

Vielleicht kommt das mit Royal Core, weil das sowieso eine komplett neue Architektur wird wo sie von Anfang an auf 64 bit only bauen könnten.

[basix]

Interessanter Gedanke, ja. Wären sie aber etwas spät dran, nicht? Soll nicht bereits Arrow Lake mit dem Royal Core kommen?

Wenn Intel mit "Royal Core" eine neue Ära einleiten will, wäre 64bit only schon nicht so far-fetched.

[Zossel]

Ich hab gerade mal den Taskmanager in Windows 11 aufgemacht: 14 von 264 Prozessen laufen als 32-bit Prozess.

Windows hängt bei der Zukunft immer weit hinterher.
Umso lächerlicher ist das Gefasel von einem ARM-only Windows.

[Zossel]

Wird kommen, da ja in der Vergangenheit der 16bit Zopf abgeschnitten worden ist..

Heutige X64-CPUs starten immer noch im 16-Bit Modus.

[ryan]

Interessanter Gedanke, ja. Wären sie aber etwas spät dran, nicht? Soll nicht bereits Arrow Lake mit dem Royal Core kommen?

Wenn Intel mit "Royal Core" eine neue Ära einleiten will, wäre 64bit only schon nicht so far-fetched.


Arrow Lake ist kein Royal Core, auch Panther Lake angeblich noch nicht. Wobei wir nicht wissen, was Panther Lake mit sich bringt. Ob das mehr ein refresh ist wie Raptor zu Alder oder wirklich was Neues. Falls das mit Nova Lake kommt, ist da eh noch ein paar Jahre hin. Das paper ist ja auch nur ein proposal, auf eine baldige Einführung deutet das nicht hin.

[Shink]

Lief beim Pentium Pro auch nicht so dolle.
Da gab es noch ein, zwei User ohne 32 Bit Betriebssystem.
Heute wär das um einiges weniger mutig und würde wohl den wenigsten auffallen.
Wer heute ein performancekritisches Service mit 32 Bit betreibt, hat vermutlich auch ein Problem mit der Speicherbegrenzung.

[Exxtreme]

So Anwandlungen haben sie alle paar Jahre mal. Lief beim Pentium Pro auch nicht so dolle.

Das war beim Pentium Pro nicht so das Problem. Das Problem war mehr der Preis. Das Ding war extremst teuer. Da ging es schnell weit über 1000 USD. Und wenn man die Inflation mitberücksichtigt dann wären es schnell weit über 2000 USD heutzutage. Als sie den Pentium Pro zum Pentium2 weiterentwickelt hatten, war auch der Preis viel niedriger.

[Leonidas]

So wie ich das sehe, ist x86S im eigentlichen nicht als was wirklich neues geplant. Es geht eher nur darum, zum einen die alten Boot-Modi loszubekommen und zum anderen nicht mehr genutzte Legacy-Teile rauszuwerfen. Sprich: Abgesehen vom Boot-Modus wird der Gerempel heutzutage sowieso nicht mehr von moderner Software genutzt, die muß sich wahrscheinlich 0,0 umstellen.

Das neue Booten ist dann nur auf neuen OS möglich, das ist die einzige wirkliche Einschränkung. Sprich, Win 10/11 werden irgendwann ganz automatisch keine neuen CPUs mehr bekommen, weil denen wahrscheinlich das neue Booten nicht mehr beigebracht werden wird. Dass der CPU-Support OS-seitig nicht ewig gehalten wird, hatten wir aber auch schon bei Windows 7.

[Radeonfreak]

Das war beim Pentium Pro nicht so das Problem. Das Problem war mehr der Preis. Das Ding war extremst teuer.

Ya rly, ich hatte einen. :redface: 200 MHZ.

[Altehardware]

keiner wird jemals alte code in x86 was in etwa 100% der software auf windows programmiert ist auf eine native 64bit umschreiben.
Daher wird das nix
Ohne software basis wird sich das nicht durchsetzen hätte man das 1992 getan den radikalen schritt wäre es heute egal aber damals wollte man den 8bit code weiterverwenden
Es wäre problemlos damals gegangen statt 32bit 64bit als basis zu nehmen.
nur sah man damals die Notwendigkeit nicht.

und 2002 war es zu spät da ab dem zeitpunkt zu viel software auf x86 basierte
Und viele der quellcodes verloren gegangen sind.
Darum ist der erste versuch von intel einen reinen x64 cpu zu entwickeln nicht geglückt.

[basix]

Soweit ich das verstehe, kann man alten Code problemlos weiterverwenden. Nur halt emuliert anstatt nativ. Solange das ohne wesentliche Performance-Nachteile klappt, ist doch alles gut? Für die Kompatibilität sorgen die CPU und das OS. Applikationen müssen nicht angepasst werden.

[lumines]

keiner wird jemals alte code in x86 was in etwa 100% der software auf windows programmiert ist auf eine native 64bit umschreiben.

Wie kommst du darauf, dass so viel Software 32-Bit-only ist?

Wie schon gesagt kann man das für die wenigen Anwendungen auch einfach emulieren. Performance sollte bei sehr alter Software dann auch kein Argument sein. Wahrscheinlich wäre die Performance trotz Emulation sogar besser als die Ausführung auf einer alten CPU, die 32 Bit noch nativ unterstützt.

Apple hat doch gezeigt, dass das problemlos möglich ist.

Die Frage ist im Grunde nur, wie lange so eine Emulationsschicht dann am Ende unterstützt wird. Bei Microsoft und Windows würde ich mir dabei aber eher weniger Sorgen machen.

[Shink]

Es gibt sicher noch jede Menge Legacy-Kram ala Access-Datenbank mit ODBC-Zugriff auf Datenbanken, deren Hersteller es nicht mehr gibt oder Delphi-Clients mit Borland Database Engine aber dafür reicht die Emulation sicher. Das Zeug läuft ja auch auf Windows on Arm.

Ich behaupte aber, das ist weniger als die postulierten "100% der Software" sind. Microsoft wird sich auch hüten, die Emulation davon bald auszubauen.

[davidzo]

Wie ist das eigentlich mit der Ram Belegung bei 64bit?
Rein theoretisch dürften doch bei doppelter Genauigkeit die binaries auch doppelt soviel Ram belegen? Von der Warte her macht es Sinn wenn viele Hintergrund-services noch mit 32bit laufen würden um mehr Kapazität frei zu machen für die performancekritischen Tasks.

[Exxtreme]

Wie ist das eigentlich mit der Ram Belegung bei 64bit?
Rein theoretisch dürften doch bei doppelter Genauigkeit die binaries auch doppelt soviel Ram belegen? Von der Warte her macht es Sinn wenn viele Hintergrund-services noch mit 32bit laufen würden um mehr Kapazität frei zu machen für die performancekritischen Tasks.

Das kann man pauschal so nicht sagen. Der RAM-Bedarf steigt, aber nicht um Faktor zwei. Was sind normalerweise verdoppelt sind sog. Zeiger/Pointer. Pointer sind Verweise auf einen Speicherbereich. Aber die machen nicht den Großteil einer Anwendung aus. Ansonsten legt der Programmierer die Größe der Daten fest. Ein uint16 bleibt weiterhin 16-bittig, egal ob die Anwendung 16- oder 32- oder 64-bittig ist. Der Verbrauch wächst in der Regel so um 20 - 30% im Schnitt.

[Shink]

Speicheradressen brauchen mehr Platz, dafür können 32 Bit Services auch nur auf weniger Speicher zugreifen.
Also: Ja, die Binaries brauchen weniger Platz bei 32 Bit. Dafür sind sie auch langsamer, da x86-64 z.B. mehr Register hat als x86. Da wurde mehr erweitert als der Adressraum.

[Skysnake]

Naja, CAD Software hat teils wegen Performance noch 32Bit Pfade.

Es ist im wissenschaftlichen Bereich auch durchaus möglich das mal in libs usw zu finden um bessere Performance zu bekommen.

[Exxtreme]

Speicheradressen brauchen mehr Platz, dafür können 32 Bit Services auch nur auf weniger Speicher zugreifen.
Also: Ja, die Binaries brauchen weniger Platz bei 32 Bit. Dafür sind sie auch langsamer, da x86-64 z.B. mehr Register hat als x86. Da wurde mehr erweitert als der Adressraum.

Kann man pauschal auch so nicht sagen. ;) Die zusätzlichen Register muss die Anwendung kennen und auch nutzen. Und zweitens, doppelt so große Zeiger = doppelt so großer Speicherplatzverbrauch = weniger Zeiger passen in den CPU-Cache. Was wiederum die Wahrscheinlichkeit für Cache-Misses z.T. stark erhöht.

[Shink]

Kann man pauschal auch so nicht sagen. ;) Die zusätzlichen Register muss die Anwendung kennen und auch nutzen.
Sollte doch hoffentlich der Compiler machen.
Die 32 Bit-Modi haben mit 8 halt wirklich sehr wenige General Purpose Register im Vergleich zu ARM, RISC oder gar PowerPC. Ich kann mir schwer vorstellen, dass das der Weisheit letzter Schluss ist.

[Zossel]

Mittlerweile tot (war mal upstream) aber ein lustiger Zwitter:

https://de.wikipedia.org/wiki/X32_(ABI)

Und es gibt ein paar Vergleiche:

https://doi.org/10.1016/j.procs.2013.05.394
https://www.sempria.de/hop/x32-ABI

[mksn7]

Der Performancevorteil könnte theoretisch ein Faktor 2x sein, wenn ein Code memory bound ist. Memory bound und viele pointer streamen ist aber eher eine ... kuriose Kombination.

Wenn es aber wirklich drauf ankommt, speichert man halt nur 32bit offsets und addiert die auf einen 64bit base pointer.

Zum Beispiel bei sparse matrix Formaten schaut man schon ob man nicht mit 32bit column indices auskommt, dann spart man sich bspw. bei SpMV 2B/Flop (von (8B+8B)/2Flop auf (8B+4B)/2Flop bei double precision). Aber wie gesagt, da wos drauf ankommt kann man dann schon herum programmieren.

[Shink]

Mittlerweile tot (war mal upstream)
Ist es wirklich tot? Laut dem englischen Wikipedia ist es noch upstream mit Stand April 2023. (Ich wüsste aber nicht, wie ich das "einfach" einsetze - Gentoo vermutlich?)

[Zossel]

Der Performancevorteil könnte theoretisch ein Faktor 2x sein, wenn ein Code memory bound ist. Memory bound und viele pointer streamen ist aber eher eine ... kuriose Kombination.

Wenn es aber wirklich drauf ankommt, speichert man halt nur 32bit offsets und addiert die auf einen 64bit base pointer.

Zum Beispiel bei sparse matrix Formaten schaut man schon ob man nicht mit 32bit column indices auskommt, dann spart man sich bspw. bei SpMV 2B/Flop (von (8B+8B)/2Flop auf (8B+4B)/2Flop bei double precision). Aber wie gesagt, da wos drauf ankommt kann man dann schon herum programmieren.

Pointer kann man auch in Registern halten, ein Pointer muss nicht immer zwingend aus dem Speicher geholt werden.

[Zossel]

Ist es wirklich tot? Laut dem englischen Wikipedia ist es noch upstream mit Stand April 2023. (Ich wüsste aber nicht, wie ich das "einfach" einsetze - Gentoo vermutlich?)

Oh, ich dachte es wäre schon rausgeflogen.
Irgendwas in der Richtung meinte ich mal gelesen zu haben.

[Fritter]

Wird ja auch Zeit das der alte Kram rausfliegt.

[Rabiata]

keiner wird jemals alte code in x86 was in etwa 100% der software auf windows programmiert ist auf eine native 64bit umschreiben.
Daher wird das nix
Ohne software basis wird sich das nicht durchsetzen hätte man das 1992 getan den radikalen schritt wäre es heute egal aber damals wollte man den 8bit code weiterverwenden
Es wäre problemlos damals gegangen statt 32bit 64bit als basis zu nehmen.
nur sah man damals die Notwendigkeit nicht.

und 2002 war es zu spät da ab dem zeitpunkt zu viel software auf x86 basierte
Und viele der quellcodes verloren gegangen sind.
Darum ist der erste versuch von intel einen reinen x64 cpu zu entwickeln nicht geglückt.
64bit im Jahre 1992?? Keine Chance in der PC-Welt.
x86-64 (die 64bit Erweiterung der Maschinensprache von x86) wurde im Jahre 1999 erstmals angekündigt. Den ersten Prozessor, der den Befehlssatz tatsächlich unterstützte, gab es 2003 von AMD. Siehe auch Wikipedia. (https://en.wikipedia.org/wiki/X86-64)
Hypothetisch hätte die Welt ab 1992 auf DEC Alpha umsteigen können, aber der Prozessor allein kostete über 1000 Dollar. Dazu die Kosten für das Umschreiben der Software...

Im Windows-Bereich wäre 32bit hardwareseitig auf dem i386-Prozessor oder neuer gegangen. Aber für manche Programmiersprachen war noch nicht mal ein 32bit Compiler verfügbar. Borland Delphi (Pascal mit OO-Erweiterungen) zum Beispiel war seinerzeit recht verbreitet, aber compilierte nur für den 16bit-Modus. Ein Delphi-Compiler für 32bit kam erst 1996 raus.

Und das allergrößte Problem ist, die Softwarehersteller und deren Kunden zum Umbau zu animieren. Das hätte 1992 genau so wenig geklappt wie heute. Speziell die Industrie ist da manchmal sehr langsam und konservativ. Die Welt frühzeitig umstellen zu wollen ist gut gemeint, aber der Versuch wird kläglich scheitern...

[Mortalvision]

Wozu 64bit, wenn man 512-bit programmieren kann. Da passt ja gleich die Verschlüsselung mit rein :freak:

[iamthebear]

keiner wird jemals alte code in x86 was in etwa 100% der software auf windows programmiert ist auf eine native 64bit umschreiben.
Daher wird das nix

1.) Man muss hier gar nichts "umschreiben". Ob 32 Bit oder 64 Bit Binaries produziert werden ist lediglich eine Compilereinstellung.

Das Problem in der Praxis:
Wenn man seine Applikation als 64 Bit Anwendung compiliert so können keine 32 Bit Libraries mehr geladen werden d.h. man muss dafür sorgen, dass man sämtliche Libraries auch als 64 Bit Version zur Verfügung hat.
Und hier wird es kompliziert, da man teilweise auf neuere Versionen updaten oder nach Alternativen suchen muss. Der Aufwand dafür kann von "einfach nur 1 Datei austauschen" bis hin zu "gar nicht realisierbar" gehen. Das muss alles individuell geprüft werden.

Dazu kommen noch ein paar Stolpersteine z.B. hat Windows bis heute keine 64 Bit Office ODBC Treiber integriert.

2.) Der WoW64 Modus wird soviel ich weiß nicht angetastet. Es wird also weiterhin Möglich sein 32 Bit Applikationen auf 64 Bit Betriebssystemen auszuführen genauso wie jetzt auch schon.
Es wird jedoch nicht mehr möglich sein 32 Bit Betriebssysteme auszuführen, was jedoch in der Praxis sowieso daran scheitern wird, dass es keine Treiber mehr dafür geben wird sobald Win10 nicht mehr supported wird.

Die Frage, die sich mir stellt ist, ob es noch möglich sein wird virtuelle 32 Bit Maschinen z.B. per HyperV auszuführen. Würde das nicht mehr funktionieren so kippt das gleich jede Menge Legacy Anwendungen aus der 2000/XP Zeit, die schon aus zig anderen Gründen nicht auf Windows 11 laufen.

[ryan]

Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end
https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end


War zwar schon länger bekannt, bis fehlte nur ein offizielles Statement. X86s war an Royal Core gekoppelt. Mit der Aufgabe vom Royal Core war x86s auch Geschichte.

[joe kongo]

Würde ich in einer VM wie zb VirtualBox ein altes XP oder W7 mit 32Bit Anwendungen laufen lassen wollen,
geht das dann nicht mehr obwohl virtualisiert?

[Zossel]

https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end


War zwar schon länger bekannt, bis fehlte nur ein offizielles Statement. X86s war an Royal Core gekoppelt. Mit der Aufgabe vom Royal Core war x86s auch Geschichte.

Intel verzettelt sich weiter.

[HOT]

Das war eh ne saublöde Idee. Mit x86s hätte Intel 30 Jahre eine komplett dichte und selbst kontrollierte Lizenz gehabt. Das würde mir der x86 group obsolet. Mit Royal Cote hatte das nix zu tun.

[Zossel]

Das war eh ne saublöde Idee. Mit x86s hätte Intel 30 Jahre eine komplett dichte und selbst kontrollierte Lizenz gehabt. Das würde mir der x86 group obsolet. Mit Royal Cote hatte das nix zu tun.

Verwechselst du das mit APX?

[basix]

So wie ich das in der News verstehe wird der X86S Alleingang beendet. Das heisst nicht, dass man keine Teile davon via x86 Advisory Group trotzdem weitertreibt. X86S war ja eher eine Entschlackung und Konzentration auf 64bit, glaube schon dass man das für die Zukunft für sinnvoll hält.

[mironicus]

Sie sollte lieber vorpreschen und alles auf ARM-Architektur umstellen. :tongue:

[Exxtreme]

So wie ich das in der News verstehe wird der X86S Alleingang beendet. Das heisst nicht, dass man keine Teile davon via x86 Advisory Group trotzdem weitertreibt. X86S war ja eher eine Entschlackung und Konzentration auf 64bit, glaube schon dass man das für die Zukunft für sinnvoll hält.

Ist halt fraglich ob das nennenswert was bringt. Das würde eventuell die Decoder etwas vereinfachen, viel mehr aber nicht. Es würde wahrscheinlich aber viel Ärger machen. Denn 32-Bit-Software ist ja weiterhin breit im Einsatz.

[Zossel]

Sie sollte lieber vorpreschen und alles auf ARM-Architektur umstellen. :tongue:

Ein Monopol statt einem Duopol ist noch beschissener.

[Zossel]

Ist halt fraglich ob das nennenswert was bringt. Das würde eventuell die Decoder etwas vereinfachen, viel mehr aber nicht. Es würde wahrscheinlich aber viel Ärger machen. Denn 32-Bit-Software ist ja weiterhin breit im Einsatz.

Der ganze X64-Kram bootet immer noch im Real-Mode (16-Bit). Und 32-Bite gibt es eigentlich nur noch in der Desktop-Nische von MS.

Und währenddessen im Rest der Welt:
- Make IA32_EMULATION boot time configurable with the new ia32_emulation=<bool> boot option.
https://lore.kernel.org/lkml/ZT0OqhIh%2F7c9IOYU@gmail.com/

[Ganon]

Eigentlich nur in der Desktop-Nische von MS.

Und währenddessen im Rest der Welt:


Auch der Steam Client unter Linux ist eine 32bit Anwendung. Also ein 08/15 Nutzer wird diese Einstellung vermutlich nicht setzen, auch wenn nur noch 64bit Spiele gespielt werden wollen.

edit:
Der ganze X64-Kram bootet immer noch im Real-Mode (16-Bit).

Nunja... der schaltet aber auch sofort in den 64bit Modus, denn UEFI ist auf so ziemlich jedem modernen PC 64bit.

[Exxtreme]

Der ganze X64-Kram bootet immer noch im Real-Mode (16-Bit). Und 32-Bite gibt es eigentlich nur noch in der Desktop-Nische von MS.

Und währenddessen im Rest der Welt:

https://lore.kernel.org/lkml/ZT0OqhIh%2F7c9IOYU@gmail.com/

Ist halt wiederum die Frage wieviel Performance so eine 32-Bit-Emulation kostet. Die Alpha-CPUs sind u.A. deshalb gescheitert weil deren x86-Emulation nicht sehr schnell war. Und eine 32-Bit-Emulation auf OS-Ebene dürfte noch viel lahmer sein.

[Ganon]

Ist halt wiederum die Frage wieviel Performance so eine 32-Bit-Emulation kostet.

Man sollte sich an der Stelle nicht von "Emulation" verwirren lassen. Bei dem Flag geht es darum, dass man bei x86_64 die Ausführung von 32bit Code auf einem 64bit Kernel (was eine x86_64 CPU nativ unterstützt) verbietet. Standardmäßig ist diese eingeschaltet.

Kenne den Stand nicht global, aber ich glaube aktuell arbeitet niemand an einer direkten "i386 Emulation" auf einen x86_64 System (im Sinne von wie für ARM gerade getan wird). Der Fokus liegt aktuell bei ARM und RISC-V als Zielsystem (Box64 / Box86 / FEX-Emu)

[Zossel]

Man sollte sich an der Stelle nicht von "Emulation" verwirren lassen. Bei dem Flag geht es darum, dass man bei x86_64 die Ausführung von 32bit Code auf einem 64bit Kernel (was eine x86_64 CPU nativ unterstützt) verbietet. Standardmäßig ist diese eingeschaltet.

Kenne den Stand nicht global, aber ich glaube aktuell arbeitet niemand an einer direkten "i386 Emulation" auf einen x86_64 System (im Sinne von wie für ARM gerade getan wird). Der Fokus liegt aktuell bei ARM und RISC-V als Zielsystem (Box64 / Box86 / FEX-Emu)

https://www.qemu.org/docs/master/about/emulation.html

[Zossel]

Auch der Steam Client unter Linux ist eine 32bit Anwendung. Also ein 08/15 Nutzer wird diese Einstellung vermutlich nicht setzen, auch wenn nur noch 64bit Spiele gespielt werden wollen.

Wahrscheinlich werden diverse Distros demnächst einfach 32-Bit per Default abschalten um den Druck auf solchen Legacy-Kram zu erhöhen.

[Pirx]

mit AMD64 hoffentlich:ulol: (oder wollen sie ihren Itanium wieder ausgraben?)

[Ganon]

https://www.qemu.org/docs/master/about/emulation.html

Wie ich extra dazu geschrieben habe "Im Sinne wie es für ARM gerade getan wird". Mit reinem QEMU(-User) wirst du keine Spiele spielen.

[basix]

Ist halt fraglich ob das nennenswert was bringt. Das würde eventuell die Decoder etwas vereinfachen, viel mehr aber nicht. Es würde wahrscheinlich aber viel Ärger machen. Denn 32-Bit-Software ist ja weiterhin breit im Einsatz.

Intel als x86 Hoheit sieht anscheinend einen Nutzen darin und ich glaube sie kennen die Vorteile am besten ;) Für mich heisst das, es gibt nennenswerte Vorteile. Chipfläche wird man wohl nicht viel sparen aber Testing/Verifikation usw. wird entschlackt. System und OS können evtl. entschlackt werden. Geringere Anzahl Points-of-Failure etc.

[Exxtreme]

Intel als x86 Hoheit sieht anscheinend einen Nutzen darin und ich glaube sie kennen die Vorteile am besten ;) Für mich heisst das, es gibt nennenswerte Vorteile.

Das sahen sie bei der Itanic (https://de.wikipedia.org/wiki/Intel_Itanium) auch. Und wie das ausgegangen ist, das weiss man ja. :freak: Und solche Entscheidungen haben oft nicht unbedingt technische Gründe. Kann sein, dass sich das Management da was ausgedacht hat um AMD als Konkurrenz irgendwie loszuwerden.

Man sollte sich an der Stelle nicht von "Emulation" verwirren lassen. Bei dem Flag geht es darum, dass man bei x86_64 die Ausführung von 32bit Code auf einem 64bit Kernel (was eine x86_64 CPU nativ unterstützt) verbietet. Standardmäßig ist diese eingeschaltet.



Ohhh, danke. Dann habe ich es wohl missverstanden. :freak:

[Hauwech]

Hat zwar mit 32/64 bit nicht viel zu tun aber gab es nicht mal vor vielen vielen Jahren den Plan oder besser gesagt eine Idee so eine Morphing CPU (wahrscheinlich noch 32bit) auf ARM-Basis zu bauen die halt ARM und X86 Befehle konnte? Nicht von Intel oder AMD sondern irgendein kleines Startup (BitBoys Oy oder so)?

[amdfanuwe]

Kann eigentlich nicht sein, sie hätten keine X86 Lizenz bekommen.
Es gab aber mal ein Projekt von AMD, das sie eine Sockel Kompatible ARM CPU bauen wollten.
Projekt Skybridge.
Wurde mangels Nachfrage eingestellt.

[Brillus]

Würde ich in einer VM wie zb VirtualBox ein altes XP oder W7 mit 32Bit Anwendungen laufen lassen wollen,
geht das dann nicht mehr obwohl virtualisiert?

Nein hätte so nicht funktionert. Da hättest du richtigen Emulator gebraucht welche die Arch Emulieren wie Dosbox oder die ganzen Konsolen Emus.

[HOT]

https://www.qemu.org/docs/master/about/emulation.html

Windows on Windows ist auch ne Emulation, läuft aber vollständig in Hardware und das ist überhaupt nichts schlimmes. Es gibt keine Einschränkungen dadurch, dass X64-Prozessoren auch IA32 unterstützen. Auch wenn eine x86-CPU noch in 16Bit bootet ist das ebenfalls nichts schlimmes und auch hier hast du keinen Nachteil daraus. Bei der Intel-Aktion ging es wirklich nur darum, eine eigene Lizenz für Jahre fahren zu können und die Kontrolle über den Befehlssatz zu behalten. Nachdem man den Befehlssatz jetzt in ein Konsortium ausgelagert hat (x86 EAG), ist das jetzt nicht mehr nötig.
Wenn der Qualcomm-Prozessor auch ne x86-Lizenz hätte, könnte Qualcomm Decoder und Firmware bauen, die beides verstehen würden und könnten x86 auf ARM nativ emulieren, das wäre dann auch schnell. So würden sie das natürlich nicht machen, in dem Fall würde Qualcomm einfach die ARM-Lizenz einsparen ;). Ich bin mir auch relativ sicher, dass Intel jetzt begriffen hat, dass Kooperation besser ist als x86 weiterhin total restriktiv zu handhaben. Das Lizenzgeschäft könnte für Intel ebenfalls noch wichtig werden, vielleicht kann sich Qualcomm und NVidia irgendwann einfach x86 in aktueller Form lizenzieren.

[latiose88]

Und hat Intel das schon umgesetzt oder wird das noch so kommen. Weil von der Bemühung was Intel da angekündigt hat merkt man ja davon nix mehr.

[Skysnake]

Hat zwar mit 32/64 bit nicht viel zu tun aber gab es nicht mal vor vielen vielen Jahren den Plan oder besser gesagt eine Idee so eine Morphing CPU (wahrscheinlich noch 32bit) auf ARM-Basis zu bauen die halt ARM und X86 Befehle konnte? Nicht von Intel oder AMD sondern irgendein kleines Startup (BitBoys Oy oder so)?
NVidia hatte das wenn ich mich recht erinnere mit ihren Denver cores vor. Wegen fehlender x86 Lizenz wurde daraus nichts.

[Exxtreme]

Und hat Intel das schon umgesetzt oder wird das noch so kommen. Weil von der Bemühung was Intel da angekündigt hat merkt man ja davon nix mehr.

Die haben das offiziell abgeblasen.

[PatkIllA]

Hat zwar mit 32/64 bit nicht viel zu tun aber gab es nicht mal vor vielen vielen Jahren den Plan oder besser gesagt eine Idee so eine Morphing CPU (wahrscheinlich noch 32bit) auf ARM-Basis zu bauen die halt ARM und X86 Befehle konnte? Nicht von Intel oder AMD sondern irgendein kleines Startup (BitBoys Oy oder so)?
Transmeta Crusoe (https://en.wikipedia.org/wiki/Transmeta_Crusoe)

[iamthebear]

Die Frage ist nur was das bringen soll. Für Qualcomm, Nvidia ist es keine Option, da sie keine x86 Lizenz haben.
Und Intel/AMD haben eine x86 Lizenz also wieso sollen diese eine ARM CPU für Windows bauen wenn es Stand jetzt keine Software gibt für die nur ARM Code verliegt.