Altlasten beseitigen: Intel will hin zum 64-Bit-only-Mode

[Botcruscher]

Die Vorteile wären?

 

[jdl]

Hätte Intel nicht auf x64 umgeschwenkt sondern weiter auf IA64 mit x32 Emulation gesetzt, hätten sie ziemlich sicher massiv an Marktpräsenz verloren. Der riesen Vorteil vom AMD64 war, dass die alten Programme weiterhin nativ laufen konnten und gleichzeitig der Adressraum für 64Bit zur Verfügung stand.

IA-64 ist nicht an der x86 Unterstützung gescheitert, sondern weil IA-64 diverse Probleme hatte (VLIW Design), die man meinte mit besseren Compiler in den Griff zu bekommen und schlussendlich nie lösen konnte.
Der Erste Itanium (Merced) verfügte übrigens über eine x86 Hardware. HP, der große Premium Partner von Intel, hat dann aber Recompiler für Itanium geschrieben, weil sie das für den eigenen HP-PA Code unbedingt brauchten. Da zeigte sich sehr schnell, dass der Recompiler deutlich bessere Performance mit alten x86 Code lieferte als die eingebaute x86 Hardware im Merced. Ab dem Itanium 2 hat man dann die x86 Hardware weggelassen. Itanium wurde dann im wesentlichen als OpenVMS und HP-UX Plattform für HP gepflegt und vertrieben. Erst als das DoD sein Ok gab (Portierung von OpenVMS auf Intel64/MAD64), durfte Intel Itanium einstellen, weil das DoD OpenVMS auch weiterhin benötigt.

Mit IA64 hätte Intel das ganz sicher nicht geschafft, da es eine komplett neue Architektur war, die mit dem alten Code nur über Software umgehen konnte und somit im Vergleich grotten langsam war.

Der HP Recompiler lieferte in Relation zum IA-64 Code ordentliche Performance ab. Das Problem war der IA-64 Mode selbst.

Beitrag automatisch zusammengeführt: 20.05.2023

Die Vorteile wären?

Weniger Altlasten im Design, und damit weniger Potential für Angriffe. Die komplette Architektur ist ein übler Hack, der damals mit dem Intel 8080 8Bit Prozessore anfing. Damit man Programme vom 8080 leicht auf den 8085 portieren konnte (Binärkompatibel waren die CPUs nicht), musste man sie nur mit dem Assembler neu übersetzen. Assembler war damals die wichtigste Sprache für Programme auf solche kleinen Prozessoren. Hochsprachen wurden üblicherweise auf größeren Systemen genutzt. 8080 und 8085 sind 8Bit CPUs mit 16Bit Adressraum. Der für den PC verwendete 8088 ist ein 8086 mit auf 8Bit verringertem Bus, dadurch wurde der PC billiger. Der 8086/8088 ist ein 16Bit Prozessor, der die 8Bit Programme für 8080 und 8085 ausführen konnte. Dafür war es aber notwendig, dass die Adressregister 16Bit groß blieben. Das Problem wurde dann dadurch gelöst, dass im 8086 Modus ein Indexregister mit 4Bit an das eigentliche Adressregister rangefrickelt wurde. Je nachdem im welchen Modus man ein Programm ausführte gab es dann 16Bit oder 20Bit Zeiger und wenn man nicht aufpasste alles zur gleichen Zeit. Mit dem 80286 wurde die Sch*** noch komplexer, und erst mit dem 80386 wurde dann ein sauberer 32Bit Modus eingeführt.

Dann ist da noch das Thema FPU x87, von der Intel sagt man solle sie nicht mehr nutzen und nur noch SSE bzw. AVX nutzen.

 

[Rudi Ratlos]

Die Vorteile wären?

Eigentlich nur auf Seiten der Hersteller. Sie können neue Hard- und Software-Produkte verkaufen, an jene, die aufrüsten müssen, weil die alte Technik inkompatibel gemacht wird.

Erlebt man ja immer wieder. So mit Windows11, das teilweise völlig grundlos ältere, mit Win10 problemlos laufende Hardware aussortierte, obwohl diese mit Win11, das ja auch nur eine Art "Win10 SP2" ist, ganz normal funktioniert!

So wie mein Laptop, der wegen des Ryzen 5 2500U nur mit Klimmzügen zum Upgrade 10->11 zu überreden war. Witzigerweise funktionierte kürzlich die Direktinstallation von Win11 per Stick ohne jegliche Probleme.... Keine Warnmeldung, nix....

 

[Holt]

Obwohl ich mich schon frage, ob 32 Bit Systeme, Befehlssätze und Programme überhaupt noch Sinn machen. Vielleicht wird dadurch das Windows schlanker, schneller und stabiler (die Hoffnung stirbt zuletzt)?

Windows ist och stabil, ich habe mit meinen Windows Installationen schon seit XP keine Probleme gehabt und nie eine Neuinstallation ausführen müssen. Schlanker wäre es in dem Sinne, dass man weniger Platz auf C: dafür brauchen würde, aber so teuer sin 1TB SSDs nicht mehr und heute Mainstream, da machen die paar GB auch nichts aus.

Klar man könnte seitens windows viel bereinigen, aber damit würde man auch sehe vieles einbüßen. Ich kann heute noch spiele für windows 95 auf meinem W10 spielen.

Eben, wobei Spiele das geringste sind, aber welche Software die man vielerorts nutzt, hat noch 32 Bit Code oder dlls enthalten? Würde bei mir noch alles so laufen, wenn kein 32 Bit Code mehr ausgeführt werden kann? Sicher nicht.

An Intel, denkt daran: "if it ain't broke, don't fix it!"

 

[pillenkoenig]

Windows ist auch nicht 'broken'. Darum fixt es keiner. Und deshalb ist es so ein Schrott.

 

[OCBBlackEdition]

Ich glaub Winrar war schuld und als einziger in x64 mod. Erhältlich nach nach kamen einigen Programme obwohl
win beides hatte 32 und 64 mod. Ich glaub man konnte sogar beides benutzten. Man sagt XP nach und deren
Instabilität sei verschuldet da ungenau in 32 geschrieben. 64 hat auch mehr Leistung abverlangt da längere Code

 

[Gurkengraeber]

Ich lese das so, dass Intels Weg schon damals der konsequentere gewesen wäre und wir heute schon weiter wären, wenn die 32bit Abwärtskompatibilität nicht durch AMD hoffähig gemacht worden wäre.

 

[Infi88]

An die Profis hier, was kommt als nächstes, 128-Bit, oder ist das Blödsinn und unnötig?

Evtl. bist du schon Nutzer des von Intel geschaffenen technischen Wunders https://de.wikipedia.org/wiki/Advanced_Vector_Extensions
Ansonsten würde ich sagen wird es problematisch für 64bit, wenn 16 Exabyte Arbeitsspeicher nicht mehr aussreichen.

Erlebt man ja immer wieder. So mit Windows11, das teilweise völlig grundlos ältere, mit Win10 problemlos laufende Hardware aussortierte, obwohl diese mit Win11, das ja auch nur eine Art "Win10 SP2" ist, ganz normal funktioniert!

So wie mein Laptop, der wegen des Ryzen 5 2500U nur mit Klimmzügen zum Upgrade 10->11 zu überreden war. Witzigerweise funktionierte kürzlich die Direktinstallation von Win11 per Stick ohne jegliche Probleme.... Keine Warnmeldung, nix....

Was hat das mim Thema zu tun ? Der Ryzen 5 erfüllte wohl die WHCP seitens Microsoft nicht, malst du dir auch da wieder eine Verschwörung gegen dein AMD aus ?

 

[DTX xxx]

Da fühlt sich ein Intel Fanboy auf den Schlipps getreten, ist schon zum totlachen...

Letztlich ist es ein beliebiger Konzern und du wirst immer ein Fanboy dieser beliebigen Firmen sein bei den Intel-Ultras , wenn du dich nicht bedingungslos Intel unterwirfst. Um zu zertifizieren, dass du auf Lebenszeit nie mehr als Fanboy irgendeiner beliebigen Firma bezeichnet werden darfst, muss du einen Ahnenschrein mit allen CEOs von Intel besitzen und täglich eine Kerze anzünden. Natürlich ist dieses Zertifikat auch ein ultimativer Beleg, dass man dann auch kein Intel Fanboy ist. Ist doch logisch. Man ist ja dann der leibeigene von Intel.

Seit ihrer Einführung vor über 20 Jahren hat sich die 64-Bit-Architektur von Intel zum vorherrschenden Betriebsmodus entwickelt.

Um einer Missstimmung vorgreifen zu können, denn man muss diesen Satz einfach falsch verstehen, sollte man es anders formulieren.
Seit ihrer Einführung des 64bit Betriebsmodus vor über 20 Jahren, haben sich die 64-Bit Prozessorarchitekturen zum vorherrschenden Betriebsmodus entwickelt.

 

[Rudi Ratlos]

, malst du dir auch da wieder eine Verschwörung gegen dein AMD aus ?

Unterstelle mir doch bitte nicht deine Projektionen.

 

[Infi88]

Seitenweise Projektionen im Essay Format sind Sache des AMD Apostel, nicht meine.

 

[Zeitmangel]

Bitte überarbeiten!
[...]
Im Grunde geht es darum, PCs schneller zu initialisieren.

Na also. Dachte schon auf Luxx muss es doch gleich Leute geben die es wirklich verstanden haben... Gibt es Was die anderen hier erzählen bleibt wie so oft ein OT-Rätsel.
Das ist nur ein PR-Gag, um sich als Innovationsantreiber darzustellen. Als wenn die Initialisierung der Kisten heute irgendeine Art Problem darstellen würde das man endlich angehen sollte

PS: @all
An die Jüngeren... AMD64 hat sich durchgesetzt, weil Microsoft wie auch die großen industriellen Linuxdistris + Compilerbauer sagten, daß ist DAS Ding und sie werden das unterstützen. Und sehen eigentlich nicht ein warum man hier noch etwas anderes machen sollte. Die unixoiden waren kurz daraufhin auch dabei. Damit war das eine klare Botschaft an Intel:
"Wenn du das nicht mitmachst, bist du bei 64bit raus. Wegen deinem Itanium haben wir jetzt genug geflucht. Ihr habt noch genug Sachen mit ISA-Erweiterungen zu klären, also seh zu, daß du das mit AMD gegenseitig regelt und nutze es für deine Gesichtswahrung."

Es ging nie um eine Marktdurchdringung. Sobald AMD bestätigte, daß sie das wie vorgestelt und demonstriert auch liefern können, war das Thema für die Obenerwähnten durch.

 

[DerBandi]

Das es mit Intel und AMD zwei Anbieter für ein so komplexes Stück Hardware gibt, liegt nur daran dass es eine umfangreiches Technologie-und Patentaustausch-Vereinbarung gibt, die in beide Richtungen funktioniert, und immer wieder verlängert und erweitert wird.

Trotzdem ist es falsch, bei diesem Feature "von Intel" zu schreiben. Man möchte als Author eines Fachartikels schon gerne präzise bleiben und nicht falsche Dinge suggerieren, oder?

 

[Botcruscher]

Weniger Altlasten im Design, und damit weniger Potential für Angriffe. Die komplette Architektur ist ein übler Hack, der damals mit dem Intel 8080 8Bit Prozessore anfing. Damit man Programme vom 8080 leicht auf den 8085 portieren konnte (Binärkompatibel waren die CPUs nicht), musste man sie nur mit dem Assembler neu übersetzen. Assembler war damals die wichtigste Sprache für Programme auf solche kleinen Prozessoren. Hochsprachen wurden üblicherweise auf größeren Systemen genutzt. 8080 und 8085 sind 8Bit CPUs mit 16Bit Adressraum. Der für den PC verwendete 8088 ist ein 8086 mit auf 8Bit verringertem Bus, dadurch wurde der PC billiger. Der 8086/8088 ist ein 16Bit Prozessor, der die 8Bit Programme für 8080 und 8085 ausführen konnte. Dafür war es aber notwendig, dass die Adressregister 16Bit groß blieben. Das Problem wurde dann dadurch gelöst, dass im 8086 Modus ein Indexregister mit 4Bit an das eigentliche Adressregister rangefrickelt wurde. Je nachdem im welchen Modus man ein Programm ausführte gab es dann 16Bit oder 20Bit Zeiger und wenn man nicht aufpasste alles zur gleichen Zeit. Mit dem 80286 wurde die Sch*** noch komplexer, und erst mit dem 80386 wurde dann ein sauberer 32Bit Modus eingeführt.

Dann ist da noch das Thema FPU x87, von der Intel sagt man solle sie nicht mehr nutzen und nur noch SSE bzw. AVX nutzen.

Das reicht mir als Erklärung nicht. Auch heute ist alles Assembler. Ob da übersetzt wird ist für das Thema nicht relevant. Ich hab bis zum Abi genug Speicheradressen durch die Alu und zurück geschubst. Nach der Initialisierung läuft der 32Bit Code wie vorher. Deine Ausflüge in die Geschichte sind also nicht besonders relevant.

Im Grunde geht es darum, PCs schneller zu initialisieren.

Bessere Erklärung. Im Grunde ändert sich am Prozessor eigentlich so gut wie nichts.

 

[Rudi Ratlos]

Das es mit Intel und AMD zwei Anbieter für ein so komplexes Stück Hardware gibt, liegt nur daran dass es eine umfangreiches Technologie-und Patentaustausch-Vereinbarung gibt, die in beide Richtungen funktioniert, und immer wieder verlängert und erweitert wird.

Trotzdem ist es falsch, bei diesem Feature "von Intel" zu schreiben. Man möchte als Author eines Fachartikels schon gerne präzise bleiben und nicht falsche Dinge suggerieren, oder?

Jupp! Aber daß man hier gleich als "AMD-Fanboy" diffamiert wird, wenn man einen sachlichen Fehler im Artikel richtigstellt, ist irgendwie typisch Foren-Parallelwelt. Wäre es anders herum, gewesen, und Intel 64bit hätte sich durchgesetzt, und im Artikel stünde AMD, hätte ich dasselbe geschrieben - nur eben umgekehrt.

Und das hat reinweg gar nichts damit zu tun, daß ich eher Sympathien für AMD habe, eben WEGEN der Zeit, in der auch 64bit im Massenmarkt kam. Denn damals hat Intel seine Marktmacht auf illegale Weise durchgesetzt, indem es mit Händlerketten Verträge abschloß, die bei einer Beteiligung an deren Werbeausgaben (mit dem Label "Intel inside") sicherstellte, daß diese fast keine oder gar keine AMD-Produkte anboten. Und das wohlgemerkt zu einer Zeit, als AMD-CPUs fast durch die Bank technisch besser waren, sich also nach den gängigen Marktregeln auch hätten viel besser etablieren müssen.

Bekannt wurden solche Deals etwa mit Dell aber auch Metro (Mediamarkt & Saturn). Und dafür mußte Intel ja auch eine Strafe zahlen., Viel zu spät und viel zu wenig, aber damit war die Sache auch offiziell.
Deshalb lehne ich Intel-Produkte nicht aus ideologischen Gründen ab, im Gegenteil! Ich habe zwei PCs, einen produktiven, in dem ein Ryzen steckt, und einen Dauerläufer, der zB. als Videorekorder (Satelliten-TV) dient. Da war mir der Leerlaufverbrauch wichtig, und deshalb ist dort ein Intel verbaut. Und als Grafikkarte im Produktiv-PC ist wiederum seit kurzem auch eine Intel verbaut, weil die aktuell den besten Hardware-Encoder für Videorendering auf dem Markt haben.

Alles pragmatisch. Im Übrigen hat die Kooperation von Intel und AMD im x86-Markt ja eine historische Ursache. AMDs x86-Geschichte begann einst als Lizenzfertiger für Intels 8086er CPUs, auf deren Basis sie dann ab Anfang der 90er Jahre eigene x86-Designs entwickelten (AMD K5 vs. Intel Pentium).

 

[nebulus1]

Man möchte als Author eines Fachartikels schon gerne präzise bleiben und nicht falsche Dinge suggerieren, oder?

Manche Artikel hier wurden wohl in der Bar, nach 10 Bier geschrieben...

 

[Holt]

Ich lese das so, dass Intels Weg schon damals der konsequentere gewesen wäre und wir heute schon weiter wären, wenn die 32bit Abwärtskompatibilität nicht durch AMD hoffähig gemacht worden wäre.

Das kann man so sehen, aber Kompatibilität und gerade auch die Abwärtskompatibilität war immer das Erfolgsrezept der PCs auf x86 Basis und dürfte der Grund sein, warum diese sich so durchgesetzt haben, wie wir es heute kennen. Die alten Zöpfe abzuschneiden klingt im ersten Moment immer gut, aber wenn genau diese Zöpfe das Erfolgsgeheimnis sind, dann sieht die Sache schnell anderes aus.

 

[smalM]

Ansonsten würde ich sagen wird es problematisch für 64bit, wenn 16 Exabyte Arbeitsspeicher nicht mehr aussreichen.

Scherzkeks. Bei der Diskussion um den 128bit Adreßraum geht es um Virtuellen Speicher, nicht um das RAM.

Ich lese das so, dass Intels Weg schon damals der konsequentere gewesen wäre und wir heute schon weiter wären, wenn die 32bit Abwärtskompatibilität nicht durch AMD hoffähig gemacht worden wäre.

Nein, Intels Weg war ein Sackgasse und AMDs Weg war Gefrickel.
Das ist aber heutzutage egal, da das, was als X64-Architekturmodell präsentiert wird, und das, was in den Prozessoren tatsächlich abläuft, eh zwei völlig verschieden Paar Stiefel sind. Ständen bspw. den CPUs nur die 3 Dutzend X64-Register zur Verfügung statt Hunderter Schattenregister, die Leistung würde völlig in den Keller fallen.

 

[jdl]

Das reicht mir als Erklärung nicht. Auch heute ist alles Assembler.

Heute schreibt niemand mehr größere Programme in Assembler. Assembler war auf 8Bit Systemen und mit Einschränkungen auf 16Bit PC/Home-Computer üblich. Da auf den 16Bit Minicomputer Anfang der 1970er sich UNIX etabliert hatte, und damit die Programmierung in der Programmiersprache C etablierte, wurde das auch unter MS-DOS, AmigaOS (Commodore nutze konsequent C und das OS war selbst in C geschrieben) und auf dem Atari in den 1980er immer bedeutender. Apple mit dem Mac hatte zuerst ObjectPascal als Programmiersprache vorgesehen, und ist dann erst später auf C bzw. C++ gewechselt.

Die Historie ist wichtig, weil sie erklärt weshalb Intel die Kompatibilität mit den älteren 8Bit CPUs beim 8086 eingebaut hatte. Ab dem 8086 hat Intel dann nicht mehr nur die Source-Kompatibilität vorgesehen, sondern wegen der steigenden Bedeutung auch noch Binärkompatibilität. D.h. lange Zeit liefen Programme für MS-DOS 8086 auch auf neueren 80386 und Nachfolgern vollkommen unverändert. Deshalb haben auch noch moderne Intel/AMD-CPUs noch immer massenweise Altlasten aus 8Bit Zeiten in der CPU. Z.B. lassen sich Register als 8Bit Register ansprechen, und nicht als 64Bit Register mit 8Bit Argument, wie das z.B. bei RISC-Plattformen üblich ist.

Ob da übersetzt wird ist für das Thema nicht relevant. Ich hab bis zum Abi genug Speicheradressen durch die Alu und zurück geschubst. Nach der Initialisierung läuft der 32Bit Code wie vorher. Deine Ausflüge in die Geschichte sind also nicht besonders relevant.

Tja, wenn man nicht viel weiß, dann versteht man vieles nicht.

 

[Holt]

Intels Weg war ein Sackgasse

Aber nur, weil die Akzeptanz gefehlt hat, eben weil es wenig Software dafür gab, da ja die alte Software für x86 nicht darauf lief.

AMDs Weg war Gefrickel.

Eben, aber es hat sich durchgesetzt, eben weil man die ganze bestehende x86 Software weiterhin darauf laufen lassen konnte. Ein Rechner ohne die nötige Software ist eben sinnlos und es ist extrem schwer eine Architektur mit einem neuen Befehlssatz durchzusetzen, gerade in einem Segment wie x86 wo unzählige Firmen die Software für die Rechner herstellen. Die muss man alle erstmal davon überzeugen diese auch für die neue Hardware anzubieten und dann hat man das Henne Ei Problem, denn wenn die Hardware nicht weit verbreitet ist, warum sollte der SW Anbieter den Aufwand betreiben und wenn es nicht die entsprechende Software gibt, warum sollte man sich dann die Hardware kaufen? Daran ist auch IA-64 gescheitert, zumal nachdem AMD mit x86_64 dann eine Alternative geschaffen hatte, die dieses Problem eben nicht hatte.

Es gibt eben immer zwei Seiten zu einer Sache und AMDs Gefrickel war das kleinere Übel und hat Intels Weg zur Sackgasse gemacht. War das im Nachhinein gut oder schlecht? Gute Frage, aber trotzdem total irrelevant, weil man die Zeit nicht zurückdrehen kann. Aber Intel sollte die Lektion von damals nicht vergessen und wenn es die Abwärtskompatibilität zu sehr beseitigt, dürfte es nicht besser enden als damals.

 

[L0rd_Helmchen]

Oh man ey. Es ist doch vollkommen offensichtlich, dass der Autor sich mit der Bezeichnung "die 64-Bit-Architektur von Intel" auf EM64T bezieht. Dies basiert auf AMD64, ist aber nicht identisch und stellt eben Intels Architekturvariante einer x86-64 Implementierung dar. Der Autor hat nicht behauptet, Intel hätte x86-64 erfunden. Das ist albern, genauso wie die Vorstellung, dass AMD "64-Bit erfunden" hätte. Geil wie sich die AMD Fanboys erstmal zwei Seiten lang entrüsten

 

[Liesel Weppen]

Oh man ey.

Der Thread taugt auf jedenfall um die Ignoreliste zu füllen.

Oder zu "verifizieren" wer eh schon drauf steht.

 

[Holt]

stellt eben Intels Architekturvariante einer x86-64 Implementierung dar.

Architektur ist ein ganz unpassendes Wort, denn Intel und AMD haben inzwischen viele verschiedene Architekturen rausgebracht, die allen den x86_64 Befehlssatz implementieren. Bei ARM kann man auch entweder die ganze Architektur lizensieren, oder eben nur den Befehlssatz und wenn man letzteres macht, muss man eben die Architektur selbst schaffen, die diesen Befehlssatz implementiert und dafür sorgen, dass jeder Befehl auch das macht was er soll. DEC hat letzteres bei ARM gemacht und dann seine eigene StrongARM Architektur entwickelt, die eben den ARM v4 Befehlssatz implementiert hat, Intel hat diese Sparte übrigens 1997 von DEC übernommen und daraus die XScale Modelle entwickelt. Ohne die Details zu kennen, würde ich trotzdem davon ausgehen, dass Intel von AMD nur den 64 Bit Befehlssatz im Rahmen ihres Patentabkommens übernommen hat und nicht die ganze CPU Architektur dahinter.

 

[smalM]

Aber nur, weil die Akzeptanz gefehlt hat, eben weil es wenig Software dafür gab, da ja die alte Software für x86 nicht darauf lief.

Die mangelhafte Unterstützung von IA-32 in Hardware war arrogant und dumm. Die Programme liefen, aber grottenschlecht.
Das ging einfach am Markt vorbei; Intel hatte gedacht, sie besäßen die Marktmacht, dabei lag die bei den Softwareherstellern, insbesondere MS.
Der Ansatz von EPIC war überkanditelt und hat nie wirklich gut funktioniert.
Witzigerweise ähnelt aber ein Itanium im inneren Hardwareaufbau einer modernen x86-64 CPU mehr als die damaligen x86 CPUs.

Ohne die Details zu kennen, würde ich trotzdem davon ausgehen, dass Intel von AMD nur den 64 Bit Befehlssatz im Rahmen ihres Patentabkommens übernommen hat und nicht die ganze CPU Architektur dahinter.

Ja, Intel hat seine eigene Architektur auf 64bit aufgebohrt: P3 -> Yonah -> Merom. Intern sind AMD- und Intel 64b-CPUs völlig unterschiedlich organisiert.

 

[Holt]

Witzigerweise ähnelt aber ein Itanium im inneren Hardwareaufbau einer modernen x86-64 CPU mehr als die damaligen x86 CPUs.

Da beides 64 Bit Architekturen waren, würde ich es eher als logischerweise als witzigerweise bezeichnen.

 

[tonythebuilder]

So nach zwei Seiten voller interessanter, manchmal sinnvoller und auch fragwürdiger Antworten. Wurde eine Frage immer noch nicht gekärt.
Kann ich auch zukünftig, ohne all zu großes Basteln, auch meine 8Bit, 16Bit und 32Bit Programme ausführen?

Klar Windows 1.0 auf einem aktuellen Ryzen/Ix macht nicht viel Sinn, cool wäre es trotzdem.

 

[Holt]

Kann ich auch zukünftig, ohne all zu großes Basteln, auch meine 8Bit, 16Bit und 32Bit Programme ausführen?

Nach Intels Plänen dann nicht mehr. Wobei ich da aber nur die 32 Bit Programme als wirklich relevant ansehen würde, die noch älteren Programme dürften sowieso auf aktuellen Systemen kaum noch oder gar nicht mehr laufen und inzwischen wirklich durch neuere Programme ersetzt worden sein.

 

[Rudi Ratlos]

Für Programme kommt es wohl darauf an,. ob das 64-bit-OS eine entsprechende Unterstützung oder Emulation hat. Ältere OS aber gehen dann nicht.

 

[nebulus1]

So nach zwei Seiten voller interessanter, manchmal sinnvoller und auch fragwürdiger Antworten. Wurde eine Frage immer noch nicht gekärt.
Kann ich auch zukünftig, ohne all zu großes Basteln, auch meine 8Bit, 16Bit und 32Bit Programme ausführen?

Klar Windows 1.0 auf einem aktuellen Ryzen/Ix macht nicht viel Sinn, cool wäre es trotzdem.

8Bit -> Dosbox
16Bit -> Dosbox
32Bit-> 64Bit Windows nativ, der 32Bit Modus wird NIE abgeschaltet.

Windows 1.0 läuft auch im Browser: https://copy.sh/v86/?profile=windows1


Der ganze Fred ist Sinnbefreit.

 

[Zeitmangel]

Die mangelhafte Unterstützung von IA-32 in Hardware war arrogant und dumm. Die Programme liefen, aber grottenschlecht.

Aha. Als wenn IA-64 gut drauf gelaufen wäre... Bei der war es extrem wichtig wie der Compiler den Code ordnet. Und zwar jeweils Programmpsezifisch bzw. Routinespezifisch. Eigentlich rbauchte das Ding eine Compiler-KI gegenüber ChatGPT immernoch lächerliches Spielzeug ist.
Und das haben sie nicht in dem Tempo gebacken bekommen wie x86(-64) sich in der Zeit leistungsmäßig weiterentwickelt hat. Irgendwann war diese Idee dann in jeder Hinsicht eben "überholt".

Die Idee von Apple beim Umstieg die Kompatibilität in eine Softemu zu schieben ist besser (für die neue Architektur), aber für den PC nicht realisierbar. Wenn Apple etwas tut, betrifft das nur OSX. Wenn Intel/AMD etwas tun, betrifft das die ganze Welt mit mehr als nur einer Handvoll Betriebssysteme.
Das ist als wenn AMD/Intel gemeinschaftlich ein x86-Rosetta schreiben würden und das für jedes OS was auf x86 genutzt wird. Irre

Bei der... Entwicklungsdichte also von Hardware und IDE bei Apple ist die Leistung für mich überhaupt nicht beeindruckend gewesen (M1). Im ersten Schritt war das für mich eher der Energieverbrauch dabei. Das ist eher der Punkt. Mit Leistung nachzulegen (M2) ist dann aber auch nicht mehr so einfach
Bei denen skaliert die Software nicht anders als auf x86 und gleich jede Routine über die GPU-Kerne zu streamen geht genausowenig. Das nimmt auch relativ schnell wieder sein Ende. Nicht alles ist DaVinci Resolve.