Oder kurz gesagt: Die Leute bei Apple wissen was sie tun und haben alles richtig gemacht

"Rosetta 2 übersetzt ARM-Code in x86-Anweisungen".... Das ist doch falschrum.

winfel: Natürlich, danke für den Hinweis. Ist korrigiert.

Hmm... Rosetta 2 übersetzt x64/amd64 Code in Arm.
x86 Code ist 32 Bit und es wäre mir neu, dass Rosetta 2 32 Bit Apps zum Laufen bringt...

Nun, das hatte ich bei Einführung der M-Chips schon gesagt. Der Intel-Code wird komplett disassembliert und in LLVM-IR Code übersetzt. Das ist am Anfang gerade mit den Status-Flags bei Intel sehr häßlicher und ineffizienter Code. Aber mit LLVM lässt sich das meiste weg optimieren (zB Status-Flags die nicht geprüft werden). Am Ende wird das ganze mit dem LLVM-Backend zu ARM Code übersetzt.
Das ganze geht natürlich nicht ganz so einfach und daher werden für Sprünge teils Exceptions verwendet und der Code in kleinere Blöcke zerlegt und hin und wieder muss dann einige Umwege gehen.

Nun, wir haben das schon gemacht um x64-Code für einen anderen Prozessor zu übersetzen - waren da aber technisch eingeschränkt (kein Speicherzugriff). Zum Spaß hatten wir Code, der mit MSVC auf Windows übersetzt wurde wieder zu x64 zurück übersetzt - der war dann ca. 10% effizienter.

Es gab früher auch mal ein OpenSource-Projekt „libcpu“, das aber irgendwann vereinsamt ist. Damals konnte man schon 6502 Code eines Commodore Rechners in x86 übersetzen.

Auch wenn Apple keine 32-bit Mac Apps unterstützt, so scheint Rosetta 2 schon das ganze x86 Befehlsregister zu kennen. Das schließt wohl SSE2, x87 und 32-bit Befehle ein. Das ist schon ein bemerkenswertes Stück Software!

Das sorgt aber auch leider dafür, dass sich Softwarehersteller auf die faule Haut legen.
Als Beispiel zB die Desktop WhatsApp Version ist immer noch Intel.
Und ich würd mal vorsichtig behaupten die haben genug Ressourcen & Kapazitäten das mal umzustellen.

Der x64 Befehlssatz (genauer gesagt die amd64 Erweiterung zum x86 und danach EMT64 von Intel) ist ja nicht gänzlich anders. Man kann ohne Probleme x86-Code auf x64 ausführen.
DIe meisten Befehle haben bei x64 einfach ein Prefix-Byte mit dem den Units in der CPU mitgeteilt wird, statt 32 Bit eben 64 zu verwenden. Wenn Immidiates in dem Befehl stehen, dann weiß der Decoder auch, dass der Befehl um 4 Bytes länger wird.
Das war bei der Umstellung von 8 auf 16 und dann 32 Bits nicht wirklich anders - nur dass damals noch Bits im Befehls-Byte frei waren. Aber es gab auch zuvor schon Prefix-Bytes für einige Erweiterungen.

Den Decoder hat das nicht einfacher gemacht, damit auch die Branch-Prediction, Instruction-Reordering etc. Deswegen kommt Intel nur mit hohem Energieaufwand in der Performanz weiter.

(Bei RISC sehen die Probleme anders aus - am Ende ist RISC aber leichter skalierbar).

Intel hatte mal eine echte 64-Bit CPUs gebaut (Itanium) der nicht 100% kompatibel zu x86 war. Wollte keiner. Dort war die Bequemlichkeit der Softwarehersteller dann zu groß.

Wie machen das eigentlich andere Betriebssysteme? Wenn ein Linux aus einem PPC, X86 oder was auch immer Prozessor läuft müssen dann auch die Programme für jede Architektur vorliegen?

Japp. Die werden für jede Architektur eigens compiliert.

Das Hauptproblem von CISC-CPUs sind die viel zu komplexen Adressierungsmodi, die von den CPUs unterstützt werden. Der zweite Aspekt sind die unterschiedlich langen Befehle. Beides zusammen erschwert enorm die spekulative Ausführung von Code und versaut die Branch Prediction.

Als historisches Beispiel: Motorola/FreeScale/NXP hat die 68k Familie für embedded Anwendungen weiter entwickelt (ColdFire), und die Cores vereinfacht. Keine BCD-Befehle mehr, Adressierungsmodi vereinfacht und FPU auf 64Bit reduziert. Wenn man das berücksichtigt läuft sogar alter 68k Code auf ColdFire.

Intel hat bei SSE und AVX die Designrichtlinie von RISC angewandt. Das ist wie RISC eine klassische Load-Store-Architektur und die Befehlslängen sind harmonisiert. Deshalb sagt Intel auch immer, dass man keinen x87 Code mehr nutzen soll, sondern nur noch SSE bzw. AVX Code. Die erzielte Rechenleistung ist auch absolut konkurrenzfähig und die CPUs sind auch effizient im Sinne von Flops/Watt, wenn sie AVX Code abarbeiten.

ARM kann noch nicht mithalten, da bisher vor ARMv8 die SIMD-Einheiten von ARM eher für Multimedia gedacht waren, und erst mit ARMv8 wurde eine allgemein nutzbare SIMD-Einheit mit nur 128Bit Breite verbindlich integriert (Neon). Einzig für das Fujitsu SuperComputer Projekt wurde eine spezielle ARMv8 CPU (A64FX) entwickelt, die bereits über SVE verfügt. Mit der neuen Architektur ARMv9 wird dann für Desktop/Server-CPUs SVE2 verbindlich werden. SVE/SVE2 erlaubt maximal 2048Bit breite SIMD Einheiten, und zwar so, dass der Befehlssatz sich nicht ändert, wenn die physikalische Verarbeitungsbreite sich ändert. D.h. man braucht nicht so wie bei Intel/AMD die Programme neu zu übersetzen, wenn eine CPU mit breiterer SIMD-Einheit kommt. Die A64FX CPU nutzt 512Bit breite Register, und liegt damit auf dem Niveau der Intel AVX512 Implementation. Bei AMD wird aktuell nur AVX512 mit 256Bit Registerbreite bearbeitet.
Itanium war gar nicht zu x86 kompatibel, das ist eine komplett andere CPU Architektur. Es war ein sehr spezielle RISC-Design mit erheblichen Schwächen (VLIW), die nie behoben werden konnten. Intel war mit Itanium nur in einem Aspekt sehr erfolgreich, es hat einige der RISC-Konkurrenz eliminiert. Dem Itanium Projekt fielen HP-PA, MIPS, Alpha zum Opfer. Einzig IBM war so schlau darauf zu verzichten, dass eigene RISC-Projekt (POWER/PowerPC/Power) nicht vorschnell zu beerdigen.

Nur der allererste Itanium (Merced) hat einen Hardwareemulator für x86 Code enthalten. D.h. bei Merced waren zwei Cores verbaut ein IA-64 und ein IA-32, dazu war der x86 Core nicht sonderlich schnell. Der wichtigste Projektpartner – HP – benötigte einen Emulator für PA-RISC. HP hat einen so guten Emulator (eigentlich wie bei Apple ein Recompiler) für PA-RISC entwickelt, dass man das Konzept auch für x86 Code nutzte. D.h. der Recompiler erzeugte schnelleren Code auf Merced als die x86 Einheit in der CPU, somit war die x86 Hardware überflüssig. Ab dem Itanium 2 wurde daher auf die x86 Fähigkeit bei IA-64 komplett verzichtet.

HP bot lange Zeit sowohl Workstations als auch Server mit Itanium an. Allerdings stellte sich schnell heraus, dass die Kunden auf Itanium entweder HP-UX oder Linux nutzen. Der Bedarf an Windows NT war eher minimal, und nur für einige spezielle MS SQL Installationen wurde Windows auf Itanium genutzt. Hinzu kam, dass AMD die Erweiterung von x86 zu x86-64 vorstellte, und das bei der überragenden Mehrheit im Markt sehr viel besser ankam, als ein vermurkster RISC-Prozessor mit überhöhtem Preis.

gfhfkgfhfk
Wow - danke für den ausführlichen Einblick!