Assembler Betriebssysteme

[Rotfuchs]

Hallo,

da ich mich die letzte Zeit mit der Programmierung von Betriebssystemen etwas mehr auseinander gesetzt habe, (C und Assembler) bin ich auf einige interessante Projekte gestoßen, welche versuchen ein Betriebssystem komplett in Assembler zu programmieren. Das hat den Vorteil, dass nicht aufwendige Übersetzungen von z.B. C in Assembler stattfinden müssen, sondern die Maschine direkt auf ihrer "eigenen" Sprache angesprochen wird. Die Ergebnisse sind mehr als erstaunlich, so lässt sich das KolibriOS innerhalb von 1! Sekunde in den grafischen Modus booten. (Getestet auf 800MHz, 1GB SD-RAM) - einige werden jetzt denken "na und?", aber das ISO des BS ist gerademal 3MB groß...

Die Anbindung von Treibern ist derzeit noch sehr klein - d.h. es werden nicht alle Tastaturen (vor allem USB) unterstützt und auch nicht alle Mäuse. Wie es mit dem Trackpoint aussieht muss ich noch testen. Auf dem Testsystem war auch die Netzwerkkarte nicht angesprochen.

Ich habe nur für mich selbst den Schluss daraus gezogen, dass es in Zukunft äußerst effektive Systeme geben kann, wenn sie richtig programmiert sind. Hier mal ein paar Links dazu:


http://www.menuetos.net/ (nur mit Floppy img)
http://www.kolibrios.org/ (Forke von MenuetOS mit CD-ISO)

 

[caputo]

Eigentlich geht die Entwicklung seit Jahrzehnten in die entgegengesetzte Richtung.

Früher gab es einige Betriebssysteme, die komplett oder größtenteils in Assembler geschrieben waren.

Heute macht das eigentlich niemand mehr, stattdessen wird C/C++ verwendet. Damit lässt sich wesentlich produktiver und fehlerärmer programmieren als mit Assembler.
Außerdem ist kann der C/C++-Code jederzeit (mit ein paar Anpassungen) für andere Prozessorachitekturen neu compiliert werden und schon läuft das OS. (Siehe Linux, das läuft ja praktisch auf allem, oder auch Windows NT, das ja ursprünglich neben Intel auch PowerPC und die legendären DEC Alpha-Architekturen unterstützte und gerade für Windows 8 auf ARM portiert wird).

Die Übersetzung macht der Compiler, und zwar nicht zur Laufzeit, sondern dann, wenn der Hersteller das Betriebssystem kompiliert, ausgeliefert wird dann Maschinencode.
Der einzige Vorteil von handgestricktem Maschinencode ist, dass man Optimierungen durchführen kann, die über die eingebauten Optimierungsfähigkeiten des Compilers hinausgehen. Allerdings sind optimierende Compiler wie z.B. der Intel-C-Compiler (http://software.intel.com/en-us/articles/intel-compilers/) schon ziemlich gut, da ist schon ein ganzer Haufen manuelles Profiling und Ooptimieren erforderlich, um wirklich bessere Ergebnisse zu bekommen.
Und an den Hot Spots, wo es ganz besonders auf Geschwindigkeit ankommt, kann man auch in C problemlos etwas Inline Assembler einfügen, wenn es denn sein muss.

Letztendlich fehlt die Zeit, die man in den Mehraufwand für die Assemblerprogrammierung und die Optimierung steckt, auf der anderen Seite beim Realisieren von Features und beim Testen. Und wenn man das Ding dann irgendwann auf einen ARM-Prozessor oder sowas portieren will, schaut man völlig in die Röhre.

Insofern bezweifle ich, dass man außerhalb von Hobbyprojekten in Zukunft viel Assembler in Betriebssystemen sehen wird. Es bleibt eher bei C/C++ mit wahrscheinlich zunehmendem Anteil von Managed Code im Userland (wegen nochmal gesteigerter Produktivität, verringerter Fehlerwahrscheinlichkeit & Angriffsfläche). In den letzten paar Jahren gab es sogar vereinzelt Projekte, ein komplettes Betriebssystem in Managed Code zu realisieren (z.B. Singularity).

 

[linrunner]

Treiber auch nur für einen kleinen Teil der verfügbaren Hardware in Assembler neu zu schreiben dürfte im besten Falle sehr lange dauern.

Der Meister persönlich schreibt übrigens in seinem Blog zum Thema C vs. Assembler (leicht aus dem Zusammenhang gerissen):

Some people seem to think that C is a real programming language, but they are sadly mistaken. It really is about writing almost-portable assembly language, [...]

 

[caputo]

Treiber auch nur für einen kleinen Teil der verfügbaren Hardware in Assembler neu zu schreiben dürfte im besten Falle sehr lange dauern.

Der Meister persönlich schreibt übrigens in seinem Blog zum Thema C vs. Assembler (leicht aus dem Zusammenhang gerissen):

Diese Sprüche gibt's aber auch erst, seit in größerem Umfang vernünftige Hochsprachen verfügbar sind.
In den 80ern hätte das niemand gesagt - außer ein paar verrückten Smalltalk-Typen (und vielleicht noch ein paar Lispler, Algolholiker und Fortransusen), aber die hat damals kaum einer ernst genommen. O tempora, o mores.

 

[linrunner]

Ich war schon in den 80ern der Meinung und das hat nichts mit einer (angeblichen) Rangordnung von Sprachen zu tun. Viele C-Konstrukte z.B. mit Pointern konnte man mit einem (oder ganz wenigen) 68000-Assember-Statements erledigen. Die Assoziation C als maschinenunabhängigen "Assembler" zu sehen liegt absolut nahe.

 

[malafide]

Dafür wurde C ja auch entwickelt.

PS: Falls die Treiber die dann geschrieben werden, und die ganzen Userland Dinge auch den Funktionsumfang eines modernen Betriebssystems haben, dann ists auch Essig mit 3MB 1Sekunden GUI Boot. Kommerziell benutzte OSe haben massenhaft Cruft, aber das würde sich bei AssemblerOS auch ansammeln. Nur die Entwicklungsgeschwindigkeit wäre schneckenlahm.

 

[demonicmaniac]

Ist sie ja auch wenn man sich Kolibri und Menuet anschaut. Die sind schon sehr lange around und die Hardwareunterstützung ist immer noch minimal. Trotzdem sind sie geniale Tech Demos was möglich ist.
Ein mir liebes Programm Beispiel z.b. ist auch e3 das in 30kb Assembler unterbringt wofuer die anderen editoren 300kb+ brauchen.
Wie es so schön heisst: Software bläht sich auf um die vorhandenen Ressourcen vollkommen zu belegen damit du alle 2 jahre neue kaufst

mfg demonicmaniac