Hallo!

Ich habe mich gerade gefragt, warum Intel (AMD & Microsoft) nicht daran gearbeitet haben, die CISC zu RISC Umwandlung mal loszuwerden.

Erster Schritt: Man hätte doch z.B. damals bei WinXP anfangen können, dieses rein auf dem RISC-Kern einer x86 CPU laufen zu lassen und die Umwandlung von CISC zu RISC zu umgehen. Weiters alle neuen Developer-Tools und Compiler so auslegen, dass sie reine RISC-Programme erzeugen und dabei ebenfalls die Umwandlung umgehen. In den x86-CPUs von damals hätte diese Umwandlungseinheit natürlich drin sein müssen, um weiterhin Abwärtskompatibilität zu garantieren. Würde man also nur WinXP und neue Programme verwenden, könnte diese Umwandlungs-Einheit abgeschaltet werden und nur bei Bedarf (ältere Programme) aktiviert werden können. So hätte man, wenn man nur neue Programme nutzt, Strom sparen können.

Nächster Schritt: Nach ca. 5 Jahren, z.B. mit der Einführen der Core-Architektur hätte man die CISC zu RISC Umwandlung aus der CPU komplett weglassen können und die alten Programme dann on-the-fly mit einer Software wie Rosetta kompatibel machen können. Da es dann nur ältere Programme beträfe und die CPU-Leistungen und RAM-Ausstattung der damaligen weit überlegen ist, würden diese Programme dann auch weiterhin schnell und sauber laufen. (ähnlich wie jetzt die PPC-Apps auf Intel-Macs laut Transitive soll man nach der Umwandlung ca. 70-80% der Performance von nativem Code erreichen)

Microsoft könnte das zu Ihrem Vorteil nutzen und diesen Kompatibilitäts-Layer nur mit Windows Vista und Windows 7 bzw. neuer mitliefern. Somit müssten Nutzer von neueren CPUs dann auch ein neueres Windows nutzen, um alte Programme ausführen zu können. Wie ich MS aber kenne, hätten sie das aber vermutlich auf für WinXP angeboten, mit einem der Service-Packs z.B.

Wie auch immer, Apple hätte dadurch den Vorteil gehabt, dass die x86-CPUs nochmals ein Stückchen sparsamer wären, und für Mac OS X braucht es sowieso keine Abwärtskompatibilität zu alten CISC-x86 Programmen, die hätten ja jede x-beliebige CPU-Architektur nehmen können, dank Rosetta.

Für Intel wäre der Vorteil natürlich am größten, denn diese könnten reine RISC Atom CPUs bauen und somit eventuell mit ARM mithalten, was Performance pro Watt angeht. Ich bin zwar kein Experte, aber ich habe irgendwo mal gelesen, bei den ATOM CPUs soll diese CISC-RISC Konvertierung in etwa 2/3 der Transistoren ausmachen.
Bei normalen Desktop-CPUs wäre der Unterschied wohl zu vernachlässigen, bei normalen Laptops evt. ein wenig zu spüren, aber Netbooks, Tablets, etc. sollten ordentlich davon profitieren.
Abgesehen davon hätte man endlich diesen Steinzeitlichen Ballast endlich abgeworfen und x86-CPUs hätten die gleiche moderne Architektur, wie andere CPUs, man könnte mit dem gleichen Forschungsaufwand mehr rausholen.

Wie gesagt, ich bin kein Experte, was das angeht, bei weitem nicht. Aber mir würde es logisch vorkommen, so vorzugehen, wie ich das beschrieben habe.

An die Experten: Bitte klärt mich auf, warum man so etwas, oder etwas ähnliches mit der x86-Architektur nie passiert ist

Besten Dank im Voraus!

Früher war Windows eine reine x86 Software und gar nicht portabel. Erst mit Windows NT wurde das OS so erneuert (die Hauptarbeit machte DEC), daß ein Wechsel der CPU Architektur überhaupt in Frage kam. Windows NT erschien dann auch in Zusammenarbeit mit Partner auch für andere Architekturen: Alpha, MIPS und PowerPC. Allerdings konnte sich Windows auf den anderen Plattformen mangels Unterstützung nicht zuletzt von Microsoft nicht durchsetzen. Einzig einige Systeme für Raytracing auf Alpha Basis konnten verkauft werden. Der Bedarf an Systemen mit MIPS oder PowerPC CPU war gleich null. Was einerseits an schlechtem Port lag (die Microsoft Compiler waren z.B. für PowerPC extrem schlecht) andererseits am Preis der Systeme. Wer sich ein RISC System kaufte nutzte direkt das UNIX vom Hersteller der Systeme, daß war billiger als Windows auf dem gleichen Rechner und es gab reichlich Softwareauswahl dafür.

Es bleibt auch die Frage wohin hätte den Microsoft migrieren sollen? MS hat keinerlei Expertise CPUs zu entwerfen, sie hätten Intel vor den Kopf stoßen müssen und sich einen anderen Partner suchen müssen. Damals zu Zeiten von NT4 gab es noch folgende RISC Plattformen: Alpha, ARM, MIPS, PA RISC, PowerPC/POWER, SPARC.

Intel hatte sich zwischenzeitlich an IA64(Itanium) versucht, nach Meinung vieler nicht sonderlich erfolgreich. Mittlerweile gibt es für Itanium kein Windows mehr. Der einzig verbleibende Anbieter von IA64 Systemen ist HP mit HP-UX und OpenVMS. Intel hat in all den Jahren immer wieder sich an RISC Systemen (i860, i960, StrongARM, ...) versucht und ist mehr oder minder regelmäßig gescheitert. IMHO wäre Intel also auch keine gute Wahl für einen RISC Prozessor gewesen.

Angenommen MS wollte jetzt auf eine RISC Plattform wechseln, wen sollten sie da als Partner ins Boot holen? Mit ARM versucht es gerade Microsoft. Aber ARM kann bisher keine Desktop oder gar Server CPUs konstruieren. Das kann aktuell nur IBM (alle anderen Firmen sind nicht aktuell in der Lage in der Leistung mit den Intel x86-64 mitzuhalten, in Performance/Watt ist IBM ohnehin besser). IBM und Microsoft, war da nicht etwas?

Die beiden Firmen haben sich damals im Streit getrennt, dagegen ist das Jobsche Nachtreten beim Intel Switch eine kleine Randnotiz der Geschichte.

gfhfkgfhfk: Ich glaube, du verstehst mich da falsch. Es geht nicht um einen CPU-Wechsel weg von x86, sondern dass neuere Software (inklusive OS) nur noch den RISC-Kern der CPU hätte nutzen sollen, anstatt die ewig alte Umwandlungseinheit von CISC zum eigentlich RISC-Kern. Also VORBEI an der alten Technik, direkt in den Kern. Alte Software kann ja für eine Frist von ca. 5 Jahren weiterhin die x86-interne Umwandlung von CISC nach RISC nutzen (wenn man nur neue Software nutzt, liegt diese brach), aber alles was neu kommt (bzw. kam seit z.B. WinXP) dafür bestand doch keine Notwendigkeit. Warum den alten Ballast mitschleppen? Warum nicht daran vorbei programmieren bzw. kompilieren?

Microsoft hat sich beim Abschneiden alter Zöpfe schon immer schwer getan. Da ist Apple deutlich konsequenter. Allerdings hat es Apple hier auch um einiges leichter. Apple hat hauptsächlich Privatanwender oder kleinere Unternehmen als Kunschaft, diese sind leichter zum aktualisieren zu bewegen als große Firmen, Versicherungen und Banken. Hinzu kommt, dass bei Apple Usern der innere Zwang immer das neueste System am laufen zu haben um ein vielfacher größer ist als bei Windows Usern. Du wärst überrascht mit welchen Uraltsystemen manche Unternehmen noch arbeiten (vor allem Versicherungen). Bei Großen Unternehmen darf man nicht vergessen, dass viele davon mit eigenen Programmen arbeiten, auch diese müssten aktualisiert werden was Kosten verursacht, deshalb wird die Aktualisierung bis zum letzten Drücker hinausgeschoben. Das hat wiederum zur Folge, dass weniger neue Hardware gekauft wird.

Selbst bei Apple gibt es ja überall empörte User weil Apple Rosetta, und somit den Support für PowerPC Progamme, einstellt. Obwohl der Wechsel von PowerPC auf Intel bereits Jahre her ist gibt es immer noch Entwickler die es nicht geschafft haben ihre Programme als Universal, geschweige denn komplett Intel zu aktualisieren. Die Entwicklergemeinde für Microsoft ist natürlich um einiges größer.

Konsequent zu sein kann sich Microsoft nicht leisten.

Die haben es nicht "nicht geschafft" sondern einfach "nicht gemacht". Hätte ja Mühe bedeutet.

Richtig. Bzw. sie haben das aber immer als "Stärke" kommuniziert.

Das geht technisch nicht, da unter anderem Intel keine definierte RISC API für die x86 Cores hat. Wenn man diese einführen würde, dann braucht man aber die x86 Emulationsebene nicht mehr, denn die Geschichte zeigt, daß Softwareemulatoren immer effektiver waren. Beim Itanium hat HP sehr schnell bessere x86 Softwareemulatoren geschrieben, so daß effektiv niemand den Hardwareemulator in den Itaniums jemals genutzt hat. Zum Booten brauchte man den x86 Support in den Itaniums ohnehin nie, da die Itaniums von Anfang an nur EFI unterstützt haben, und somit alter x86 Code auf diesen ohnehin nicht booten konnte. Dazu kommt die Auswahl an OS auf Itanium: HP-UX, OpenVMS, Linux und mittlerweile abgekündigt Windows Server.

Auch hier sieht man das Problem an WIntel. Es ist eben nicht eine Firma sondern deren zwei.

HP hat bei HP-UX auch schon zweimal die CPU-Architektur gewechselt. Beim ersten mal von 68k zu PA-RISC und zuletzt von PA-RISC zu Itanium. Beim letzten Schritt wurde ein Softwareemulator mitgeliefert, so daß es genügend Zeit gibt zu migrieren. IBM hat bei den AS/400 ebenfalls die CPU Architektur ausgetauscht: von einer 48Bit Spezialarchitektur hin zu 64Bit PowerPCs. Da IBM ohnehin eine Art von Bytecode bei OS/400 verwendet fiel das nie auf.

SGI und SUN haben früher in den Workstations und Server 68k CPUs verwendet, bei denen gab es eine Zeitlang parallel beide Architekturen (68k und SPARC bzw. 68k und MIPS). OS Support gab es natürlich recht lange.

Das Problem an Apple ist nicht der Wechsel der CPU Architektur, sondern die harten Schnitte womit man von einem Tag auf den anderen keine Hardware mehr bekommt auf der bestimmte Software läuft. Support für alte OS Versionen ist ebenfalls von einem auf den anderen Tag nicht mehr erhältlich. So etwas kann sich nur eine Firma leisten, die schlußendlich ausschließlich private Endkunden hat. Apple behandelt die professionellen Kunden immer stiefmütterlicher.

Das ist absolut wahr und echt bedauerlich. So lange es nur Software-Emulation bzw. Umwandlung der Programme ist (wie bei Rosetta) kann man das ja so lange weiterführen, wie man möchte. Genauso unnötig war es, bei 10.5 PPC Classic wegzulassen, jetzt sind die verbleibenden PPC-Macs in 10.4 und 10.5 gespalten, was niemandem etwas bringt, und nicht notwendig gewesen wäre.
Komischerweise haben sie es ja bis inkl. 10.4.11 auf PPC auch geschafft, theoretisch endlos abwärtskompatibel zu sein. Natürlich läuft in der Praxis nicht mehr alles unter Classic, aber durchaus einige alte 68k-Programme auf nem G5.

Die Frage ist, warum gibt es diese API nicht? Man hätte damit über die Zeit den alten Ballast loswerden können und über eine Softwareemulation für ewige Zeiten weiterhin die alten Programme betreiben können.

Aber das ist doch gerade das Problem. Indem man ewig lange Altes unterstützt bewegen sich weder User noch Entwickler mit.
Microsoft hat´s doch vorgemacht. Windows ist voller Balast nur damit alte Software auch auf neueren Systemen funktioniert damit die vielen Unternehmen die Aktualisierung ihrer Software so lange wie möglich hinauszögern können.

Würde Apple nicht konsequent sein wären nach wie vor viele Programme nicht auf Intel umgestellt.
Harte Schnitte wie bei Apple sorgen dafür, dass Apple sehr schnell neue Technologien unter´s Volk bringt und auch die Entwickler, die meisten zumindest, die neuen Technologien nutzen.

Dabei dachte ich, du bist kein Fan von Emulatoren und dem ewigen unterstützen alter Technologien.

Naja, nicht so ganz. Von DOS auf Win NT/2000/XP gab es auch bei MS einen ziemlichen Einschnitt. Aber für solch alte Sachen gibt es schließlich Emulatoren, wie die DOSBox, die Betriebsystem-unabhängig sind.

Das kommt ganz darauf an, ob es technisch auch sinnvoll ist, bzw. ob es dafür technische Gründe gibt. Und in Sachen Hardware sollte man altes Zeug, wie diese CISC zu RISC Umwandlung bei x86 schon mal loswerden … btw: Da frage ich mich gerade, wie man das ganze überhaupt mit 64 bit vereinen konnte?! Wird für 64bit Programme auch noch diese Umwandlung benötigt?

Emulatoren sind doch eine nette Sache. Gerade erst kürzlich entdeckt, dass E-UAE jetzt vergleichbar gut, wie WinUAE läuft, und ich jetzt auch unter Mac OS X "Alien Breed 3D II" zocken kann, und dazu nicht extra Windows brauche.

Äh, die letzte E-UAE-Version ist mittlerweile über vier Jahre alt. Bist du sicher, dass du das meinst?

3-plus-1: Ja stimmt, ist alt, aber gut. Damit laufen auch CPU-intensive Sachen endlich super. War auf meinem iMac G5 nicht so zu schaffen. Max-UAE war ultralahm, E-UAE glaube ich etwas besser, einzig Mac-UAE unter Classic lief ziemlich flott, aber dafür auch sehr fehlerhaft.

Ganz Ehrlich: Bei der heutigen Software-Entwicklung mit all den architektonischen Schichten,, Frameworks, Layern und VMs, spielt es gar keine Rolle mehr, ob unten CISC, RISC oder sonstwas an Code dabei heraus kommt.