Kleine RISC emulator

Question

Ich bin auf der Suche zum erstellen einer VM in ein Spiel und Frage mich, ob jemand wusste, ein wirklich einfaches VM (ich dachte RISC/PIC war nahe an dem, was ich wollte), die in der Regel verwendet für embedded-Projekten wie der Steuerung von Robotern, Motoren, sensoren, etc.Meine größte Sorge ist, dass schreiben ein compiler/assembler, wenn ich roll mit meiner eigenen.Ich würde nett sein, verwenden Sie die Werkzeuge, die sind schon draußen oder in seiner einfachsten form nur ein C-compiler, kompilieren kann es :-p.

Ich möchte wirklich nicht das Rad neu erfinden, aber hier muss ich auch Tausende dieser läuft um eine virtuelle Welt, so dass Sie haben, um so einfach und so schnell wie möglich.Als eine person, die hat schon gesagt ich habe auch keine Sorge über Reale Probleme der Welt solch einem timing und Busse und alle, die Spaß Zeug.Ich denke, dass Ihre virtuellen Uhren beschränkt sich auf etwas ziemlich langsam;und irgendwann werde ich wohl schauen müssen, in native Kompilierung, um Sie noch schneller, aber für jetzt bin ich nur darum, Prototypen zusammen, um Euch ein proof-of-concept.

Als Eingabe, ich bin der Planung auf die Entfernung, die Licht -, material-und touch-sensoren montiert, um den zylindrischen Körper (16, vielleicht 32 von Ihnen), dann einfach 2 Motoren für Richtungs-Ausgang zur Steuerung einer Art von Rad auf jeder Seite.im wesentlichen die Verarbeitung nicht zu anstrengend ist und die Welt einfach genug, so dass die Maschine nicht haben zu werfen viele der Verarbeitung macht bei einfachen Aufgaben.

In Bezug auf Speicher, ich möchten, dass Sie in der Lage sein, um genug Daten werden allein für ein paar Tage ohne Eingriff für Gebäude maps und sammeln von Statistiken.Ich weiß nicht, wie 8bit, würde schneiden Sie es für die Verarbeitung oder Speicher, aber 16bit wäre definitiv ein Anwärter.32 und 64bit, nur drücken Sie es, und es gibt keine Möglichkeit, Sie ' ll haben mehr als 1 MB, jeden Speicher - wahrscheinlich näher 256-512 Kb.(Bill sagte 640 Kb genug sein würde, also warum kann ich nicht!!)

Answer 1

Wenn Sie etwas in der realen Welt verwurzelt wollen, eine der am häufigsten verwendeten Embedded-RISC-Mikrocontroller ist die PIC-Familie. Google gibt mehrere Emulatoren, aber ich glaube nicht, die Quelle für die meisten zur Verfügung.

Eine andere Möglichkeit ist QEMU, die bereits mehrere ARM Sorten emuliert.

und natürlich, wenn Sie nicht interessiert sind, eine reale Gerät emuliert, viel einfacher und eine bessere Leistung wäre Ihre eigene Rolle. nur mit dem, was Sie brauchen, und nicht in das Chaos der Staatsflaggen bekommen, Überlauf-Bits, begrenzten Busbreite, RAM-Timings, etc.

Answer 2

Ich schrieb Wren für einen Freund, der mit rund 16 K eine VM Sprache läuft auf einem Embedded-Controller wollte RAM. (Aber es erlaubt in dem Code 64k pro Prozess geschrieben.) Es enthält einen Compiler für eine dumme kleine Programmiersprache. Es ist alles, äh, ziemlich einfach und hat nicht viel gesehen, aber es ist genau das, was Sie in Ihrem ersten Absatz beschrieben.

Answer 3

Die HER "virtuelle Maschine" ist ungefähr so einfach wie Sie kommen.16-bit-Adressraum (in der Regel), 16-bit-Datenworte, zwei stacks, Speicher.Loeliger s "Gewinde Interpretierende Sprachen" sagt Ihnen viel darüber, wie zu bauen ein FORTH-interpreter auf einem Z80.

Answer 4

Wenn Sie einfach wollen, sollten Sie die Manchester Mark I. Siehe Seite 15 diese PDF . Die Maschine verfügt über 7-Anweisungen. Es dauert etwa eine Stunde einen Interpreter für sie zu schreiben. Leider sind die Anweisungen ziemlich dingt (das nicht, warum so ziemlich eine vollständige Spezifikation der Maschine ist auf einer Seite passen kann).

Javier Ansatz Ihre eigene Walz ist sehr pragmatisch. Entwerfen und eine winzige Maschine zu schaffen ist eine zweitägige Aufgabe, wenn überhaupt. Ich baute eine kleine VM für ein Projekt vor ein paar Jahren und es hat mir zwei Tage, um die VM mit einem einfachen visuellen Debugger zu schreiben.

Auch - hat es RISC sein? Sie könnten 68K wählen, sagen wir, für die es Open-Source-Emulatoren und 68K war ein wohlverstandenen Ziel für gcc.

Answer 5

Viele Menschen Spiel Programme zu schreiben und andere Anwendungen einbetten, eine Sprache in die Anwendung Benutzer zu ermöglichen, kleine Programme zu schreiben.

Soweit ich sagen kann, die beliebtesten eingebetteten Sprachen in sehr roughtly populärsten-erste Ordnung (obwohl „populäre“ bedeutet nicht unbedingt „besser“) zu sein scheinen:

• domänenspezifische Sprache massgeschneidert für diese spezifische Anwendung und sonst nirgends
verwendet
• Lua a
• Tcl
• ein b , oft eine vereinfachte Teilmenge wie PyMite c
• Forth
• JavaScript a
• Lisp
• ein
• ein b
• ein
• ein < a href = "http://www.cs.um.edu.mt/gordon.pace/Research/Papers/wict2010-01.pdf" rel = "nofollow noreferrer"> b
• NPCI (Nano Pseudo C Ausgelegt) ein
• Robotalk
• einig Hardware Maschinensprache zu interpretieren (Warum ist dies die am wenigsten beliebte Wahl? Aus guten Gründen, wie unten beschrieben).

Sie können das GameDev Stack zu prüfen, insbesondere Fragen wie " Wie fügen Sie eine Skriptsprache, um ein Spiel? ".

Sie möchten hier einige der Fragen, zu überprüfen, auf Stackoverflow „embedded language“ markiert; sowie "Auswählen eines Embedded Language" , "Was ist ein gut integrierbare Sprache, die ich für das Skripting in meiner Software verwenden kann? " „Alternativen zu Lua als eingebettete Sprache?“ "Welches Spiel Skriptsprache besser zu bedienen: Lua oder Python? ", etc.

Viele Implementierungen dieser Sprachen verwenden irgendeine Art von Bytecode intern. Oft zwei verschiedene Implementierungen der gleichen High-Level-Programmiersprache wie JavaScript zwei völlig verschiedene Bytecode verwenden languagES intern ( a ). Oft sind mehrere High-Level-Programmiersprachen kompilieren, um denselben zu Grunde liegenden Bytecode Sprache - zum Beispiel die Jython Implementierung von Python, die Rhino Implementierung von JavaScript, die Jacl Implementierung von Tcl, JScheme und einige andere Implementierungen von Scheme, und mehrere Implementierungen Pascal; alle auf den gleichen JVM-Bytecode kompiliert werden.

Details

Warum eher eine Skriptsprache verwenden, als einige Hardware Maschinensprache zu interpretieren?

Warum "Alternate harte und weiche Schichten" ? Zu gewinnen Einfachheit und schnellere Entwicklung.

schnellere Entwicklung

Die Menschen im Allgemeinen erhalten Sachen schneller arbeiten mit Skriptsprachen statt kompilierten Sprachen.

gibt es die erste Arbeits Prototyp ist in der Regel viel schneller - der Dolmetscher behandelt ein paar Sachen hinter den Kulissen die Maschinensprache zwingt Sie ausdrücklich darauf schreiben: die Anfangswerte von Variablen auf Null, Unterprogramm-prolog Einstellung und Unterprogramm -epilog Code, malloc und realloc und frei und Speicher-Management-Material bezogen, die Größe von Containern zu erhöhen, wenn sie voll bekommen, etc.

Wenn Sie einen ersten Prototyp haben, das Hinzufügen neues Features ist schneller: Skriptsprachen haben eine schnellen Bearbeitungs-Execute-Debug-Zyklen, da sie die „Übersetzen“ Stadiums der edit-kompilieren-execute-Debug-Zyklen von kompilierten Sprachen zu vermeiden.

Einfachheit

Wir wollen die eingebettete Sprache Sprache „einfach“ auf zwei Arten sein:

• Wenn ein Benutzer ein wenig Code zu schreiben, der etwas konzeptionell triviale Aufgabe der Fall ist, wollen wir diese Person nicht abzuschrecken mit einer komplexen Sprache, die 20 Pfund Bücher und Monate der Studie nimmt, um zu schreiben ein "Hallo, $ USER" ohne Pufferüberlauf.

• Da wir die Sprache sind die Umsetzung wollen wir etwas einfach zu implementieren. Vielleicht ein paar einfachen darunter liegenden Anweisungen können wir an einem Wochenende für einen einfachen Dolmetscher knock out, und vielleicht eine Art von vorbestehenden Compiler können wir mit minimalem Zwicken wieder verwenden.

Wenn Menschen CPUs bauen, Hardware-Einschränkungen immer den Befehlssatz am Ende begrenzen. Viele konzeptionell „einfache“ Operationen - Dinge, die Menschen die ganze Zeit - am Ende erfordern viele Maschinensprache Anweisungen zu implementieren.

Embedded Sprachen nicht über diese Hardware-Beschränkungen, so dass wir implementieren kompliziertere „Anweisungen“, die Dinge tun, die (ein Mensch) scheinen vom Konzept her einfach. Dies macht oft das System einfacher in beide Weisen oben erwähnt:

• Menschen direkt in der Sprache zu schreiben (oder Menschen Compiler für die Sprache zu schreiben) am Ende zu schreiben viel weniger Code, verbringen weniger Zeit in Einzelschritte durch den Code debuggen es, etc.

• Für jede solche höherer Ebene Betrieb, verschieben wir die Komplexität von dem Compiler eine Implementierung der Anweisung innerhalb des Dolmetschers. Anstatt den Compiler (Sie Code in schriftlicher Form) etwas höherer Ebene Betrieb in eine kurze Schleife in der Zwischensprache zu brechen (und immer wieder in Ihrem Interpreter zur Laufzeit durch diese Schleife Schritt-), gibt der Compiler eine Anleitung in der Zwischensprache (und Sie die gleiche Reihe von Operationen in Ihrem Dolmetscher Umsetzung dieser Zwischen „instruction“) schreiben. Mit all den intensiven CPU Sachen in der kompilierten Sprache implementiert ( „inside“ komplexe Befehle), extrem einfache Dolmetscher sind oft mehr als schnell genug. (Das heißt, vermeiden Sie verbringen viel Zeit den Aufbau einer JIT oder versuchen, die Dinge auf andere Weise zu beschleunigen).

Aus diesen und anderen Gründen verwenden viele Spieleprogrammierer eine „Scripting“ Sprache als „embedded Sprache“.

(Ijetzt sehen, dass Javier bereits empfohlen „verwenden eine eingebettete Scripting-Sprache“, so dass dies hat mich in eine lange Tirade eingeschaltet Warum das ist eine gute Alternative, um eine Hardware-Maschinensprache zu interpretieren und Alternativen zeigen, wenn eine bestimmte Skriptsprache nicht geeignet scheint).