warum werden betriebssysteme in c geschrieben?
-
ist man bei beos eigtl. auf einen compiler festgelegt?
-
Beiträge die nur dazu dienen einen Flamewar aus diesem Thread zu machen, werde ich konsequent löschen. Falls ihr einen Bedarf für so einen Flamewar habt, eröffnet bitte einen eigenen Thread. Danke für das Verständnis.Ihr freundlicher Moderator
-
rüdiger schrieb:
BeOS/Haiku sind komplett in C++ etc.
Noch nie ins Repository von Haiku gesehen, hab greade hier ne cpu.c angeguckt, selbst in cpp-dateien sehen man mehr C o_O
-
haiku war nie komplett c++
es basiert u.a. auf den newos kern, der einiges an c enthält
-
Ich verstehe. Und Systeme wie Windows Vista werden jetzt nicht komplett in C++ geschrieben, weil man den vorherigen Kernel auch noch verwendet um Zeit zu sparen usw.
Gut, dann weiß ich, falls ich mal ein Betriebssystem entwickeln sollte, dass ich es in meiner Lieblingssprache (c++ ^^) schreiben kann.
-
beos ist komplett c++, jedoch ohne exceptions im kern
er grund ist, das die c++ eh lib von gcc nicht ring0-save ist und zu komplex zum nachbauen
ich hab auch schon mal n kleines hello world c++ os gebastelt
-
borg schrieb:
edit: gibts sogar schon
gibts schon lange, auch im iphone is einer drin
-
borg schrieb:
gibt doch auch schon in java geschriebene betriebssysteme: http://www.jnode.org/
warum auch nicht? die befehlssätze der prozessoren nimmt doch ständig zu, ich könnte mir durchaus vorstellen das es in zukunft prozessoren gibt die java bytecode interpretieren können.
edit: gibts sogar schon, http://de.wikipedia.org/wiki/PicoJava
Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen). Das führt die Idee des Bytecode ad absurdum. Natürlich sehe ich ein, dass der Computer beim Booten am Anfang etwas braucht, was er ohne Schnickschnack einfach ausführen kann, aber zu diesem Zweck könnte man die wichtigsten Teile (auch wenn sie in Java geschrieben sind) zu native code compilieren. Oder das BIOS startet einen extrem kleinen Microkernel, der kaum was anderes macht als die VM zu starten.
-
Optimizer schrieb:
Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen).
Das ist sehr praktisch, denn Bytecode-Programme sind ziemlich schlank.
Glaubst du auch, daß die Menschheit keine CISC-Prozessoren braucht?
-
Der Bytecode muss intern wieder in Micro-Ops zerlegt werden (weil auch ein CISC-Prozessor einen RISC-Kern hat) und das Endergebnis kann eigentlich nicht kürzer sein für das gleiche Programm. Man packt einfach, was der JIT-compiler normal macht, in die Hardware, aber was daran besser sein soll, erschließt sich mir nicht.
Sinnvoller würd ich da schon finden, wenn man den Prozessoren spezielle Befehle angedeihen ließe, die z.B. Garbage Collection beschleunigen.
-
Optimizer schrieb:
Wobei ich schon glaube, dass die Menschheit sowas nicht braucht (Prozessoren, die Java-Bytecode verstehen).
Irgendwie ist das ja schon eine interessante Sache... Wenn ich mich richtig erinnere, war das holen der Instruktionen aus dem Speicher einer der Flaschenhälse beim Ausführen eines "konventionellen" Programms. Liegt ja irgendwo auch nahe, höhere Befehle zu verwenden, v.a. weil die Technik ja schon weit fortgeschritten ist, wird ja mal Zeit für eine neue Version der Prozessortechnik
Schade fände ich nur, wenn man sich eben auf eine Programmiersprache festlegen würde, aber das ist ja eine andere Sache
-
Badestrand schrieb:
Schade fände ich nur, wenn man sich eben auf eine Programmiersprache festlegen würde, aber das ist ja eine andere Sache
bytecode für eine Java-VM muss nicht unbedingt mit einem Java-compiler erzeugt werden.
-
is ja nicht so... schrieb:
bytecode für eine Java-VM muss nicht unbedingt mit einem Java-compiler erzeugt werden.
Nunja, er wird aber wohl relativ Java-spezifisch sein (schätze ich
). Man kann doch auch aus unverschlüsseltem Bytecode den Quelltext fast vollständig wieder herstellen oder nicht?
-
@Optimizer
Für einen Server oder PC macht so ein Chip sicher keinen Sinn. Aber in einem mobilen Gerät ist so etwas theoretisch sicher nützlich, da man Rechenleistung so einsparen kann. Aber so viel Sinn scheint es dann doch nicht gemacht zu haben:It was never released as a product by Sun Microsystems and the sources are now open source.
http://en.wikipedia.org/wiki/PicoJava
Optimizer schrieb:
Man packt einfach, was der JIT-compiler normal macht, in die Hardware, aber was daran besser sein soll, erschließt sich mir nicht.
Ist schneller und spart mehr Energie
@gäähn
im iPhone? Würde doch wenig Sinn machen, wenn das nicht erweiterbar ist. Aber wird so etwas wirklich in Mobiltelefonen benutzt oder haben die einfach einen schnelleren ARM-Chip (oder was auch immer) eingebaut?Codebytes schrieb:
Glaubst du auch, daß die Menschheit keine CISC-Prozessoren braucht?
hmm, ja
Badestrand schrieb:
Wenn ich mich richtig erinnere, war das holen der Instruktionen aus dem Speicher einer der Flaschenhälse beim Ausführen eines "konventionellen" Programms.
Speicherzugriffe sind teuer. Aber ich glaube mal, dass der Code da ein weniger großes Problem darstellt.
-
rüdiger schrieb:
@Optimizer
Für einen Server oder PC macht so ein Chip sicher keinen Sinn. Aber in einem mobilen Gerät ist so etwas theoretisch sicher nützlich, da man Rechenleistung so einsparen kann....Könnte ich mir auch vorstellen.
"Bytecode" ist ja auch nichts Anderes als ein "CISC-Befehlssatz" ... IMHO liegt die Stärke einer bestimmten Architektur darin, dass man sie auf bestimmte Anwendungsgebiete "zuschneiden" kann - und dazu zählt eben auch "die CPU-Sprache" mit ihren speziellen Optimierungsmöglichkeiten (in Abstimmung mit dem Rest der Architektur).
Wenn man auf einem System sowieso im Wesentlichen "Javaspezifisches" laufen lassen will, kann es bestimmt sinnvoll sein, ihn direkt Java-Bytecode "denken" zu lassen.
Für einen "Numbercruncher" oder ein "I/O-Monster" gibt's bestimmt Effektiveres:
MERKE (um einer Emotionalität dieses Threads vorzubeugen): Ich sage NICHT, dass man in Java keine effektiven Programme für numerische Berechnungen oder I/O schreiben könnte. Ich sage nur, dass es auf Systemebene bestimmt NOCH effektivere Wege gibt das umzusetzen als über Bytecode.Gruß,
Simon2.
-
rüdiger schrieb:
Optimizer schrieb:
Man packt einfach, was der JIT-compiler normal macht, in die Hardware, aber was daran besser sein soll, erschließt sich mir nicht.
Ist schneller und spart mehr Energie
richtig. denn merke: was hardware kann ganz fix erreichen, das dauert in software schon ein weilchen
-
rüdiger schrieb:
Ist schneller und spart mehr Energie
Das halte ich immer noch nicht für erwiesen. Schon allein deshalb nicht, weil der Bytecode aus den Java-Compilern fast unoptimiert ist. Das live-interpreten der Prozessoren an sich mag ja schnell sein, aber das ersetzt nicht eine eigene, Prozessor-spezifische Optimierungsphase (normal optimieren Compiler den AST, dann den Zwischencode, dann den native code, wo am meisten Zeit aufgewendet wird, wegen Registerbelegung usw.).
Aber es gibt ja viel gröbere Probleme. Man kann am Bytecode nichts mehr ändern, z.B. hätte man in .Net die Generics nicht mehr hinzufügen können. Man gibt einfach die Vorteile dieser Zwischenschicht auf und verzichtet auf eine wichtige Optimierungsphase (oder beschränkt sie erheblich). Und das soll jetzt auf einmal geil sein.
-
Ruler of the Underworld schrieb:
rüdiger schrieb:
Optimizer schrieb:
Man packt einfach, was der JIT-compiler normal macht, in die Hardware, aber was daran besser sein soll, erschließt sich mir nicht.
Ist schneller und spart mehr Energie
richtig. denn merke: was hardware kann ganz fix erreichen, das dauert in software schon ein weilchen
Merke auch: Ist der Compiler nicht mehr schlau, wird die Hardware auch zum DAU.
-
n000b schrieb:
...
Gut, dann weiß ich, falls ich mal ein Betriebssystem entwickeln sollte, dass ich es in meiner Lieblingssprache (c++ ^^) schreiben kann.
Aber nur, wenn auf der Zielplattform auch ein C++-Compiler existiert.
-
Hallo
Betriebssysteme werden nicht nur in C geschrieben.
Es gab (und gibt teilw.) betriebssysteme in Modula, Mesa, LISP, Oberon, FORTH, PL/1, Smalltalk, BCPL ...
Druchgesetzt hat sich aber C, zusammen mit *n*x. Das hat viele Grunde, historische wie praktische.