Was genau soll eigentlich 3dNOW!?

[huha]

Morgen!

Kann mir mal bitte jemand erklären, was 3dNOW von AMD eigentlich bringt/bringen soll, wie es funktioniert und ob es heute noch einen Einfluß hat?
Ich hab schon über so ziemlich jede Technologie was gelesen, außer über 3dNow...

-huha

[Bokill]

Schon mal was von SSE/SSE2 gehört oder Altivec?
Das sind alles Vektor/Matritzenrecheneinheiten für Fliesskommaberechnungen mit reduzierter Genauigkeit.

AMD war dort sogar der Pionier. Mit diesem Instruktionsseitenwagen können zugleich mehrere Berechnungen stattfinden.

Sehr guter Artikel:
SSE Technology in New Intel Prescott Processors
http://www.xbitlabs.com/articles/cpu/display/prescott-sse.html

[huha]

SSE kann ich ja und darüber gibt's auch tonnenweise Informationen - nur was soll dann das 3dNOW! als "Gegenkonzept"? Da bin ich mir leider noch nciht wirjlich im Klaren darüber...

-huha

[Exxtreme]

Original geschrieben von huha
SSE kann ich ja und darüber gibt's auch tonnenweise Informationen - nur was soll dann das 3dNOW! als "Gegenkonzept"? Da bin ich mir leider noch nciht wirjlich im Klaren darüber...

-huha
Eigentlich ist SSE das Gegenkonzept zu 3DNow!. AFAIR ist der Unterschied zw. SSE und 3DNow!, daß SSE eigene Register dafür nutzt und 3DNow! die Gleitkomma-Register dafür nutzt.

[zeckensack]

3DNow ist wesentlich angenehmer zu hanhaben und sogar flexibler, es wäre mir eigentlich lieber gewesen wenn Intel SSE eingestampft hätte :weg:

[GloomY]

Original geschrieben von Exxtreme
Eigentlich ist SSE das Gegenkonzept zu 3DNow!. AFAIR ist der Unterschied zw. SSE und 3DNow!, daß SSE eigene Register dafür nutzt und 3DNow! die Gleitkomma-Register dafür nutzt. Die SSE Register sind zudem noch 128 Bit breit. Das ermöglicht einen doppelt so hohen theoretischen Grad an Parallelverarbeitung.

Dafür ist 3DNow! (mit Ausrufezeichen) flexibler gegenüber SSE, was Operationen zwischen den einzlnen SIMD Registern angeht. Ich kann da den von Bokill angesprochenen Artikel (http://www.xbitlabs.com/articles/cpu/display/prescott-sse_5.html) nur weiterempfehlen. :)

[zeckensack]

Original geschrieben von GloomY
Die SSE Register sind zudem noch 128 Bit breit. Das ermöglicht einen doppelt so hohen theoretischen Grad an Parallelverarbeitung.... selbst wenn es bei der Theorie bleibt (P3), erreicht man immerhin Quasi-Codekompression, weil man die gleiche Arbeit mit weniger Befehlen ausführen kann.

Nur so als Ergänzung ;)

[BlackBirdSR]

Original geschrieben von huha
Morgen!

Kann mir mal bitte jemand erklären, was 3dNOW von AMD eigentlich bringt/bringen soll, wie es funktioniert und ob es heute noch einen Einfluß hat?
Ich hab schon über so ziemlich jede Technologie was gelesen, außer über 3dNow...

-huha
während sich die Anderen noch streiten und von Matratzen reden :bäh:

3dnow ist mit MMX oder SSE vergleichbar.
Im Prinzip addiert man nicht mehr nur 2 Zahlen miteinander und erhält 1 Ergebnis, sondern hat einen Vektor aus z.B 2 Elementen den man vielleicht mit einem anderen Vektor addiert.
Man kann hier also mit einem Addierbefehl gleich 2 Ergebnisse bekommen. Durch dieses Prinzip kann man theoretisch Einiges an Performance gewinnen.

Das Ganze nennt sich SIMD (Single Instruction Multiple Data).
für unsere x86 CPUs gab es sowas zuerst mit dem Pentium MMX, in Form eben dieses MMX.
Leider konnte man mit MMX nur ganzahlige Operationen durchführen. Das war besonders blöd weil Spiele gerade beim Umsteigen auf Fließkommeberechnungen waren.

AMDs K6 hatten Probleme mit der FPU, aber bei AMD sah man einen Ausweg. 3Dnow! sollte das gleiche Prinzip wie MMX nutzen, aber für Fließkommewerte funktionieren. Nutzt man 3Dnow!, kann man die Fließkommaperformance des K6 immens steigern.
Intel bastelt derweil an MMX2 -> SSE. Aber ich würde nicht sagen dass es eine direkte Antwort auf 3Dnow! war, sondern eine logische Evolution von MMX.

Warum ist 3Dnow! jetzt nicht so der Renner? (oder SSE ;D ).
Für SIMD braucht man Vektorcode. Dieser lässt sich entweder per Hand schreiben, oder man vertraut auf einen Compiler. Die Hand ist faul, der Compiler blöde.
Und so hat sich SIMD nie so recht durchgesetzt. Es gibt hier und da ein paar Ansätze, aber es wird nicht voll ausgereizt.
Da SSE einige vermeintliche Vorteile beitet, und SIMD es so schon schwer hatte, ist 3Dnow! ins Hintertreffen geraten.
Das ändert nichts daran, dass 3Dnow! eigentlich sehr schön ist, für User und K6/7 :)

Fazit: 3Dnow! sollte dem K6 und AMD aus der Fließkommapatsche helfen und auch bei Anwendungen und Spielen den K6 mit dem Pentium2 konkurrieren lassen.
Als der K7 das ganz alleine schaffte gab es eigentlich keinen großen Grund mehr jetzt unbedingt 3Dnow! für AMD CPUs zu nutzen.

[Gast]

Original geschrieben von zeckensack
... selbst wenn es bei der Theorie bleibt (P3), erreicht man immerhin Quasi-Codekompression, weil man die gleiche Arbeit mit weniger Befehlen ausführen kann.

Nur so als Ergänzung ;)

Neee, das ganz sicher nicht. MMX, SSE & Co-Code ist in der Regel länger als nicht-MMX-Code, da die MMX-Opcodes länger sind. Die Schleifengröße und die Anzahl der Befehle ist meistens gleich, nur werden halt pro Takt mehr Daten bearbeitet.

Gruß

Jörg

[Matti]

Kann der Opteron/Athlon64 überhaput noch 3dnow, oder wurde das wegen SSE2 abgeschafft??

[Endorphine]

Original geschrieben von zeckensack
3DNow ist wesentlich angenehmer zu hanhaben und sogar flexibler, es wäre mir eigentlich lieber gewesen wenn Intel SSE eingestampft hätte :weg: Ich glaube dir wäre es eigentlich lieber, wenn man _Intel_ einstampfen würde ;D

[JTHawK]

Original geschrieben von Matti
Kann der Opteron/Athlon64 überhaput noch 3dnow, oder wurde das wegen SSE2 abgeschafft?? The AMD Hammer processor microarchitecture features support for all 32-bit industry-standard architectural extensions supported by previous AMD processor generations, including Intel’s MMX™ and AMD’s 3DNow!™ Professional technology (combining Enhanced 3DNow! technology and SSE). In addition, it introduces support for all instructions necessary to be fully compatible with SSE2 technology.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/Hammer_architecture_WP_2.pdf

[GloomY]

Original geschrieben von zeckensack
... selbst wenn es bei der Theorie bleibt (P3), erreicht man immerhin Quasi-Codekompression, weil man die gleiche Arbeit mit weniger Befehlen ausführen kann.

Nur so als Ergänzung ;) Das verstehe ich jetzt nicht ganz. Kannst du das bitte nochmal ausführen?
Original geschrieben von BlackBirdSR
Fazit: 3Dnow! sollte dem K6 und AMD aus der Fließkommapatsche helfen und auch bei Anwendungen und Spielen den K6 mit dem Pentium2 konkurrieren lassen.
Als der K7 das ganz alleine schaffte gab es eigentlich keinen großen Grund mehr jetzt unbedingt 3Dnow! für AMD CPUs zu nutzen. Och doch, SIMD Berechnungen haben doch trotzdem noch Geschwindigkeitsvorteile gegenüber "normalen" Befehlen gerade weil sie ja mehrere Sachen pro Takt machen.

[Endorphine]

Original geschrieben von JTHawK
The AMD Hammer processor microarchitecture features support for all 32-bit industry-standard architectural extensions supported by previous AMD processor generations, including Intel’s MMX™ and AMD’s 3DNow!™ Professional technology (combining Enhanced 3DNow! technology and SSE). In addition, it introduces support for all instructions necessary to be fully compatible with SSE2 technology.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/Hammer_architecture_WP_2.pdf Es ist auch möglich, dass die 3DNow-Implementierung beim K8 nur noch langsamer Microcode ist und keine festverdrahtete Logik/Arithmetik.

[zeckensack]

Original geschrieben von Gast
Neee, das ganz sicher nicht. MMX, SSE & Co-Code ist in der Regel länger als nicht-MMX-Code, da die MMX-Opcodes länger sind. Die Schleifengröße und die Anzahl der Befehle ist meistens gleich, nur werden halt pro Takt mehr Daten bearbeitet.

Gruß

Jörg Das ist richtig, ich meinte das aber auch nicht im Vergleich zu skalaren Operationen, sondern zu 'kürzeren' SIMD-Ops. SSE und 3DNow sind zB auf AthlonXP CPUs von der Rechenleistung gleichwertig. SSE macht (wenn man die vierfache Parallelisierung nutzen kannn) aber dichteren Code, weil jeweils vier Operationen, statt nur zwei in einen Maschinenbefehl kodiert werden.
Original geschrieben von GloomY
Das verstehe ich jetzt nicht ganz. Kannst du das bitte nochmal ausführen?Ein einzelner SSE-Befehl führt ja bis zu 4 Operationen aus. Der P3 führt das ganze aber trotzdem in Zweierpaketen aus. Der mögliche Gewinn ggü einem hypothetischen, nur zweifach SIMD-igen SSE besteht hier in der Code-Dichte. Sowohl Decoder, als auch I-Cache werden entlastet.

Ich gehe davon aus daß im Gegenzug der Microcode-Sequencer belastet wird, typischer SSE-Code würde darunter aber kaum leiden (weil SSE-Code idR nicht mit komplexen Integer-Ops gemischt wird; der Sequencer dreht sowieso Däumchen).

[zeckensack]

Original geschrieben von Endorphine
Es ist auch möglich, dass die 3DNow-Implementierung beim K8 nur noch langsamer Microcode ist und keine festverdrahtete Logik/Arithmetik. Ich gehe eigentlich vom umgekehrten Fall aus (=> 3DNow ist nativ, SSE und SSE2 sind Microcode).

[BlackBirdSR]

Original geschrieben von zeckensack
Ich gehe eigentlich vom umgekehrten Fall aus (=> 3DNow ist nativ, SSE und SSE2 sind Microcode).

in den AMD Dokumenten steht irgendwo was davon, dass beim XP für SSE Microcode benuztz wird und der K8 die meisten SSE/SSE2 Befehle durch den schnellen Fastpath laufen.

[GloomY]

Original geschrieben von zeckensack
Ein einzelner SSE-Befehl führt ja bis zu 4 Operationen aus. Der P3 führt das ganze aber trotzdem in Zweierpaketen aus.Achso, das war mir nicht bekannt. Dann ist es natürlich klar.

btw: Warum gibt man dem P3 SSE mit der Möglichkeit 4 Berechnungen in einem Takt zu machen, wenn dann doch nur 2 Berechnungen pro Takt implementiert werden? Ist das beim AthlonXP auch so?
Original geschrieben von zeckensack
Der mögliche Gewinn ggü einem hypothetischen, nur zweifach SIMD-igen SSE besteht hier in der Code-Dichte. Sowohl Decoder, als auch I-Cache werden entlastet.Jep, klar :)
Original geschrieben von zeckensack
Ich gehe davon aus daß im Gegenzug der Microcode-Sequencer belastet wird, typischer SSE-Code würde darunter aber kaum leiden (weil SSE-Code idR nicht mit komplexen Integer-Ops gemischt wird; der Sequencer dreht sowieso Däumchen). Ahja. Gibt es eigentlich Informationen welche normalen Befehle (abgesehen von den ganzen SIMD Befehlen) denn aus dem Microcode geholt werden müssen und welche fest verdrahtet sind?

[Mr. Lolman]

Zur möglichen Leistung von 3DNow!:

System1:
PII/416MHZ (83MHz FSB,)
128MB SDRAM (@83MHz)
Intel 440BX, Mobo
3dfx Voodoo Banshee 16MB SDRAM (100/110MHz)

System2:
AMD K6/II 300MHz (66MH FSB)
128MB SDRAM (@66MHz)
unbekanntes Mobo
3dfx Voodoo Banshee 16MB SDRAM (100/110MHz)

Testsoftware:
Unreal, flyby


Die genauen fps Zahlen hab ich nicht mehr im Kopf, aber Tatsache ist, dass das AMD System, trotz auf dem Papier deutlich unterlegener Leistung in 800x600 um ca. 2fps schneller als das Intel System war (27fps vs. 25fps) und das trotz deutlich schlechterer FPU Leistung und ~30% geringerer CPU,FSB,RAM Taktrate.

Bei anderer Software war der AMD Rechner tw. sogar 50% langsamer.

[zeckensack]

Original geschrieben von Endorphine
Ich glaube dir wäre es eigentlich lieber, wenn man _Intel_ einstampfen würde ;D *hrhr* :kicher:

Nein, eigentlich nicht. Eine Zeitlang war Intel (IMO) tatsächlich die beste Prozessordesignschmiede der Welt. Der P3 ist wirklich eine saugute Architektur. Banias macht auch einen sehr überzeugenden Eindruck. Ich gehe mal davon aus, daß sie immer noch genug talentierte Leute haben ... nur manchmal überschattet Intel's geradezu dogmatische Sturheit leider dieses Design-Talent.

Was ich an Intel also nicht mag, sind die politisch motivierten Entscheidungen (IA64 ist und bleibt IMO eine Schnapsidee, sorry), wozu letztlich auch die Arbeit unter Konkurrenzdruck gehört (Willamette als Reaktion auf Thunderbird; das Design war so IMO einfach noch nicht marktreif).

Um jetzt den Bogen aufs Thema zurück zu bekommen: die Pentium 4-Linie ist im Grunde in einer ähnlichen Situation wie seinerzeit der K6 mit seiner mittlerweile legendären FP-Schwäche. Anstatt einer ausbalancierten Architektur, die alles recht gut macht, muß man sich auf spezielle ISA-Erweiterungen zurückziehen, um überhaupt brauchbare Performance zu bekommen. Dann steigt die FP-Leistung plötzlich von 'beschämend' auf 'überragend'. Die Balance fehlt.

Daß Intel es eigentlich auch 'besser' kann, beweist der P6. Die FP-Leistung des Pentium 3 ist auch ohne SSE konkurrenzfähig.

Eine weitere interessante Parallele gibt es beim 'Update' der Architektur. K6-2 => K6-3 verbesserte den L2-Cache und brachte je nach Anwendung 10~15% Performance. Willamette => Northwood ist im Grunde exakt das gleiche. Die kleinen Architektur-Tweaks des Northwood hat der K6 bereits beim Schritt nach K6-2 erhalten.

Oder so gesagt (wenn man Software- und Hardware-Entwicklung zusammen betrachtet):
Der Schritt
a)K6 mit x87-Code => K6-3 mit 3DNow!-Code
entspricht in weiten Teilen
b)Willamette mit x86-Code => Northwood mit SSE2-Code

(eigentlich tue ich dem K6 mit diesem Vergleich sogar noch unrecht; dessen Integer-Leistung war zu seiner Zeit schlicht unschlagbar, er hatte so gesehen also eher weniger Schwachpunkte als der Willamette).

[zeckensack]

Original geschrieben von BlackBirdSR
in den AMD Dokumenten steht irgendwo was davon, dass beim XP für SSE Microcode benuztz wird und der K8 die meisten SSE/SSE2 Befehle durch den schnellen Fastpath laufen. Na dann, umso besser :)
Ich muß zugeben daß ich die K8-Dokumente noch nicht so gut auswendig kann, wie die K7-Gegenstücke ;)

[zeckensack]

Original geschrieben von GloomY
Achso, das war mir nicht bekannt. Dann ist es natürlich klar.

btw: Warum gibt man dem P3 SSE mit der Möglichkeit 4 Berechnungen in einem Takt zu machen, wenn dann doch nur 2 Berechnungen pro Takt implementiert werden? Ist das beim AthlonXP auch so?Da könnte ich jetzt mein Lieblingsargument für Shader-Hochsprachen ins Feld führen:
Man lässt sich Freiraum, um die Implementierung später noch verbessern zu können, und diese Verbesserungen ohne Software-Änderungen auch sofort nutzen zu können :)

2fach SSE ist erstmal ein sehr natürlicher Schritt von einer klassischen x87-FPU aus. Die rechnet sowieso schon mit 80bittigen Operanden, die dafür vorhandene Hardware kann dann relativ leicht (ohne 'verbreiterte' Datenpfade) so umgerüstet werden, daß sie wahlweise auch zwei 32bittige Operationen beherrscht. Spart halt massiv Transistoren, wenn man nicht für beide Anwendungsfälle seperate Funktionseinheiten braucht :)
Ich denke mal daß das Intel's Motivation war.

SSE-Arithmetik (insbesondere ADDPS, MULPS, SUBPS) ist auf AthlonXPs auch 'vector path' (=Microcode) und halbiert ggü 3DNow den Durchsatz. Was ich daraus schließe, sollte offensichtlich sein :)

Ahja. Gibt es eigentlich Informationen welche normalen Befehle (abgesehen von den ganzen SIMD Befehlen) denn aus dem Microcode geholt werden müssen und welche fest verdrahtet sind? AMD Dokument # 22007 wird dich glücklich machen, insbesondere Appendix F ("Instruction Dispatch and Execution Resources/Timing").
Üpp (http://www.amd.com/products/cpg/athlon/techdocs/pdf/22007.pdf).

Intel ist leider nicht so freizügig mit dieser Art Information :(

[GloomY]

Original geschrieben von zeckensack
Da könnte ich jetzt mein Lieblingsargument für Shader-Hochsprachen ins Feld führen:
Man lässt sich Freiraum, um die Implementierung später noch verbessern zu können, und diese Verbesserungen ohne Software-Änderungen auch sofort nutzen zu können :)

2fach SSE ist erstmal ein sehr natürlicher Schritt von einer klassischen x87-FPU aus. Die rechnet sowieso schon mit 80bittigen Operanden, die dafür vorhandene Hardware kann dann relativ leicht (ohne 'verbreiterte' Datenpfade) so umgerüstet werden, daß sie wahlweise auch zwei 32bittige Operationen beherrscht. Spart halt massiv Transistoren, wenn man nicht für beide Anwendungsfälle seperate Funktionseinheiten braucht :)
Ich denke mal daß das Intel's Motivation war.Ok, jetzt kann ich es nachvollziehen.
Original geschrieben von zeckensack
SSE-Arithmetik (insbesondere ADDPS, MULPS, SUBPS) ist auf AthlonXPs auch 'vector path' (=Microcode) und halbiert ggü 3DNow den Durchsatz. Was ich daraus schließe, sollte offensichtlich sein :)Dass 3DNow! auf dem XP kein langsamer Microcode ist und dass der Athlon64 / Opteron bei SSE Code zulegen kann im Takt-zu-Takt Vergleich zum AthlonXP ?!
Original geschrieben von zeckensack
AMD Dokument # 22007 wird dich glücklich machen, insbesondere Appendix F ("Instruction Dispatch and Execution Resources/Timing").
Üpp (http://www.amd.com/products/cpg/athlon/techdocs/pdf/22007.pdf).

Intel ist leider nicht so freizügig mit dieser Art Information :( Danke, aber das ist ja fast erschlagend viel an Informationen ;)

[GloomY]

Original geschrieben von zeckensack
Um jetzt den Bogen aufs Thema zurück zu bekommen: die Pentium 4-Linie ist im Grunde in einer ähnlichen Situation wie seinerzeit der K6 mit seiner mittlerweile legendären FP-Schwäche. Anstatt einer ausbalancierten Architektur, die alles recht gut macht, muß man sich auf spezielle ISA-Erweiterungen zurückziehen, um überhaupt brauchbare Performance zu bekommen. Dann steigt die FP-Leistung plötzlich von 'beschämend' auf 'überragend'. Die Balance fehlt.Ja, sehe ich genauso. Ich habe manchmal das Gefühl, der P4 ist nur ein sehr schneller Medienprozessor (wie aus einem DVD-Player), aber keine für Allgemeinaufgaben geeignete CPU, die das Herzstück eines Computers bildet, der für prinzipiell alle möglichen Berechnungen gut geeignet sein sollte. Das Universalitätsprinzip ist hier einfach sehr stark eingeschränkt, wenn man sich die Performance anguckt.

Eine Hardwarearchitektur, die nur auf das nächste Release einer verbesserten Compilerversion oder die Optimierung des Programms X für diese Architektur wartet und nicht aus eigener Kraft heraus imstande ist, konkurrenzfähige Leistung zu bringen, halte ich nicht für sonderlich gut für den PC geeignet.

OT: Meine Meinung zu EPIC sollte hieraus auch klar hervorgehen ;)

[Mr. Lolman]

Original geschrieben von GloomY
Eine Hardwarearchitektur, die nur auf das nächste Release einer verbesserten Compilerversion oder die Optimierung des Programms X für diese Architektur wartet und nicht aus eigener Kraft heraus imstande ist, konkurrenzfähige Leistung zu bringen, halte ich nicht für sonderlich gut für den PC geeignet.


Das ist bei Nvidias FX Karten ähnlich. :weg:

[Demirug]

Original geschrieben von Mr. Lolman
Das ist bei Nvidias FX Karten ähnlich. :weg:

Ist bei jeder Grafikhardware so. Bei den 1.1-1.3 Shader hatten die Treiber zu dem Zeitpunkt als es relevant wurde aber die passenden Compiler schon eingebaut.

Bei den Shader >= 2.0 hatte ATI einfach das nötige Glück und den Vorteil das sie eben schneller waren.

[Demirug]

Original geschrieben von GloomY
Eine Hardwarearchitektur, die nur auf das nächste Release einer verbesserten Compilerversion oder die Optimierung des Programms X für diese Architektur wartet und nicht aus eigener Kraft heraus imstande ist, konkurrenzfähige Leistung zu bringen, halte ich nicht für sonderlich gut für den PC geeignet.

Das Zeitalter der gleichgeschalteten Hardwarearchitektur neigt sich sowieso dem Ende zu. In Zukunft wird man mehr auf JIT-Compiler setzen.

[PhoenixFG]

JIT-Compiler? Das heißt, der Code wird erst zur Programmlaufzeit übersetzt? Das dürfte doch das gleiche Prinzip sein, welches hinter Java steckt. Zwar absolut plattformunabhängig, aber leider auch recht langsam.

MfG

[Demirug]

Original geschrieben von PhoenixFG
JIT-Compiler? Das heißt, der Code wird erst zur Programmlaufzeit übersetzt? Das dürfte doch das gleiche Prinzip sein, welches hinter Java steckt. Zwar absolut plattformunabhängig, aber leider auch recht langsam.

MfG

Ja, ein JIT-Compiler übersetzt den Code erst bei Bedarf. So langsam ist das gar nicht. Ein guter JIT-Compiler ist duraus in der Lage es mit einem C-Compiler aufnehmen. JAVA hat inzwischen auch recht gute JIT-Compiler auch wenn JAVA es nicht gerade einfach macht einen gute JIT-Compiler zu schreiben. Der Bytecode von JAVA war ursprünglich dafür gedacht interpretiert zu werden.

[BlackBirdSR]

Intel macht soetwas ähnliches bald auch für ihre IA-64 CPUs.
Dort wird ein Softwarelayer den x86 Code in Laufzeit auf IA-64 umsetzen. Das soll auch gar nicht so langsam sein.

Aber Hersteller sagen Viel wenn der Tag lang ist ;)

[Demirug]

Original geschrieben von BlackBirdSR
Intel macht soetwas ähnliches bald auch für ihre IA-64 CPUs.
Dort wird ein Softwarelayer den x86 Code in Laufzeit auf IA-64 umsetzen. Das soll auch gar nicht so langsam sein.

Aber Hersteller sagen Viel wenn der Tag lang ist ;)

Das erinnert mich an "DIGITAL FX!32". Das war ein System (für Windows NT) um auf den Alpha Prozessoren x86 Code auszuführen.

Allgemein kann man aber sagen das es einfacher ist von Bytecode aus zu jitten als von einer Maschinensprache in eine andere zu übersetzten.

[BlackBirdSR]

Original geschrieben von Demirug
Das erinnert mich an "DIGITAL FX!32". Das war ein System (für Windows NT) um auf den Alpha Prozessoren x86 Code auszuführen.

Allgemein kann man aber sagen das es einfacher ist von Bytecode aus zu jitten als von einer Maschinensprache in eine andere zu übersetzten.

tja, wenn man bedenkt, dass Intel viele leute aus dem Alpha Team übernommen hat, wäre es kein Wunder wenn deren Erfahrung/Wissen zum EInsatz kommen würde.