Wahnsinn - MenuetOS, ein vollständig in x86 Assembler programmiertes Betriebssystem inkl. GUI & CO. Kein C Code!
-
MenuetOS ist ein komplettes 32 und 64 Bit Betriebssystem vollständig in x86 Assembler geschrieben, enthält keinen C Code oder ähnliches!
Das muß man mal gesehen haben, Respekt an die Entwickler!Ich bin tief beeindruckt.
Und das Ding ist sogar noch richtig performant, sogar auf uralten Rechner (> 386er notwendig), bietet TCP/IP Support, nen Browser, ne grafische Oberfläche uvm. und paßt auf eine 1 MB große Diskette.
Die DosBox und Doom läuft auf dem OS ebenfalls.Und da will mir einer sagen das man große Projekte nicht mehr in Assembler realisieren könnte.
http://www.menuetos.de/index.php5
MenuetOS kann man ürbigens auch in einer Virtuellen Maschine wie z.b. Bochs oder Qemu mal antesten.
-
Schaut euch mal das Youtube Video zu Menuet OS an:
http://www.youtube.com/watch?v=RoLrXv5sBko
(Es gibt noch ein paar weitere Videos)
-
Weiß jemand warum MenuetOS geforkt wurde?
Liegt es eventuell daran, daß der Kernel von MenuetOS 64 inzwischen propritär ist?
Das geforkte OS heißt Kolibri OS:
-
ich möchte vermuten wegen der x64-ISA, die sich nun doch etwas unterscheidet.
-
vollständig in x86 Assembler geschrieben, enthält keinen C Code oder ähnliches!
und welchen vorteil kann man sich davon versprechen?
-
hellihjb schrieb:
vollständig in x86 Assembler geschrieben, enthält keinen C Code oder ähnliches!
und welchen vorteil kann man sich davon versprechen?
SPEED! Wenig Resourcen-Verbrauch!
Auf Assembler-Ebene kannst du jeden schmutzigen Trick anwenden umd die Berechnung zu beschleunigen bzw. zu verkürzen und weil du den redundaten code reduzierst macht der code weniger überflüßiges und schneller das notwendige.
hat jemand die Zahlen zur Hand: Binary-Größe in Byte von "Hello, world!" für C,C++ und Asm? Aus verschwommener Erinnerung gelogen:
C/C++ 13KByte
ASM 80ByteDie Größenordnungen stimmen jedenfalls.
-
das bedeutet dass der programmierer ueberwiegend besseren (effezienteren und kuerzeren) code erzeugen muss als der compiler.
halte ich nicht fuer realistisch...
-
hellihjb schrieb:
das bedeutet dass der programmierer ueberwiegend besseren (effezienteren und kuerzeren) code erzeugen muss als der compiler.
halte ich nicht fuer realistisch...kommt drauf an. asm-programmierer wählen manchmal andere d.h. effizientere wege als ein hochsprachen-coder und compiler können leider immer noch nicht hellsehen.
-
hellihjb schrieb:
das bedeutet dass der programmierer ueberwiegend besseren (effezienteren und kuerzeren) code erzeugen muss als der compiler.
halte ich nicht fuer realistisch...Kommt immer auf den Programmierer an.
In den meisten Fällen ist das aber der Fall.
Bislang hab ich noch keinen C/C++ Compiler gesehen, der annähernd "optimalen" Code erzeugt.
-
Man kann in asm echt mit einer handvoll Befehlen ganz ansehnliche Sachen machen. Nur die Lesbarkeit und damit die Wartbarkeit und Wiederverwendbarkeit ist grausam.
-
Walli schrieb:
Man kann in asm echt mit einer handvoll Befehlen ganz ansehnliche Sachen machen. Nur die Lesbarkeit und damit die Wartbarkeit und Wiederverwendbarkeit ist grausam.
Und die Portabilität ist gleich Null.
frickler schrieb:
Bislang hab ich noch keinen C/C++ Compiler gesehen, der annähernd "optimalen" Code erzeugt.
Das liegt aber auch daran, dass x86 nicht für C Compiler optimiert ist. Wenn man sich andere Plattformen anschaut, die explizit für die Verwendung von C Compilern optimiert wurden (wie z.B. MSP430), dann stellt man fest, dass man per Hand kaum besseren Code als ein Compiler erzeugen kann.
:xmas1:
-
Pedobear schrieb:
Wenn man sich andere Plattformen anschaut, die explizit für die Verwendung von C Compilern optimiert wurden (wie z.B. MSP430), dann stellt man fest, dass man per Hand kaum besseren Code als ein Compiler erzeugen kann.
wie kommst'n darauf?
-
Wenn man sich ein bissl mit asm auskennt, dann fallen einem ein paar tricks ein die tatsächlich an die grenzen gehen,.. ich progge zwar "nur" atmel avr-asm,.. aber das ist och janz schön
besonders wenn es auf cyclegenauigkeit ankommt,..seid gegrüßt