Lowlevel
Lowlevel => OS-Design => Thema gestartet von: remake am 29. December 2010, 19:13
-
Guten Abend,
mir ist so eben die Idee gekommen einen Kernel zu entwickeln der eine eigene Interpretersprache unterstützt, welche an Assembler vom Befehlssatz angelehnt ist. Auf realen Register wird bei der Sprache verzichtet, stattdessen müsste man virtuelle bereitstellen.
Sinn der ganzen Sache wäre nur den Kernel in C und Asm zu schreiben und den rest in dieser Interpretersprache... Man könnte das laufende System einfach pausieren und den Managed Bytecode anpassen und dann weiterlaufen lassen. Aber die wirklichen Vorteile sehe ich in der Sicherheit und in der Portierbarkeit des Systems, man müsste für einen anderen Prozessor z.B. ARM nur den Interpreter anpassen.
Das sind nur mal so die groben Ideen, klar perfekt ist es nicht, aber vll. Habt ihr weitere Anregungen oder Kritik.
Gruß
Remake
-
Schau dir mal Android an, das ist ein Linux-Kernel, in dem eine Java-Implementation läuft; das Android-System selbst ist in Java geschrieben. Der Unterschied zu realem Java ist, dass du bei Java-Bytecode eine stackbasierte Architektur hast, die sich schlecht auf reale CPUs mappen lässt, darum hat Android die Dalvik-Architektur, das ist registerbasierter Bytecode.
Im Prinzip baust du einen System-Emulator als Kernel; ob das mit den Treibern so einfach hinhaut, kann ich nicht einschätzen. Der wahrscheinlich beste Ansatzpunkt wäre, die Dalvik-Maschine auf bare Hardware zu portieren.
Probleme sehe ich insbesondere in der Performance, aber ich glaube, das weißt du sicherlich auch selbst. ;-)
-
Wenn man es richtig macht, sehe ich in der Performance keine Probleme. Die Interpretersprache darf man dann natürlich nicht wörtlich nehmen, sondern muss einen JIT-Compiler oder so hernehmen. Vorteil ist, dass man sich den ganzen Aufwand für Speicherschutz sparen kann, weil der in die Sprache/VM schon eingebaut ist - also keine Kontext- und Ringwechsel, alles kann sicher im selben Speicherkontext in Ring 0 laufen.
Einfach mal zwischendurch den Kernel neukompilieren und Teile austauschen wird natürlich schwierig,weil es ja immer auch ein paar nicht ganz unwichtige Daten gibt, die den Wechsel überleben müssen - und das, obwohl die Datenstrukturen möglicherweise geändert worden sind. Vermutlich nicht ganz so einfach. ;)
-
Abend und danke für die schnelle Antwort.
Ja,... Performance ist klar, das ein Interpretiertes Programm langsamer ist als ein Natives. Doch bei der heutigen Rechenpower bzw. wenn man sieht was mit Interpretersprachen so möglich ist, wenn der Interpreter gut optimiert ist... siehe JavaScript im Chrome mit der V8 Engine...
Problem sehe ich ähnlich wie du bei den Treibern, eventuell müssten diese weiterhin in C/ASM geschrieben sein.
Auch wenn es einen tick langsamer durch den Interpreter läuft, bleibt weiterhin der Vorteil, dass das OS in einer Art Sandkasten läuft bzw. vor Bufferoverflows usw. geschützt wäre... Eventuell bekommt man am Ende kein Betriebssystem für Hardcore Gamer heraus, was eh unrealistisch ist... aber was realistisch klingt wäre ein stabiler Kernel den man mit managed code füttern kann und ein kleines stabiles OS bieten könnte.
Gruß
Remake
-
Wenn man es richtig macht, sehe ich in der Performance keine Probleme. Die Interpretersprache darf man dann natürlich nicht wörtlich nehmen, sondern muss einen JIT-Compiler oder so hernehmen. Vorteil ist, dass man sich den ganzen Aufwand für Speicherschutz sparen kann, weil der in die Sprache/VM schon eingebaut ist - also keine Kontext- und Ringwechsel, alles kann sicher im selben Speicherkontext in Ring 0 laufen.
Einfach mal zwischendurch den Kernel neukompilieren und Teile austauschen wird natürlich schwierig,weil es ja immer auch ein paar nicht ganz unwichtige Daten gibt, die den Wechsel überleben müssen - und das, obwohl die Datenstrukturen möglicherweise geändert worden sind. Vermutlich nicht ganz so einfach. ;)
Ah ja JIT wäre auch eine Idee, aber zuerst würde ich das mit einen stabilen Interpreter probieren, optimieren kann man später immer noch ;-)
Ja der Kernel sollte schon sehr stabil und so minimal wie möglich sein... Das meiste in bytecode der im laufe des OS geändert werden kann... Also ein OS das während der Laufzeit verändert und debuggt werden kann. Ich glaube das wäre sehr interessant. Im Debug Modus sollte wirklich das komplette OS pausieren und nur Debugger und einen Codeeditor anzeigen, wo man während der laufzeit änderungen vornehmen kann... Kann mir vorstellen, das dies auch viel zur Sicherheit beiträgt, wenn der Benutzer direkt sehen kann was der Rechner alles macht.
Gruß
Remake
-
Naja, ich schätze mal, ein JIT ist nicht nice to have, sondern Pflicht. Die modernen JavaScript-Engines, die du als Beispiel nennst, sind auch längst keine Interpreter im klassischen Sinn mehr. Was für eine Performance du von einem reinem Interpreter zu erwarten hast, kannst du dir anschauen, indem du mal ein Linux in bochs bootest. Macht keinen Spaß.
Mit dem Ändern zur Laufzeit - wie gesagt: Wie gehst du mit geänderten Datenstrukturen um? Nehmen wir mal an, du hast ein neues Feld in eine Struktur eingefügt, die eine Page beschreibt. Die Daten der Speicherverwaltung beibehalten musst du auf jeden Fall, sonst kriegst du sehr schnell ein Problem.
-
So viele Gedanken wegen der Datenstruktur habe ich mir noch nicht gemacht.
Das sind alles erstmal nur grobe Gedanken...
Das später ein JIT Pflicht ist, ist klar.. aber für die ersten Tests sollte ein Interpreter ausreichen ;-) Und dann wird optimiert, ähnlich wie Google es macht, dort wird auch nachträglich V8 immer weiter optimiert.
Ja klar Bochs ist lahm, aber das auch ein kompletter Computer Emulator...
Aber Interpretersprachen wie PHP sind Performance mäßig auch akzeptabel ;-)
Gruß
Remake
-
Was die Datenstrukturen betrifft, spreche ich ja auch nicht von irgendeiner konkreten Datenstruktur. Aber du wirst definitiv den Fall haben, dass du einen Kernelteil austauschen willst, der im Moment irgendwelche Datenstrukturen benutzt, die erhalten bleiben müssen. Bei der Speicherverwaltung ist es ganz offensichtlich, denn ansonsten weißt du nicht mehr, welcher Speicherbereich frei ist und welcher nicht. (Das Beispiel ist gleichzeitig auch blöd, weil die Speicherverwaltung in der VM stecken wird und nicht im Managed Code ;)) Zum Beispiel Hardwaretreiber haben aber in der Regel auch irgendeinen Zustand, der erhalten bleiben muss.
An dieser Stelle musst du dir halt überlegen, wie du es hinkriegst, dass eine Struktur zwar in der neuen Version verändert wird, dass aber gleichzeitig die Daten im Speicher weiterbenutzt werden können. Vielleicht musst du an dieser Stelle transparent irgendwas konvertieren. Darüber würde ich mir Gedanken machen, wenn du das mit dem Austauschen ernst meinst, denn das halte ich für ein zentrales Problem.
Zur Geschwindigkeit von Interpretern wie PHP: Bist du sicher, dass es heute noch ein Interpreter ist? Aber abgesehen davon, zumindest in älteren Versionen war es auch so, dass man deutlich gespürt hat, wenn ein rechenaufwendigere Algorithmus in PHP implementiert war. Einigermaßen schnell wird es erst dadurch, dass für vieles die Standardbibliothek benutzt wird, die in C geschrieben ist. Genau das willst du bei deinem OS natürlich so weit wie möglich vermeiden, sonst schenkst du die ganze Sicherheit wieder her.
-
Ja genau, so weit wie möglich sollte auf C verzichtet werden.
Naja, dass ganze war jetzt erstmal nur eine grobe Idee, ich muss das ganze noch mal ein paar Tage im Kopf auswachsen lassen und schauen was das Ergebnis meiner Überlegung dann sein wird.
Vielleicht habt ihr noch Ideen oder Anregungen?
Oder habt Tipps für die Umsetzung?
Gruß
Remake
-
Naja, das ganze ist ein Projekt in einer Größe, wie es wahrscheinlich die wenigsten von uns schon umgesetzt haben. Statt "einfach" nur einem OS baust du gleichzeitig noch eine Programmiersprache, einen Compiler und eine VM. Das sind alles Dinge, die jede für sich sauber geplant sein sollten, wenn die Komponenten am Ende zu einem lauffähigen System zusammenspielen sollen und du nicht irgendwann feststellen willst, dass dein Design manche Features (wie z.B. das Austauschen von Modulen zur Laufzeit) gar nicht hergibt.
Anfangen würde ich erstmal bei der Spezifikation der Sprache (kannst du auch gern mal hier herzeigen, da werden sicher einige drüberschauen und Kommentare abgeben). Anschließend wahrscheinlich den Compiler unter einem existierenden OS, also z.B. Linux schreiben. Teilweise parallel dazu die VM anfangen und ebenfalls unter Linux testen, aber darauf acht geben, dass sie portabel geschrieben ist, so dass du sie später ohne größeren Aufwand in deinen Kernel einbauen kannst. Und erst dann, wenn das alles halbwegs tut, würde ich tatsächlich mit dem klassischen OS-Dev-Teil anfangen und den Kernel bauen, die VM draufsetzen und einen ersten Hello-World-Treiber in deiner Bytecode-Sprache schreiben.
-
Es gibt schon sowas, kannst du ja mal als Anregung nutzen:
https://github.com/mosa/MOSA-Project (https://github.com/mosa/MOSA-Project)
Die haben nen eigenen C# Compiler geschrieben, ob das jetzt alles in einer VM läuft weiß ich nicht mehr. Jedenfalls ist managed code.
-
Ja C# ist mir schon wieder ein tick zu weit von der Hardware entfernt. Naja ich werd mir die Tage mal einen kleinen Befehlssatz usw. einfallen lassen und davon hier berichten. Eine Compiler werde ich wohl in c++ zusammen mit qt schreiben, damit es leichter zu Portieren ist ^^ wird wohl eine Asm ähnliche Sprache, aber auch Basic Sprachen sollte man leicht zu diesem bytecode compilieren lassen. Muss mir das ganze mal morgen nach Feierabend anschauen und schauen was ich da zu Stande bekomme.
gruß
Remake
-
Guten Morgen,
hab gerade mal einwenig im Zug an der Idee gearbeitet. Was dabei heraus kam ist folgendes. Die Programmiersprache soll Anlehnungen an Assembler, Basic und BrainFuck haben. Der Interpreter soll ähnlich wie ein Brainfuck interpreter in C programmiert sein oder wie eine einfache Virtuelle Maschine (einfach mal in den Bochs Quelltext hineinschauen).
Es soll eine Art managed Assembler entstehen das in einer VM läuft und Basic ähnliche befehle bietet.
Hab mir überlegt verschiedene Virtuelle Register mit unterschiedlichen größen bereit zustellen, aber eventuell sollte ich diese Idee verwerfen... das sollte vll. doch die VM alles lösen.
Hier meine groben Überlegungen zu der Bytecodesprache:
;register
0x00 to 0x09 10x 8 bit register
0x10 to 0x19 10x 16 bit register
0x20 to 0x29 10x 32 bit register
0x30 to 0x39 10x 64 bit register
;relational operator
0x00 >
0x01 <
0x02 >=
0x03 <=
0x04 ==
0x05 !=
;managed bytecode
0x00 close programm
0x01 to 0x10 reserved
0x11 add (register, value)
0x12 sub (register, value)
0x13 mul (register, value)
0x14 div (register, value)
0x15 inc (register)
0x16 dec (register)
0x17 mov (register, egister)
0x18 for (operator, register"value left", register"value right", register"step")
0x19 endfor
0x20 if (operator, register"value left", register"value right")
0x21 elseif (operator, register"value left", register"value right")
0x22 else
0x23 endif
Beispiele:
IF reg0 >= reg1 THEN ... ENDIF
{0x20, 0x02, 0x00, 0x01, ..., 0x23}
FOR reg0 < reg1 STEP reg2 ... ENDFOR
{0x18, 0x01, 0x00,0x01,0x02, ..., 0x19}
Gruß
Remake
-
Morgen nochmal,
eventuell sollte ich die virtuellen Register rauswerfen und lieber eine Möglichkeit einbauen um Variablen mit Typen zu deklarieren. Somit könnte wie VM ordentlich den Arbeitsspeicher Managen... und es gäbe keine 32 bzw. 64 bit probleme bzw. keine unterschiede bei der Programmierung (außerhalb des Kernels).
Mit dem Befehlssatz von Post vorher sollte sich schon ein einfaches Basic realisieren lassen das zu diesen Managed Bytecode kompilieren kann... Was klar fehlt sind String, Text sowie Grafikausgabe. Da bei diesen Managedcode kein direkter zugriff auf dem Speicherstatt finden soll, muss ich mir noch eine Art und Weise ausdenken wie man methoden implementieren könnte.
So das die Kernel funktionen usw. per methode irgendwie aufgerufen werden kann.
Gruß
Remake
-
Nichts für ungut, aber dieser "Sprache" fehlt alles interessante. In vierzig Registern kriegst du unmöglich die gesamten Daten unter. Zumindest sowas wie Arbeitsspeicher wäre als Konzept noch ganz nett. Nächstes Problem ist, dass Integer zwar ein nützlicher Datentyp sind, aber eigentlich will man auch anderes haben, insbesondere Strukturen und Arrays. Du hast keinerlei Möglichkeit, Funktionen zu repräsentieren, außer du inlinst sie komplett (was irgendwie den Zweck einigermaßen verfehlt).
Ein Opcode für endif ist auch gelinde gesagt merkwürdig - das würde ja bedeuten, dass die VM den Code beim Ausführen erstmal aufwendig parsen muss. Es hat seinen Grund, warum richtige Architekturen keine if- und endif-Instruktionen sondern bedingte und unbedingte Sprünge haben. Deine Vergleichsoperatoren mappen auch schlecht auf die des Hosts, aber das ist dagegen fast schon ein Detail.
Wie du damit zur Laufzeit Code ersetzen können willst, ist mir ein Rätsel.
-
Nichts für ungut, aber dieser "Sprache" fehlt alles interessante. In vierzig Registern kriegst du unmöglich die gesamten Daten unter. Zumindest sowas wie Arbeitsspeicher wäre als Konzept noch ganz nett.
Ach quatsch xD Sowas nimm ich doch nicht böse auf ;-) Du hast ja auch Recht mit deinen Aussagen, wie in meinem letzten Post schon gesagt sollte ich die Idee mit den Virtuellen Registern verwerfen und stattdessen variablen mit Typen integrieren die von der VM verwaltet werden.
Ja, wegen funktionen muss ich mir noch genau Gedanken machen, da habe ich etwas im Kopf aber das ist noch total unausgereift. Aber mit dem funktionen Mechanismus soll man dann auch mit dem Kernel/Hardware kommunizieren.
Ja, ein Opcode für if/endif usw. ist merkwürdig hat in meiner Überlegung seinen Sinn und wüsste auch schon wie man dies gut umsetzen könnte.
-
Magst du das mit if/endif mal näher erläutern? Also sowohl wozu du es brauchst als auch wie du es effizient umsetzen willst?
-
Also if/endif usw. finde ich ganz nützliche Befehle, und da alles eh von einer VM interpretiert wird gibt es weniger gründe es weg zulassen als gründe es einzubauen.
Kann mir vorstellen das wenn die Bytecode sprache diese Befehle schon unterstützt es einfacher ist dafür eine Hochsprache zu entwickeln.
Hab mir nochmal Gedanken bezüglich Methoden und Variablen gemacht...
Das ist der erste Entwurf..
;managed bytecode
0x24 Variable deklarieren
0x25 Methode deklarieren
0x26 End Methode
;Datentypen
0x01 byte
0x02 int
0x03 float
0x04 string
usw. usw...
;Eine Variable vom Type Byte mit der ID 1 deklarieren
0x24(opcode) 0x01(Datentype) 0x01(id)
;Eine Variable vom Type Byte mit der ID 257 deklarieren
0x24(opcode) 0x01(Datentype) 0xFF(id) 0x01(id)
;Eine Methode mit der ID 1 deklarieren, welche ein Byte als Rückgabewert liefert
;Parameter könnte man über einen Stack der Methode mit geben
0x25(opcode) 0x01(Datentype 0x01(id) ... 0x26(opcode)
-
Das was du dir da ausdenkst, ist kein Bytecode, sondern einfach eine Kodierung von Quelltext mittels Zahlen. Dein Compiler wäre dann nichts anderes ein Komprimierer.
Vielleicht solltest du dir mal anschauen wie Java und .Net funktionieren.
-
Der Bytecode ist in der Informatik eine Sammlung von Befehlen für eine virtuelle Maschine. Bei Kompilierung eines Quelltextes mancher Programmiersprachen oder Umgebungen – wie beispielsweise Java – wird nicht direkt Maschinencode, sondern ein Zwischencode, der Bytecode, erstellt. Dieser Code ist in der Regel unabhängig von realer Hardware und im Vergleich zum Quelltext oft relativ kompakt.
Ansonsten wäre es nett mir zu erklären wo du den Unterschied siehst!?
Die Hochsprachen die später zu diesen Bytecode kompilieren sollen sehen ganz anders aus, bzw. gibt es nicht für alles einen Opcode, so dass bestimmte Befehle und auch spätere Objekt Orientiertung irgendwie anders und komplexer im Bytecode dargestellt werden.
Gruß
Remake
-
Du solltest dir wirklich mal ein paar echte Architekturen und Java/.Net anschauen. Dein Bytecode ist mehr oder weniger nutzlos - da könntest du auch gleich den Quellcode direkt interpretieren. Der eigentliche Sinn von Bytecode ist ja, dass eine relativ komplexe Hochsprache in eine simple hardwarenahe Form gebracht wird, die effizient und leicht in die Zielsprache (also z.B. x86-Maschinencode) übersetzt werden kann. Diese Vereinfachung hast du nicht, dein Bytecode ist genauso schwer zu parsen wie der ursprüngliche Quelltext.
-
Es könnte interessant sein sich mal LLVM anzuschauen. Die haben ja auch eine assemblerartige Zwischensprache. Hätte generell den Vorteil, dass es dazu schon eine rießige Toolchain gibt.
-
Du solltest dir wirklich mal ein paar echte Architekturen und Java/.Net anschauen. Dein Bytecode ist mehr oder weniger nutzlos - da könntest du auch gleich den Quellcode direkt interpretieren. Der eigentliche Sinn von Bytecode ist ja, dass eine relativ komplexe Hochsprache in eine simple hardwarenahe Form gebracht wird, die effizient und leicht in die Zielsprache (also z.B. x86-Maschinencode) übersetzt werden kann. Diese Vereinfachung hast du nicht, dein Bytecode ist genauso schwer zu parsen wie der ursprüngliche Quelltext.
Also ich hab mir mal den Bytecode (Die zwischensprache von .Net angeschaut) MSIL...
http://www.fh-wedel.de/~si/seminare/ws02/Ausarbeitung/5.msil/MSIL4.htm
// Metadata version: v2.0.50215
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 2:0:0:0
}
.assembly sample
{
.custom instance void [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 )
.hash algorithm 0x00008004
.ver 0:0:0:0
}
.module sample.exe
// MVID: {A224F460-A049-4A03-9E71-80A36DBBBCD3}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000001 // ILONLY
// Image base: 0x02F20000
// =============== CLASS MEMBERS DECLARATION ===================
.class public auto ansi beforefieldinit Hello
extends [mscorlib]System.Object
{
.method public hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello World!"
IL_0006: call void [mscorlib]System.Console::WriteLine(string)
IL_000b: nop
IL_000c: ret
} // end of method Hello::Main
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: call instance void [mscorlib]System.Object::.ctor()
IL_0006: ret
} // end of method Hello::.ctor
} // end of class Hello
Ich weiß ja nicht wo die einfacher sein sollte!?!?
Also da ist meine Sprache schneller zu richtigen x86 befehlen übersetzt.
-
Das ist nicht der Bytecode, sondern eine Art Assemblersprache, die in Bytecode übersetzt wird.
-
Moinsen,
ist das nicht auch wieder mal so ein Ansatz wie ihn den MS mit Singularity auch verfolgt?
Das solltest Du dir denn auch mal anschaun, zumal man das ja - wenn es denn noch so ist - im Quellcode runterladen kann da dieser frei verfügbar ist :-D
BTW gabs doch hier noch jemanden der sowas in der Art machen wollte... Is der nimmer da?
Grüße,
DeepDancer
-
Das ist nicht der Bytecode, sondern eine Art Assemblersprache, die in Bytecode übersetzt wird.
Ja, das ist der Bytecode in klartext... ;-)
Bei mir sieht der Bytecode in einem klartext dann auch so aus
mov 01,02
if 01 < 04
usw.
Aber bei MS ist genau dieses MSIL die Sprache welche halt in bytecode komprimiert dargestellt wird.
Wollte damit nur sagen, das der Bytecode von MSIL (.net) viel komplexer ist und einen viel komplexeren Parser und Interpreter oder JIT-Compiler benötigt als die von mir überlegten Befehle.
Ah ja es gab Singularity, total vergessen, hatte ich mir vor einigen Jahren mal Just4fun angesehen, aber das ist halt pure .net ;-) Wollte irgendwie was anderes entwickeln, einfacher und offener ^^
-
da könntest du auch gleich den Quellcode direkt interpretieren.
So würde ich jetzt Assembler definieren. Und so wie ich remake verstanden habe hat er das auch vor, auch wenn da dann von einer eigenen Sprache zu sprechen irreführend ist.
Also da ist meine Sprache schneller zu richtigen x86 befehlen übersetzt.
:? Hast du den Code überhaupt verstanden :? Es gibt da ein ldstr und ein ldarg, die sich mit einfachen mitteln
(je ein mov rdi, xxx) in x86-Assembler umwandeln lassen. Ansonsten ist das alles schon x86, da steht nämlich nur noch 'nop', 'call' und 'ret'.
Ich würde dir auf jeden Fall empfehlen erst mal einen nutzbaren Assembler zu entwerfen bevor du dich auf eine Codierung festlegst.
-
Aber bei MS ist genau dieses MSIL die Sprache welche halt in bytecode komprimiert dargestellt wird.
Du übersiehst dabei nur, dass dein eigener Bytecode zwar komprimierter Assemblercode ist, das aber nicht zwingend auf andere Implementierungen zutrifft. Java/.Net hab ich mir noch nicht im Detail angeschaut, aber ich schätze mal, dass der Assembler auch dort wesentlich mehr macht als nur zu "komprimieren". Zwischen Assemblercode und Maschinencode liegt eben doch nochmal eine Verarbeitungsstufe. Globale Variablen werden sicher in keinem vernünftigen Maschinencode mitten im Code "deklariert".
Und wie gesagt, kein Maschinencode hat ein if...endif-Konstrukt, das ist nicht effizient umsetzbar. Anstatt einfach einen vom Assembler vorherberechneten Sprung zu machen, musst du jetzt alle Befehle anschauen und ignorieren bis du das endif findest. Das ist einfach die falsche Abstraktionsstufe für Maschinencode.
Wollte damit nur sagen, das der Bytecode von MSIL (.net) viel komplexer ist und einen viel komplexeren Parser und Interpreter oder JIT-Compiler benötigt als die von mir überlegten Befehle.
Der eigentliche Interpreter wird bei deinem Bytecode natürlich einfacher sein (Überraschung, hat ja auch kaum Features im Vergleich), aber der Parser wird vermutlich deutlich aufwendiger.
-
Ah ja es gab Singularity, total vergessen... [schnipp] ... Wollte irgendwie was anderes entwickeln, einfacher und offener ^^
Soso, vergessen.... :wink:
Also viel offener als die Sourcen zur Verfügung zu stellen geht doch ned wirklich? *gg*
Ich mein ich finde ja den Ansatz von Singularity an sich auch echt gut, würde es auch mir als Softi manchmal die Arbeit bisserl erleichtern (zumindest denk ich mir das so schön zurecht :-D ).
Um eine gewisse Komplexität im Bytecode wirst du nicht rum kommen wenn auch vernünftige Programme rauskommen sollen am Ende.
Und ich bin echt gespannt wie dein Projekt weitergeht - das gefällt mir auf jeden Fall schon mal :)
-
Und so wie ich remake verstanden habe hat er das auch vor, auch wenn da dann von einer eigenen Sprache zu sprechen irreführend ist.
Nein ^^ Ich möchte den code erstmal nicht in Assembler übersetzen...
Ich stelle es mir so vor...
Basic }--------------\ /--> {ARM}
C }------------------+--->[kompilieren]---> {"Managed Bytecode"} ---> [Interpretieren] ---+--> {x86}
Eigene Sprache }----/ \--> {Sonstige..}
-
Zwischen Assemblercode und Maschinencode liegt eben doch nochmal eine Verarbeitungsstufe. Globale Variablen werden sicher in keinem vernünftigen Maschinencode mitten im Code "deklariert".
Und wie gesagt, kein Maschinencode hat ein if...endif-Konstrukt, das ist nicht effizient umsetzbar. Anstatt einfach einen vom Assembler vorherberechneten Sprung zu machen, musst du jetzt alle Befehle anschauen und ignorieren bis du das endif findest. Das ist einfach die falsche Abstraktionsstufe für Maschinencode.
Ähm ja ^^ Langsam weiß man nicht mehr wer was meint bei den ganzen Begriffen, Maschienencode, Assembler, Bytecode usw. usw.
Ich möchte keinen Maschienencode heraus bekommen, der direkt auf der Hardware läuft... Das sollte später dann ein Interpreter oder der Just In Time(kurz JIT-) Compiler übernehmen. Sonst ist das nicht mehr Plattform unabhängig. Das die befehle ähnlich wie bei Assembler sind.. naja das ist halt so ^^ MS hat mit MSIL ja auch scheinbar bei Assembler abgeschaut. ;-)
Hier ein Java Bytecode der durch einen "disassembler" geschickt wurde um leserlich darzustellen:
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
11: iload_2
12: iload_1
13: if_icmpge 31
16: iload_1
17: iload_2
18: irem
19: ifne 25
22: goto 38
25: iinc 2, 1
28: goto 11
31: getstatic #84; //Field java/lang/System.out:Ljava/io/PrintStream;
34: iload_1
35: invokevirtual #85; //Method java/io/PrintStream.println:(I)V
38: iinc 1, 1
41: goto 2
44: return
wie man da sehen kann gibt es auch dort if, goto usw. seltsame Dinge die nichts mit Assembler oder Nativen Maschinencode zu tun haben... Aber es ist halt der Bytecode den die JavaEntwickler sich ausgedacht haben und dieser kann später mit einem Interpreter ausgeführt werden oder mit einem JIT-Compiler für die jeweilige Hardware in richtigen Maschinencode umgewandelt werden. ;-)
Edit:
Gerade noch was gefunden... hier sieht man schön den leserlichen code sowie er als Hex dargestellt wird:
// Bytecode stream: 03 3b 84 00 01 1a 05 68 3b a7 ff f9
// Disassembly:
iconst_0 // 03
istore_0 // 3b
iinc 0, 1 // 84 00 01
iload_0 // 1a
iconst_2 // 05
imul // 68
istore_0 // 3b
goto -7 // a7 ff f9
Gruß
Remake
-
Das if_icmpge funktioniert nicht so wie dein if/endif. Das springt z.B. zum Offset 44, wenn eine bestimmte Bedingung wahr ist, und sonst gehts mit der folgenden Instruktion weiter. Das Springen zum Offset ist der entscheidene Unterschied vom Java-Bytecode zu deiner Darstellung mit if/endif-Blöcken. Ein endif gibt es dort nicht.
Der Unterschied setzt sich fort bei diesen Opcodes:
0x24 Variable deklarieren
0x25 Methode deklarieren
0x26 End MethodeFür solche Operationen muss zur Laufzeit kein Code ausgeführt werden, sondern das Ganze kann zur Compilezeit bzw. beim Laden abgehandelt werden. Bei dir hingegen sind diese Deklarationen gleichrangig mit Operationen im Code verteilt und dein Interpreter muss diese Abschnitte überspringen. Alternativ kann er ein Verzeichnis mit diesen Methodendefinitionen aufstellen. Aber es ist Zeitverschwendung, das beim Laden zu machen, weil der Compiler es bereits hätte machen können. Dann bräuchte der Compiler diese Opcodes auch nicht mehr generieren. Und dann bist du wieder einen Schritt näher an Java/.Net.
-
Desto mehr ich über den Java Bytecode lese, desto interessanter wird es.
Also bei .Net sowie bei Java wird auf Register und Speicherzugriff im Bytecode verzichtet, stattdessen wird alles mit Stacks gemacht. Werte an Methoden übermitteln, sowie Rückgabewerte und viel mehr läuft über einen Stack ab.
Das lass ich mal in meine planung einfließen. ;-)
Gruß
-
Also…
Maschinencode ist von einer Maschine direkt ausführbarer Code. Assembler ist die Menschen lesbare Form davon. Und Bytecode ist ein Maschinencode für ein Virtuelle Maschine.
Klar gibt es da IF-Konstrukte im Assembler, aber es gibt kein ENDIF, und was hat da nichts mit Nativem Maschinencode(für echte CPUs) tun? Das ist alles recht nah am echten Befehlssatz dran, welche CPU hat denn keine load, store, jump und/oder call, compare, und if befehle?
-
Zwischen Assemblercode und Maschinencode liegt eben doch nochmal eine Verarbeitungsstufe. Globale Variablen werden sicher in keinem vernünftigen Maschinencode mitten im Code "deklariert".
Und wie gesagt, kein Maschinencode hat ein if...endif-Konstrukt, das ist nicht effizient umsetzbar. Anstatt einfach einen vom Assembler vorherberechneten Sprung zu machen, musst du jetzt alle Befehle anschauen und ignorieren bis du das endif findest. Das ist einfach die falsche Abstraktionsstufe für Maschinencode.
Ähm ja ^^ Langsam weiß man nicht mehr wer was meint bei den ganzen Begriffen, Maschienencode, Assembler, Bytecode usw. usw.
Ich möchte keinen Maschienencode heraus bekommen, der direkt auf der Hardware läuft... Das sollte später dann ein Interpreter oder der Just In Time(kurz JIT-) Compiler übernehmen.
Bytecode und Maschinencode ist größtenteils äquivalent. Maschinencode ist der Bytecode einer Maschine, die zufällig in Hardware existiert, und Bytecode ist der Maschinencode einer rein virtuellen Maschinen. Also ist das eigentlich mehr oder weniger dasselbe. Deswegen ist es auch sinnvoll Maschinencode z.B. von x86 mit dem Bytecode deiner VM zu vergleichen.
Sonst ist das nicht mehr Plattform unabhängig. Das die befehle ähnlich wie bei Assembler sind.. naja das ist halt so ^^ MS hat mit MSIL ja auch scheinbar bei Assembler abgeschaut. ;-)
Nein, das ist nicht einfach nur so, sondern das hat den Grund, dass man schon maschinennah (aber immer noch plattformunabhängig) sein will, damit die Übersetzung in die endgültige Form effizient geht. Letztendlich will man ja doch immer bei Maschinencode für eine Registermaschine rauskommen, da gibt es also genug Gemeinsamkeiten.
Hier ein Java Bytecode der durch einen "disassembler" geschickt wurde um leserlich darzustellen:
wie man da sehen kann gibt es auch dort if, goto usw. seltsame Dinge die nichts mit Assembler oder Nativen Maschinencode zu tun haben...
Im Gegenteil sieht das sehr viel mehr nach Maschinencode aus als dein Bytecode. Was bei der Java-VM vielleicht noch etwas "komisch" oder ungewohnt aussieht, ist dass die Java-VM keine Registermaschine, sondern eine Stackmaschine ist.
if und goto (zumindest wenn if ein bedingter Sprung ist, wie es hier aussieht) sind keine seltsamen Dinge für eine Maschinensprache. Auf x86 existieren sie genauso und sind unverzichtbar, nur dass sie Jcc und JMP heißen. Ein endif wiederum oder ein else wirst du im Java-Bytecode nicht finden. Variablen müssen auch irgendwo liegen, aber sicher nicht wie bei dir mitten im Code.
Aber es ist halt der Bytecode den die JavaEntwickler sich ausgedacht haben und dieser kann später mit einem Interpreter ausgeführt werden oder mit einem JIT-Compiler für die jeweilige Hardware in richtigen Maschinencode umgewandelt werden. ;-)
Naja, der Punkt ist halt, dass die Java-Entwickler nicht einfach irgendwas runtergeschrieben haben, sondern sich was dabei gedacht haben. Natürlich ist der Bytecode immer das, was sich sein Entwickler eben ausgedacht hat, aber es gibt trotzdem besser und schlechter geeigneten Bytecode. ;)
-
Für solche Operationen muss zur Laufzeit kein Code ausgeführt werden, sondern das Ganze kann zur Compilezeit bzw. beim Laden abgehandelt werden. Bei dir hingegen sind diese Deklarationen gleichrangig mit Operationen im Code verteilt und dein Interpreter muss diese Abschnitte überspringen. Alternativ kann er ein Verzeichnis mit diesen Methodendefinitionen aufstellen. Aber es ist Zeitverschwendung, das beim Laden zu machen, weil der Compiler es bereits hätte machen können. Dann bräuchte der Compiler diese Opcodes auch nicht mehr generieren. Und dann bist du wieder einen Schritt näher an Java/.Net.
Stimmt, könnte man machen. Eine liste aller Methoden während des compilieren sammeln und am Anfang der auszuführenden Datei eine Verzeichnis schreiben, aber auch dann müsste ich die funktionen "deklarieren"... Naja mal schauen.
Klar gibt es da IF-Konstrukte im Assembler, aber es gibt kein ENDIF, und was hat da nichts mit Nativem Maschinencode(für echte CPUs) tun? Dass ist alles recht nah am echten Befehlssatz dran, welche CPU hat denn keine load, store, jump und/oder call, compare, und if befehle?
Ja klar gibt es jump befehle usw. aber keine CPU unterscheidet wirklich zwischen float, long, char usw. und das wird im JavaBytecode getan... Man wirft dort einen Float wert anders auf dem Stack als einen Integer Wert. ;-)
Das meine IF Anweisung einen Sprungpunkt zum code bekommt könnte man ja bewerkstelligen, damit bleibt das endif dann auch weg.
-
@taljeth: Danke ;-)
*hust* Wieder mal einiges gelernt... Also werd ich mir mal den JavaBytecode sowie den von .Net mal genauer unter die Lupe nehmen und mit dann noch einmal Gedanken machen.
xD Aber mein Code wäre auch gelaufen, wenn auch nicht so performant ^^ Aber da wird das ja nicht wollen, werd ich mir mal weiter Dokumentationen über Bytecode durchlesen und dann noch einmal das Planen angehen.
Gruß
Remake
-
Stimmt, könnte man machen. Eine liste aller Methoden während des compilieren sammeln und am Anfang der auszuführenden Datei eine Verzeichnis schreiben, aber auch dann müsste ich die funktionen "deklarieren"... Naja mal schauen.
Ja, Tabellen (oder Verzeichnisse, wie du sie nennst) wird du einige brauchen. Aber wenn man sie nicht mit dem Code mischt, sondern an einer Stelle zusammenbringt, wird es sehr viel leichter, sie zu benutzen.
Ja klar gibt es jump befehle usw. aber keine CPU unterscheidet wirklich zwischen float, long, char usw. und das wird im JavaBytecode getan... Man wirft dort einen Float wert anders auf dem Stack als einen Integer Wert. ;-)
Ja, dass du mit typisierten Objekten arbeiten musst, ist der wesentliche Unterschied zu Maschinen wie x86. x86 kennt keine Strukturen und Arrays, sondern Pointer und Offsets zu diesen Pointern. Mit letzterem kannst du natürlich keine Sicherheit gewährleisten. Es spricht also manches dafür, dass die VM mit komplexeren Objekten umgehen können sollte und dann muss natürlich alles typisiert sein.
-
Klar gibt es da IF-Konstrukte im Assembler, aber es gibt kein ENDIF, und was hat da nichts mit Nativem Maschinencode(für echte CPUs) tun? Dass ist alles recht nah am echten Befehlssatz dran, welche CPU hat denn keine load, store, jump und/oder call, compare, und if befehle?
Ja klar gibt es jump befehle usw. aber keine CPU unterscheidet wirklich zwischen float, long, char usw. und das wird im JavaBytecode getan... Man wirft dort einen Float wert anders auf dem Stack als einen Integer Wert. ;-)
Hast du schon mal mit Floats im x86-Assembler programmiert? Für floats gibt es eine komplett eigenen Befehlssatz. Und zwischen 'long' und 'char' wird selbstverständlich auch unterschieden. Wo du recht haben könntest ist das ne cpu nicht zwischen 'char' und 'Byte' unterscheidet.
Das meine IF Anweisung einen Sprungpunkt zum code bekommt könnte man ja bewerkstelligen, damit bleibt das endif dann auch weg.
Das würde sich auf jeden Fall positiv auf die Qualität deines Assemblers/Bytecodes auswirken.
Aber da wird das ja nicht wollen, werd ich mir mal weiter Dokumentationen über Bytecode durchlesen und dann noch einmal das Planen angehen.
Bei der Recherche würde ich mich nicht nur auf VMs beschränken, sondern auch reale CPU Architekturen betrachten.
[edit]
BTW: es gibt auch noch LLVM (http://llvm.org/docs/LangRef.html)
-
Hast du schon mal mit Floats im x86-Assembler programmiert? Für floats gibt es eine komplett eigenen Befehlssatz. Und zwischen 'long' und 'char' wird selbstverständlich auch unterschieden. Wo du recht haben könntest ist das ne cpu nicht zwischen 'char' und 'Byte' unterscheidet.
Vielen Dank, aber das wusste ich jetzt wirklich nicht. Oder meinst du einfach nur das die Register 8,16 oder halt 32 Bit lang sind!?!? usw.
Assembler hab ich bis jetzt immer nur kleinere Dinge entwickelt. Hauptsächlich Programmiere ich in C++ seit neusten jetzt fürs Unternehmen auch ObjectiveC damit unsere Anwendungen auch im AppStore vertreten sind. Ansonsten halt Jahrelang .Net (naja solange gibt es das ja noch nicht), PHP, Java usw.
Aber trotz das ich Java und .Net entwickelt habe, hatte ich nie wirklich mir den Bytecode beider Sprachen/Frameworks angeschaut.
Gruß
-
Hast du schon mal mit Floats im x86-Assembler programmiert? Für floats gibt es eine komplett eigenen Befehlssatz. Und zwischen 'long' und 'char' wird selbstverständlich auch unterschieden. Wo du recht haben könntest ist das ne cpu nicht zwischen 'char' und 'Byte' unterscheidet.
Vielen Dank, aber das wusste ich jetzt wirklich nicht. Oder meinst du einfach nur das die Register 8,16 oder halt 32 Bit lang sind!?!? usw.
Nein, die Register sind alle gleich lang (zumindest auf MIPS und x86), 32- bzw. 64-Bit. Es kommt nur darauf an ob ich sie als Byte, Word oder Double(long) benutze.
-
:-D Das meinte ich doch ^^
Wie auch immer, ich werd noch einmal gründlich nachdenken und eventuell mal einen kleinen Test Kernel dann bereit stellen... Multiboot Kernel den man einfach in QEMU nutzen kann, sollte sich schnell in C realisieren lassen. So ne Art Überraschung für Euch ;-) Aber wohl nicht mehr Pünktlich zum neuen Jahr... Obwohl. habe morgen Frei... vielleicht fang ich mal ein kleines projekt an.
So mal am Rande... Find es cool das so viele hier beim Thema mit diskutieren und das mit wirklich guten Informationen, gibt viele Foren wo so etwas anders abläuft.
Gruß