Emulator

Hi,

Wie kann ein Emulator es eigentlich ausnutzen, wenn die Ausführungsumgebung die gleiche Architektur ist, wie die Umgebung, die emuliert wird? Also ein normaler Emulator, der interpretiert und ned kompiliert. Was bringt das da? Er muss doch dann trotzdem instruktion für instruktion dekodieren und ausführen. er kann ja ned einfach den code ausführen.

Christoph

nobb2k schrieb:

er kann ja ned einfach den code ausführen.

Doch, genau das kann er in diesem Fall oft machen. Der Emulator muss nur sicherstellen, dass alle interrupts, syscalls, privilegierte Instruktionen u.ä. abgefangen und emuliert werden.

hi,
und wie kann er das machen? da muss er den code doch vorher durchgehen und diese ganzen instruktionen ändern

das schreit für mich nach hooks.

dafad schrieb:

das schreit für mich nach hooks.

und was sind hooks in diesem zusammenhang? wenn der prozessor die instruktionen nativ ausführt kann er ja ned einfach ne exception auslösen bei instruktionen, die sonderbehandlung brauchen wenn man das ganze vorher rekompiliert, versteh ichs ja, aber wie es ohne kompilieren geht, ist mir nach wie vor ned klar-..

rüdiger

nobb2k schrieb:

wenn der prozessor die instruktionen nativ ausführt kann er ja ned einfach ne exception auslösen bei instruktionen, die sonderbehandlung brauchen

Doch: SIGILL => Illegal Instruction

Aber das Problem wird ja oft eher sein entweder zusätzliche Software/Hardware zu emulieren. Bei Software sollte es eben relativ leicht sein, da man nur die entsprechenden Einsprungpunkte anbieten muss. So wie WINE das zB macht. Der Code wird nativ ausgeführt, nur die WinAPI-Aufrufe werden eben durch Aufrufe von nachgebauten WinAPI-Funktionen ersetzt. Aber im Grunde wäre das dann kein Emulator mehr (daher steht WINE auch für Wine Is Not an Emulator).

Bei zusätzlicher Hardware dürfte das ganze Unterfangen schwieriger werden.

dafad schrieb:

das schreit für mich nach hooks.

ich denke mal du willst auf API hooking raus?

api hooking hat damit doch nix zu tun. es kann nur so gehen wie ich es mir schon selber gedacht hab durch neukompilieren und das ist mir zu kompliziert. ich schreibe einen emulator und werde ihn entweder auf normal x86 schreiben oder auf der gleichen plattform, die ich emuliere. aber wenn ich das ned ausnutzen kann, kann ich ihn ja auch ganz normal schreiben als interpreter-

ghorst

neucompilieren wäre ein bisschen übertrieben. das ganze funktioniert am einfachsten über laufzeitanalysen und code-austausch auf maschienencodebasis. alle "gefährlichen" aufrufen werden herausgefiltert und durch passende einsprungsequenzen in deinen emulator ersetzt. das ist alles. (klingt einfach, ist aber furchtbar fies zu implementieren...)

naja das is ja neukompilieren

ghorst

lass uns streiten über worte: neucompiliere heißt eigentlich, dass man den quellcode nimmt und auf die neue architektur übersetzt. emulatoren machen genau das nicht.

wieso?`das is doch ne gängige technik die emulatoren anwenden, besonders wenn es neuere systeme sind, gehts doch kaum anders, wenn man halbwegs akzeptable performance haben möchte...

mad_martin

So, die Emulatoren nehmen also den Sourcecode und übersetzen den neu für die Zielplattform? Das glaube ich nicht, Tim

Der Maschinencode wird neuinterpretiert bzw. die Aufrufe umgebogen, wie oben schon gesagt. Aber neu kompiliert wird nüscht.

hustbaer

man kann neu compilieren auch anders verstehen. bei der java VM sagt man ja auch "JIT compiler" und nicht "JIT mondkalb" oder sonstwas. wüsste nicht wieso man einen maschinencode für CPU X nicht als sourcecode für einen compiler ansehen kann der daraus dann code für CPU Y macht.

müsste man dann z.B. aufhören C-compiler zu sagen wenn jmd. eine CPU bastelt die C-code direkt ausführt?

ghorst

wenn du einen prozessor hättest, der c direkt ausführen könnte, bräuchte man keinen compiler mehr. dann hätten wir endlich den c-assembler.

aber du hast recht: java-mondkalb und codemorphing, wie man es zwischen verschiedenen architekturen nutzt (siehe die dicken dinger von ibm und co), ist im prinzip das gleiche. aber ich verstand die frage des op so, dass es im explizit um emulatoren auf der gleichen architektur geht. hier haben die eigentlich mehr ähnlichkeit mit virtualisierung, da die emulatoren eben nicht versuchen zu verstehen, was der code macht, sondern "nur" die hardwareaufrufe ersetzen und sonst keinerlei codemorphing betreiben.

aber mal ehrlich: das ist ein recht akademische streit. man kann das sicher mit neukompilieren bezeichnen, finde ich halt nur irreführend.