Post by Thomas PrieglWarum sollte der Code doppelt übersetzt werden müssen?
Stimmt, ist irgendwie Blödsinn, aber ich versuche gedanklich dem Problem
der Synchronisation der beiden emulierten CPUs aus dem Weg zu gehen.
Aber meiner Ansicht nach lassen sich mehrere emulierte CPUs eben nur
ansprechend synchronisieren, wenn sie im gleichen Thread emuliert
werden. Ich kann mich natürlich auch täuschen...
Wenn die Emulation von einem Dual-Prozessor, insbesondere mit
dynamischer Recompilierung, halbwegs einfach wäre, dann gäbe es meiner
Ansicht nach deutlich mehr Sega-Saturn-Emulatoren. Der SH-2 ist
eigentlich vergleichsweise trivial, aber die Tatsache, daß der Saturn
gleich zwei davon hat, macht die Emulation der Hardware deutlich
aufwendiger.
Post by Thomas PrieglEine JVM kann auch beliebig viele Threads parallel ausführen
Der Unterschied bei Java ist aber, daß Du nicht mehrere VMs hast,
sondern Threading durch die Thread-Klasse und nötige Synchronisation im
Bytecode durch monitorenter und monitorexit gesteuert werden.
Das ist etwas komplett anderes, als zwei reele Prozessoren in
unterschiedlichen Threads mit dynamischer Recompilierung zu emulieren
und dann noch zu versuchen, beide so zu synchronisieren, daß sich das
ganze dann wie ein SMP-System verhält.
Eine andere Idee von Dir war ja, die Windows-Threads quasi in
Emulations-Threads zu übertragen, aber dadurch würde der Emulator so
stark auf Windows (und wahrscheinlich nur XP, da es bei jeder Version
etwas anders sein dürfte) angepaßt, daß es kein PC-Emulator wäre.
In dem Fall wäre es dann besser, nur die CPU-Emulation zu nehmen, mit
einem PE-Loader zu kombinieren und die Win-API auf OSX zu portieren. Da
hätte außerdem den Nebeneffekt, daß man sich bis auf die CPU die
Hardwareemulation spart und die API nativ läuft. Und so ein Projekt ist
schließlich in Arbeit:
<http://darwine.opendarwin.org/>
Post by Thomas PrieglBTW: Übersetzt VPC alles im voraus in nativen G4/G5 Code (analog eines
Java Just in Time Compilers)
Nein, das wäre definitiv zu langsam und würde zu noch längeren
Wartezeiten beim Start eines Programms führen, als das bei einem Java
JIT-Compiler der Fall war. Mal abgesehen davon, daß man bei einem echten
Maschinenprogramm nicht immer eindeutig entscheiden kann, was jetzt
wirklich alles Code ist.
Wie die meisten Emulatoren mit dynamischer Recompilierung arbeitet VPC
mit sog. Basisblöcken ("basic blocks"). Dieser aus der
Compileroptimierung bekannte Terminus bezeichnet eine Folge von
Instruktionen, die immer sequenziell ausgeführt wird, oder anders
ausgedrückt, ein Basisblock reicht von einem Einsprungpunkt bis zur
nächsten Verzweigung.
Sobald eine Adresse angesprungen werden soll, für die noch keine
Entsprechung im Translation-Cache vorliegt, wird der Basisblock ab
dieser Adresse übersetzt, die Übersetzung in den Cache gehängt und
danach angesprungen.
Dazu noch ein kleiner Artikel des Entwicklers:
<http://www.byte.com/art/9711/sec4/art4.htm>
Post by Thomas Priegloder macht VPC auch eine Analyse wie
Hotspot, übersetzt erst nach n durchläufen und interpretiert vorher?
Pauschal fällt mir nur ein in der Praxis eingesetzter
Binärcode-Übersetzer ein, der vorher einen Durchlauf mit Interpreter und
Profiler machte. Die Rede ist von FX!32, dem x86-Emulator für
WinNT/Alpha, der allerdings keine dynamische sondern eine statische
Übersetzung macht, die erst nach der Laufzeit erzeugt wird und dann für
den nächsten Durchlauf in einer Datenbank gespeichert wird.
Nach meinen Informationen sind die Profile-Informationen, die während
der Interpretation gesammelt werden, auch nicht gerade berauschend.
Primär geht es dabei um drei Dinge:
* Registrierung von Spungzielen, um eben Basisblöcke ausmachen zu können
* Markierung von nicht ausgerichteten Speicherzugriffen, da
"misalignment" auf dem Alpha einer Sonderbehandlung bedarf
* Markierung von indirekten Sprüngen, da diese eines der Hauptprobleme
der statischen Übersetzung darstellen; falls die gefundenen möglichen
Sprungziele zur Laufzeit nicht zutreffen sollten, muß sowieso wieder der
Fallback-Interpreter ran
HotSpot hat bei Java aus meiner Sicht primär einen Vorteil:
Initialisierungscode, der ohnehin nur einmal ausgeführt wird, muß nicht
übersetzt werden, was sich insbesondere auf die Startgeschwindigkeit
einer Applikation günstig auswirken dürfte.
Ansonsten sehe ich HotSpot vielmehr als Reperatur einer schlechten
JVM-Definition! Warum?
Nun, der Java-Bytecode wird vom Java-Compiler generiert, der natürlich
genau weiß, wo sich die Basisblöcke befinden, nur dummerweise wird der
Anfang eines Basisblocks im Bytecode nicht markiert. Eine der
Hauptaufgaben des Profilings in HotSpot dürfte es also sein, ähnlich wie
in FX!32, zur Laufzeit die Basisblöcke wiederzufinden, die zur
Compilezeit bereits bekannt waren.
Aber auch ansonsten hat ja Sun einiges für die Laufzeit aufgehoben, was
man besser zur Compilezeit erledigen sollte, wie die Registerallokation,
nachdem die JVM eine Stackmaschine ist...
Ich denke mal mit etwas besserem Design der JVM wäre so etwas wie
HotSpot einfach nicht nötig.
Post by Thomas PrieglHm ... ein Emulator übersetzt x86 Maschinencode in G4/G5 Maschinencode.
Eine JVM übersetzt Java Bytecode in x86 bzw. G4/G5 Maschinencode. Ich
kenne mich da wirklich nicht gut aus, aber wo ist der große Unterschied?
Genauso gut könntest Du fragen, was der Unterschied zwischen einem
Spaziergang und einem Marathonlauf ist...
Mal ein paar Unterschiede wahllos herausgegriffen:
* Bei Java hat man modularen Ausgangscode in Form von Klassen-Dateinen
und Methoden. Bei dynamischer Recompilierung bekommt man einfach einen
Batzen Maschinencode, bei dem je nach Objektformat noch nicht einmal
klar gegliedert sein muß, was davon Code oder Daten sind. Mal abgesehen
davon, daß ja zur Laufzeit auch problemlos weiterer Maschinencode
erzeugt werden kann.
* Selbstmodifizierender Code ist bei der JVM kein Thema, bei dynamischer
Recompilierung *das* Problem schlechthin, insbesondere wenn man es mit
der IA-32 zu tun hat, bei der aus Kompatibilitätsgründen ein Cache-Flush
vollkommen transparent sein muß und deswegen dem Emulator in keinster
Weise (z.B. durch eine spezielle Instruktion) mitgeteilt wird.
* Die JVM ist eine abstrakte Laufzeitumgebung ohne Seiteneffekte, bei
einem Emulator muß man die Emulation der CPU und der restlichen Hardware
richtig synchronisieren und darf sich noch mit einigen Seiteneffekten
herumschlagen (allseits beliebt sind schlecht dokumentierte
Condition-Flags).
Ich schätze mal, ich könnte noch mehr in die Tiefe gehen, aber das
sollte erstmal reichen...
Post by Thomas PrieglJein. Ich würde sagen, er sollte n Applikationen parallel so schnell wie
möglich ablaufen lassen. Ich arbeite extrem selten nur mit einer
Applikation.
Hmm, wenn Du Dich genötigt fühlst, auf einem PC-Emulator unter Windows
mehrere Applikationen gleichzeitig zu benutzen, dann würde ich mich an
Deiner Stelle fragen, ob ich nicht auf dem falschen System arbeite.
Für mich ist Emulation zum einen eine Form der Nostalgie und zum anderen
die Möglichkeit, einige wenige Applikationen, für die es auf meinem
aktuellen Primärsystem keine Entsprechung gibt, weiterzunutzen.
[VM-Extensions]
Post by Thomas PrieglJa. So ist es auch unter XP. Aber ich habe gelesen, dass in VPC 7 eben
dies für Win 98 nicht mehr unterstützt werden soll.
Und nochmal, "unsupported" heißt nicht unbedingt "geht nicht mehr".
Probier es einfach aus, bei mir klappt es.
Post by Thomas PrieglSchade. Gerade die unglaubliche Performance von BeOS hat mich damals
begeistert.
Stimmt schon. Ich hatte mal ein längeres Streitgespräch mit einem in der
BeOS-Newsgroups, weil er BeOS unbedingt in Bochs testen wollte (weil er
sich außer stande sah, sein Linux mal für ein paar Minuten
herunterzufahren) und mir nicht glauben wollte, daß er die Vorteile des
Systems so definitiv nicht einschätzen kann.
Post by Thomas PrieglSonst konnte man damit ja nicht soviel machen. ;-)
Ich habe es eigentlich noch einige Jahre nach der Einstellung der
Weiterentwicklung weiterverwenden können. Erst als immer mehr Webseiten,
die ich leider brauchte, mit den vorhandenen Browsern nicht mehr
funktionierten, faßte ich den Entschluß auf ein anderes System
umzusteigen. Nachdem mein PC dann auch schon veraltet war und einige
kleine Macken bekommen hatte, habe ich es dann gleich mit einem Wechsel
der Hardware verbunden.
--
M.I.K.e