Dlaczego emulacja procesora jest powolna [zamknięta]


3

Różne operacje CPU (IA-32, ARM9 itp.) Powinny być równoważne w swojej naturze (przenoszenie, odczyt, zapis danych itp.). Różne procesory nie powinny być tak bolesne dla siebie nawzajem. Ale wydaje się, że nie jest to takie łatwe, ponieważ emulowane oprogramowanie działa zbyt wolno. Czy możemy po prostu przekonwertować plik wykonywalny, a następnie go wykonać? Dlaczego i tak jest tak zależny od zasobów (dlaczego potrzebuję potężnego procesora, aby emulować inny procesor)? Muszę powiedzieć, że nie mam dużych umiejętności programowania na niskim poziomie. Wielkie dzięki.

Odpowiedzi:


4

Po pierwsze, chociaż z pewnością istnieją instrukcje bardzo podobne, nie jest tak, że istnieje zestaw instrukcji, które zawsze zachowują się w ten sam sposób na różnych architekturach procesora. Do dokładnej emulacji (zwykle) nie wystarczy przetłumaczyć każdą instrukcję - musisz obsługiwać dostęp do pamięci, czas, przerwania ... i to tylko dla procesora.

Wydaje się, że to, o czym myślisz, to rekompilacja statyczna, ale jest to bardzo trudne (w rzeczywistości myślę, że sprowadza się to do problemu zatrzymania , co w praktyce czyni go niemożliwym). W praktyce czasami możemy to zrobić dla podzbioru programów, ale nie można napisać kompilatora ogólnego przeznaczenia, który pobiera kod obiektu dla jednej architektury jako dane wejściowe i generuje doskonale równoważny kod dla innego. Na przykład trudno byłoby obsłużyć kod samomodyfikujący przy użyciu tej metody.

Rekompilacja dynamiczna (która generuje kod w locie podczas wykonywania programu) jest bardziej skuteczna (nadal nie jest trywialna, aby zrobić dobrze). Konkretne problemy będą jednak zależeć od architektury. W wielu przypadkach emulacja procesora nie jest problemem, ale emulowanie różnych urządzeń peryferyjnych przy zachowaniu dokładnego taktowania jest (patrz np . Artykuł byuu na temat emulacji SNES ).

Czasami możesz zignorować wiele z tych ograniczeń i nadal emulować sprzęt wystarczająco dobrze, aby uruchomić podzestaw oprogramowania, ale o ile wiem, nigdy nie jest możliwe, aby mieć 100% dokładności przy zerowym obciążeniu, chyba że masz rzeczywisty sprzęt.


czym różni się rekompilacja statyczna od dynamicznej, skoro kod i tak zostanie ponownie skompilowany (przekonwertowany)?
user2543574

Różnica polega na tym, że dynamiczna rekompilacja zachodzi w trakcie działania kodu, dzięki czemu można poznać stan systemu w dowolnym momencie. To pozwala ci tłumaczyć kod w różny sposób w zależności od aktualnych warunków, co jest niemożliwe przy statycznym rekompilatorze.
user55325

5

Różne operacje CPU (IA-32, ARM9 itp.) Powinny być równoważne w swojej naturze (przenoszenie, odczyt, zapis danych itp.).

Powinny być, ale nie są. Architektura procesora realizuje te podstawowe operacje zgodnie z przewidywaniami projektantów - i może się to bardzo różnić w zależności od tego, co próbują osiągnąć projektanci. Rzeczy, które można wykonać w jednej instrukcji na niektórych procesorach, mogą wymagać wielu, wielu instrukcji na innych.

Czy możemy po prostu przekonwertować plik wykonywalny, a następnie go wykonać? Dlaczego i tak jest tak zależny od zasobów (dlaczego potrzebuję potężnego procesora, aby emulować inny procesor)?

Jeśli wszystko, co chcesz zrobić, to emulować procesor, możesz to zrobić i zrobić stosunkowo łatwo. „Konwertowanie” pliku wykonywalnego w locie nazywa się „rekomplikacją dynamiczną” i wiele emulatorów już to robi. Zazwyczaj jednak chce się emulować całą platformę. Obejmuje to sprzęt inny niż procesor, a czasami ten sprzęt jest trudny do emulacji (na przykład Atari 2600 TIA) lub słabo udokumentowany (sprzęt wideo NES PPU lub nawet obecny sprzęt GPU) lub jedno i drugie. Procesory zawsze działają w kontekście platformy i zwykle oprogramowanie oczekuje, że platforma CPU + będzie działać razem w określony sposób. Wymagania dotyczące emulacji platformy i wykonywania jej przy często wymaganych rygorystycznych wymaganiach czasowych to część trudna i zasobochłonna.


Tak. Gdyby nie ten drobny szczegół urządzeń peryferyjnych wokół procesora, na przykład nie byłby potrzebny cały wysiłek, aby przebudować system IBM ROM BIOS; po prostu uderz w gotową płytę 8086 na płycie głównej, a będziesz mieć klona IBM PC gotowego uderzyć w półki. Oczywiście w praktyce nie było to takie łatwe. To samo dotyczy tutaj, choć na większą skalę niż układ 8 KiB ROM z opublikowanym, opatrzonym komentarzem i komentarzem kodem źródłowym.
CVn

@ MichaelKjörling, dlaczego nie możemy myśleć w kategorii czarnych skrzynek, skoro mamy dane wejściowe i zadania do wykonania? dane wejściowe powinny być wystarczająco łatwe do konwersji. dlaczego to nie jest
user2543574

@ user2543574 Ponieważ dokładnie, jak wskazuje ultrasawblade, istnieje o wiele więcej użytecznej emulacji platformy niż zwykłe tłumaczenie kodów binarnych procesora z jednego procesora na drugi. Pisanie użytecznego (choć być może niezbyt przydatnego) emulatora Altair 8800 bez kości jest dość łatwe, ponieważ tak naprawdę był to niewiele więcej niż procesor 8080, kilka fizycznych we / wy (światła i przełączniki), płyta RAM i Magistrala S-100 łącząca urządzenia peryferyjne z procesorem. Napisanie przydatnego emulatora NES to zupełnie inne przedsięwzięcie, mimo że procesor 6502 jest na podobnym poziomie co 8080.
CVn
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.