Thema: Idee OS mit eigener Managed Sprache

[kevin]

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.

[bluecode]

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.

[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.

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

Code: [Auswählen]

// 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.

[kevin]

Das ist nicht der Bytecode, sondern eine Art Assemblersprache, die in Bytecode übersetzt wird.

[DeepDancer]

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 

BTW gabs doch hier noch jemanden der sowas in der Art machen wollte... Is der nimmer da?

Grüße,
DeepDancer

[remake]

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

Code: [Auswählen]

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 ^^

[MNemo]

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.

[kevin]

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.

[DeepDancer]

Ah ja es gab Singularity, total vergessen... [schnipp] ... Wollte irgendwie was anderes entwickeln, einfacher und offener ^^

Soso, vergessen....  

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   ).

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

[remake]

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...

Code: [Auswählen]


Basic }--------------\                                                                                             /--> {ARM}
C }------------------+--->[kompilieren]---> {"Managed Bytecode"} ---> [Interpretieren] ---+--> {x86}
Eigene Sprache }----/                                                                                             \--> {Sonstige..}



[remake]

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:

Code: [Auswählen]

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

[Jidder]

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:

Code: [Auswählen]

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.

[remake]

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ß

[MNemo]

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?

[kevin]

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.

[remake]

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.

[remake]

@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

[kevin]

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.

[MNemo]

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

[remake]

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ß