Befehlssatzsimulator - Instruction set simulator

Ein Befehlssatz - Simulator (ISS) ist ein Simulationsmodell , codiert in der Regel in einer High-Level - Programmiersprache , die imitiert das Verhalten eines Großrechner oder Mikroprozessor durch Befehle „Lesen“ und interne Variablen , welche die Aufrechterhaltung des Prozessors darstellen Registern .

Die Anweisungssimulation ist eine Methodik, die aus einem von mehreren möglichen Gründen eingesetzt wird:

Zum Beispiel wurde die IBM 1401 auf der späteren IBM/360 durch die Verwendung von Microcode- Emulation simuliert .
  • Zur Überwachung und Ausführung der Maschinencode-Anweisungen (aber als Eingabestrom behandelt) auf derselben Hardware zu Test- und Debugging-Zwecken, zB mit Speicherschutz (der vor versehentlichem oder absichtlichem Pufferüberlauf schützt ).
  • Zur Verbesserung der Geschwindigkeitsleistung – im Vergleich zu einem langsameren zyklusgenauen Simulator – von Simulationen mit einem Prozessorkern, bei dem der Prozessor selbst nicht zu den verifizierten Elementen gehört; beim Design von Hardware-Beschreibungssprachen mit Verilog, wo Simulationen mit Tools wie ISS mithilfe von " PLI " (nicht zu verwechseln mit PL/1 , einer Programmiersprache ) schneller ausgeführt werden können .

Implementierung

Eine ISS wird oft mit einem Debugger (oder ist selbst) ausgestattet , damit ein Softwareingenieur / Programmierer das Programm debuggen kann, bevor er die Zielhardware erhält. GDB ist ein Debugger, der ISS einkompiliert hat. Es wird manchmal in simulierte Peripherieschaltungen wie Timer , Interrupts , serielle Ports , allgemeine I/O-Ports usw. integriert, um das Verhalten eines Mikrocontrollers nachzuahmen .

Die grundlegende Befehlssimulationstechnik ist unabhängig vom Zweck gleich: Führen Sie zuerst das Überwachungsprogramm aus und übergeben Sie den Namen des Zielprogramms als zusätzlichen Eingabeparameter.

Das Zielprogramm wird dann in den Speicher geladen, aber die Kontrolle wird nie an den Code übergeben. Stattdessen wird der Eintrittspunkt innerhalb des geladenen Programms berechnet und ein Pseudo- Programmstatuswort (PSW) an diese Stelle gesetzt. Ein Satz von Pseudoregistern wird auf den Wert gesetzt, der enthalten wäre, wenn dem Programm die Kontrolle direkt übertragen worden wäre.

Je nach Hardware und Betriebssystem kann es notwendig sein, einige davon so zu ändern, dass sie auf andere Pseudo-"Steuerblöcke" verweisen. Es kann auch erforderlich sein, die ursprüngliche Parameterliste zurückzusetzen, um den zuvor hinzugefügten Programmnamensparameter zu „entfernen“.

Danach läuft die Ausführung wie folgt ab:

  1. Bestimmen Sie die Länge der Anweisung an der Pseudo-PSW-Position (anfänglich die erste Anweisung im Zielprogramm). Wenn dieser Befehlsversatz innerhalb des Programms mit einem Satz zuvor angegebener "Pause"-Punkte übereinstimmt, stellen Sie den "Pause"-Grund ein, gehen Sie zu 7.
  2. "Abrufen" der Anweisung von ihrem ursprünglichen Speicherort (falls erforderlich) in den Speicher des Monitors. Wenn "Trace" verfügbar und "on" ist, speichern Sie den Programmnamen, den Befehlsoffset und alle anderen Werte.
  3. Führen Sie je nach Anweisungstyp Prüfungen vor der Ausführung durch und führen Sie sie aus. Wenn die Anweisung aus irgendeinem Grund nicht fortgesetzt werden kann (ungültige Anweisung, falscher Modus usw.), gehen Sie zu 7. Wenn die Anweisung den Speicher ändert, prüfen Sie, ob das Speicherziel existiert (für diesen Thread ) und ausreichend groß ist. Wenn OK, laden Sie geeignete Pseudoregister in temporäre Realregister, führen Sie eine äquivalente Bewegung mit den Realregistern durch, speichern Sie die Adresse und die Länge des geänderten Speichers, wenn der Trace "on" ist, und gehen Sie zu 4. Wenn der Befehl ein "Register-to-Register"-Befehl ist Operation, Pseudoregister in die realen Monitorregister laden, Operation ausführen, in die entsprechenden Pseudoregister zurückspeichern, weiter zu 4. Wenn der Befehl eine bedingte Verzweigung ist, bestimmen Sie, ob die Bedingung erfüllt ist: wenn nicht, gehe zu 4, wenn die Bedingung erfüllt ist, Berechnen Sie die Verzweigung zur Adresse, stellen Sie fest, ob sie gültig ist (wenn nicht, setzen Sie error = " Wild branch ") und gehen Sie zu 7. Wenn OK, gehen Sie zu 5. Wenn die Anweisung ein Betriebssystemaufruf ist, führen Sie einen echten Aufruf vom Überwachungsprogramm durch "Faking" durch Adressen, um die Steuerung an das Überwachungsprogramm zurückzugeben und dann Pseudoregister zurückzusetzen, um den Aufruf widerzuspiegeln; gehe zu 4.
  4. Addieren Sie die Befehlslänge zum aktuellen Pseudo-PSW-Wert.
  5. Speichern Sie die nächste Adresse in Pseudo-PSW.
  6. Gehe zu 1.
  7. Ausführung anhalten.

Für Test- und Debugging-Zwecke kann das Überwachungsprogramm Einrichtungen zum Anzeigen und Ändern von Registern, Speicher und Neustartort bereitstellen oder einen Mini- Core-Dump erhalten oder symbolische Programmnamen mit aktuellen Datenwerten drucken. Es könnte neue bedingte "Pause"-Positionen zulassen, unerwünschte Pausen entfernen und dergleichen.

Die Anweisungssimulation bietet die Möglichkeit, Fehler VOR der Ausführung zu erkennen, was bedeutet, dass die Bedingungen noch genau so sind, wie sie waren und nicht durch den Fehler zerstört werden. Ein sehr gutes Beispiel aus der IBM S/360- Welt ist die folgende Befehlssequenz, die beim Debuggen ohne Befehlssimulationsmonitor zu Schwierigkeiten führen kann. 

     LM    R14,R12,12(R13)   where r13 incorrectly points to string of X"00"s
     BR    R14              causes PSW to contain X"0000002" with program check "Operation Exception"
*                           all registers on error contain nulls.

Folgen

Gemeinkosten

Die Anzahl der Befehle zum Ausführen der obigen grundlegenden "Schleife" (Abrufen/Ausführen/Berechnen einer neuen Adresse) hängt von der Hardware ab, aber sie könnte auf IBM S/360 /370/390/ES9000-Maschinen in etwa 12 oder 13 Befehlen für viele Anweisungstypen. Das Prüfen auf gültige Speicherorte oder auf bedingte "Pause"s erhöht den Overhead beträchtlich, aber Optimierungstechniken können dies auf ein akzeptables Niveau reduzieren. Für Testzwecke ist dies normalerweise akzeptabel, da leistungsstarke Debugging-Funktionen bereitgestellt werden, einschließlich Anweisungsschritt , Trace und absichtlicher Sprung zur Testfehlerroutine (wenn kein tatsächlicher Fehler vorliegt). Darüber hinaus kann ein vollständiger Instruktions-Trace verwendet werden, um die tatsächliche (ausgeführte) Codeabdeckung zu testen .

Zusätzliche Vorteile

Gelegentlich kann die Überwachung der Ausführung eines Zielprogramms dabei helfen, zufällige Fehler hervorzuheben , die während der Überwachung, jedoch nicht in der realen Ausführung, auftreten (oder manchmal verschwinden). Dies kann passieren, wenn das Zielprogramm an einem anderen Ort als normal geladen wird, da sich das Überwachungsprogramm physisch im gleichen Adressraum befindet.

Wenn das Zielprogramm den Wert von einer "zufälligen" Stelle im Speicher abholt (eine, die es normalerweise nicht "besitzt"), kann es zum Beispiel in fast jeder normalen Situation Nullen (X"00") sein und das Programm funktioniert OK . Wenn das Überwachungsprogramm den Lastpunkt verschiebt, kann es beispielsweise X"FF" aufnehmen und die Logik würde während eines Vergleichsvorgangs zu anderen Ergebnissen führen. Wenn das Überwachungsprogramm jetzt den Platz belegt, von dem der Wert "abgeholt" wird, können alternativ ähnliche Ergebnisse auftreten.

Fehler beim Wiedereintritt: Die versehentliche Verwendung von statischen Variablen anstelle von "dynamischem" Thread-Speicher kann in vielen Situationen zu Problemen mit dem Wiedereintritt führen. Mit einem Überwachungsprogramm können diese auch ohne Speicherschutzschlüssel erkannt werden .

Unzulässige Operationen: Einige Betriebssysteme (oder Hardware) erfordern, dass sich das Anwendungsprogramm für bestimmte Aufrufe des Betriebssystems im richtigen "Modus" befindet. Die Befehlssimulation kann diese Bedingungen vor der Ausführung erkennen.

Hot-Spot-Analyse und Befehlsverwendung durch Zählen der während der Simulation ausgeführten Befehle (die der Anzahl der ausgeführten Befehle auf dem tatsächlichen Prozessor oder der nicht überwachten Ausführung entsprechen), kann der Simulator sowohl ein Maß für die relative Leistung zwischen verschiedenen Algorithmusversionen liefern als auch zur Erkennung verwendet werden "Hot Spots", an denen der Programmierer dann gezielt Optimierungen vornehmen kann. In dieser Rolle kann es als eine Form der Leistungsanalyse betrachtet werden, da es nicht einfach ist, diese Statistiken bei normaler Ausführung zu erhalten, und dies gilt insbesondere für Hochsprachenprogramme, die den Umfang von Maschinencodebefehlen aufgrund ihrer Natur effektiv "verbergen".

Bildungs ​​Gründe

Einige dieser Softwaresimulatoren werden noch als Werkzeuge für den Unterricht in Assemblersprache und Befehlssatzarchitektur verwendet, wobei einige speziell unter Verwendung mehrerer Simulationsschichten und ISA-zu-ISA-Simulation entwickelt wurden, mit der Fähigkeit, sogar ISAs zu entwerfen und zu simulieren.

Kritik

Im ersten Band von The Art of Computer Programming schrieb Donald Knuth : "Nach Meinung des Autors wurde viel zu viel Zeit für das Schreiben solcher [Maschinensprachen-] Simulatoren aufgewendet, und es wurde viel zu viel Computerzeit für deren Verwendung verschwendet ." Im folgenden Abschnitt gibt der Autor jedoch Beispiele dafür, wie solche Simulatoren als Trace- oder Monitorroutinen für Debugging-Zwecke nützlich sind.

Beispiel

Typische Trace-Ausgabe aus der Simulation durch ein Überwachungsprogramm, das für Test und Debugging verwendet wird: 

Program        offset         instruction            Dis-assembled             register/ storage (after execution)
TEST001        000000         X'05C0'                BALR   R12,0              R12=002CE00A
               000002         X'47F0C00E'            BC    15,X'00C'(R12)    
               00000E         X'98ECD00C'            STM   R14,R12,X'00C'(R13)   X'002E0008' ==> X'00004CE,002CE008,..etc....'
               000012         X'45E0C122'            BAL   R14,X'122'(R12)     R14=002C0016
SUB1           000124         X'50E0C28A'            ST    R14,X'28A'(R12)       X'002CE294' ==> X'002C0016'
etc...

Siehe auch

Simulatoren

  • ARMulator - CPU-Simulatoren für die ARM-Architektur , die von ARM selbst als Referenz- und Softwareentwicklungsfahrzeug bereitgestellt werden.
  • Computerarchitektursimulator
  • CPU Sim - Java-basiertes Programm, das es dem Benutzer ermöglicht, einen Befehlssatz zu entwerfen und zu erstellen und dann Programme mit Befehlen aus dem Satz durch Simulation auszuführen
  • Gpsim - PIC-Mikrocontroller- Simulator
  • INTERP/8 - Intel 8008 und INTERP/80 für Intel 8080.
  • Little Man Computer - einfaches Java-basiertes Beispiel für einen Befehlssatzsimulator
  • MikroSim - CPU-Simulator, der die Definition von Befehlssätzen auf Mikrocode-Ebene für Bildungszwecke ermöglicht
  • OVPsim - CPU- und Vollsystemsimulator , der über 170 befehlsgenaue Prozessormodelle bietet. Ermöglicht benutzerdefinierte Befehlssätze.
  • Simics - CPU- und vollständiges Systemsimulator-Framework, das vollständige Modelle komplexer moderner Hardware erstellt.
  • CPU-OS-Simulator - Integrierte RISC-CPU- und Multithreading-Betriebssystem-Lernsimulatoren.

Andere

Verweise

Externe Links

  • "Mikrocodesimulator MikroSim 2010" . 0/1-SimWare . Abgerufen 2010-12-06 .
  • "Simulation und Tracing auf Anweisungsebene"
  • Imperas bietet eine ISS für über 170 Prozessorvarianten für ARM, ARMv8, MIPS, MIPS64, PowerPC, RISC-V, ARC, Nios-II, MicroBlaze ISAs.