warum werden betriebssysteme in c geschrieben?
-
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.
-
Optimizer schrieb:
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.).
Registerbelegung, Befehlsumsortierung etc. kannst du dir ja sparen, wenn der Bytecode bereits native von der Hardware verstanden wird.
Optimizer schrieb:
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.
Wir reden doch eh von Embedded-Systemen. Da ist ein ändern des Bytecodes eh unwahrscheinlich, selbst wenn die VM in Software läuft. Bei J2ME wird AFAIK auch nicht gejittet, sondern nur interpretiert. Daher gibt es auch keinen Native-Code bzw eine Optimierung davon. Die ganze Ebene fällt ja einfach weg. Egal ob interpretiert oder direkt in Hardware gegoßen.
Fincki schrieb:
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.
Bei welcher Sprache gäbe es diese Einschränkung nicht?
-
rüdiger schrieb:
Wir reden doch eh von Embedded-Systemen. Da ist ein ändern des Bytecodes eh unwahrscheinlich, selbst wenn die VM in Software läuft. Bei J2ME wird AFAIK auch nicht gejittet, sondern nur interpretiert. Daher gibt es auch keinen Native-Code bzw eine Optimierung davon. Die ganze Ebene fällt ja einfach weg. Egal ob interpretiert oder direkt in Hardware gegoßen.
Dann macht Java bzw. Bytecode doch noch weniger Sinn. Kann ich doch auch gleich Maschinencode "aufspielen". Der Bytecode hat doch gerade den Vorteil, das ich sagen kann, ich nehme Software A und spiele es auf meine Hardware/Plattform B, ohne neu kompilieren zu müssen. Aber wenn ich eh nichts einfach so wechseln kann, kann ich auch gleich native Software produzieren.
Der Sinn von Java-CPUs erschliesst sich mir bis heute nicht. Es war wohl damals einfach eine Schnappsidee, um dem langsamen Java eine Zukunft zu geben: "Heute ist Java zwar langsam, aber ihr könnt ruhig auf unser Pferd setzen, wir werden euch bald ne schnellere HW liefern!" Nur dumm gelaufen, das die Nicht-Java-CPUs eh schon schneller wurden und die Arbeit erledigt haben. Ist ein weiterer Markt für SUN weggefallen.
Wenn ich kompakten Code haben will, der auch gleich auf einer passenden CPU läuft, kann ich auch ARM-Thumb nehmen!
-
rüdiger schrieb:
Registerbelegung, Befehlsumsortierung etc. kannst du dir ja sparen, wenn der Bytecode bereits native von der Hardware verstanden wird.
Die Hardware arbeitet deswegen nicht auf magische Weise stack-basiert sondern muss dann die Registerbelegung zur Laufzeit machen. Da kommt dann natürlich auch was weniger optimales raus, wie wenn ein Compiler eine Stunde lang seinen dependency graph auswertet. Ich glaube weiterhin, dass man damit eine Optimierungsphase einfach auslässt und noch hat mir keiner erklären können, was der Gewinn davon ist.
rüdiger schrieb:
Wir reden doch eh von Embedded-Systemen. Da ist ein ändern des Bytecodes eh unwahrscheinlich
Das Ändern des Bytecode-Standards hat IMHO nichts mit embedded zu tun. Der Bytecode muss manchmal geändert werden, um neue Features zu unterstützen, wie zum Beispiel Generics. Das vermeidet Sun um jeden Preis, deshalb gibt es die Generics auch nur auf Sprachebene. Sauberer ist es aber in der Laufzeitumgebung wie bei .Net, weil dort nicht intern mit massenweisen eigentlich unnötigen checked casts gearbeitet wird und man auch value types verwenden kann. Vielleicht ist die vorhandene Hardware mit ein Grund, warum man die Bytecode-Spezifikation dazu nicht angefasst hat, aber auch das ist eben höchst suboptimal. Da wäre es doch besser, man könnte den Bytecode-Standard abändern und für die Hardware neu compilieren (zu native code).
Die CPU Bytecode verstehen zu lassen ist wie direkt aus dem AST native code zu erzeugen (denn der Bytecode ist dann in diesem Fall der native code), aber das macht heute kein Compiler (auch C++-native-Compiler generieren Zwischencode), aus gutem Grund. Die zusätzliche Schicht hilft, die verschiedenen Optimierungen richtig einzuordnen und macht Änderungen leichter.
-
rüdiger schrieb:
Fincki schrieb:
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.
Bei welcher Sprache gäbe es diese Einschränkung nicht?
bei C
--> <---Artchi schrieb:
Der Bytecode hat doch gerade den Vorteil, das ich sagen kann, ich nehme Software A und spiele es auf meine Hardware/Plattform B, ohne neu kompilieren zu müssen.
dieser vorteil bleibt auch erhalten, wenn die maschine den byte code direkt ausführen kann.
Artchi schrieb:
Der Sinn von Java-CPUs erschliesst sich mir bis heute nicht.
man kann z.b. auf 'ner desktop kiste entwickeln und testen und dann den bytecode unverändert auf dem target laufen lassen.
Artchi schrieb:
Wenn ich kompakten Code haben will, der auch gleich auf einer passenden CPU läuft, kann ich auch ARM-Thumb nehmen!
oder du benutzt einen 16- oder 8-bitter, keinen 32 bittigen RISC. dann ist der code immer kompakt
und wenn du meinst, das wäre eine einschränkung: thumb hat auch 'ne menge nachteile im vergleich zu native ARM code.Optimizer schrieb:
Der Bytecode muss manchmal geändert werden, um neue Features zu unterstützen, wie zum Beispiel Generics. Das vermeidet Sun um jeden Preis, deshalb gibt es die Generics auch nur auf Sprachebene.
man kann zwar was neues hinzufügen, aber alte funktionalität sollte man nicht einfach beseitigen. das ist eine eiserne regel bei etablierter software.
-
Artchi schrieb:
rüdiger schrieb:
Wir reden doch eh von Embedded-Systemen. Da ist ein ändern des Bytecodes eh unwahrscheinlich, selbst wenn die VM in Software läuft. Bei J2ME wird AFAIK auch nicht gejittet, sondern nur interpretiert. Daher gibt es auch keinen Native-Code bzw eine Optimierung davon. Die ganze Ebene fällt ja einfach weg. Egal ob interpretiert oder direkt in Hardware gegoßen.
Dann macht Java bzw. Bytecode doch noch weniger Sinn. Kann ich doch auch gleich Maschinencode "aufspielen". Der Bytecode hat doch gerade den Vorteil, das ich sagen kann, ich nehme Software A und spiele es auf meine Hardware/Plattform B, ohne neu kompilieren zu müssen. Aber wenn ich eh nichts einfach so wechseln kann, kann ich auch gleich native Software produzieren.
Da hast du mich falsch verstanden. Natürlich kannst du deine eigenen Programme beliebig aufspielen. Ich meinte eher das ändern der Bytecode-Specs.
Optimizer schrieb:
rüdiger schrieb:
Registerbelegung, Befehlsumsortierung etc. kannst du dir ja sparen, wenn der Bytecode bereits native von der Hardware verstanden wird.
Die Hardware arbeitet deswegen nicht auf magische Weise stack-basiert sondern muss dann die Registerbelegung zur Laufzeit machen. Da kommt dann natürlich auch was weniger optimales raus, wie wenn ein Compiler eine Stunde lang seinen dependency graph auswertet. Ich glaube weiterhin, dass man damit eine Optimierungsphase einfach auslässt und noch hat mir keiner erklären können, was der Gewinn davon ist.
Du hast doch auch beim Jitter keine Stundenlange Optimierungsphase. Geschweige denn beim Interpreter für J2ME. Ich sehe schon einen praktischen Hintergrund, einfach das so etwas viel Strom spart. Das ist bei Embedded Geräten ein entscheidender Vorteil. Aber mittlerweile sind so wohl Akkus, als auch Embedded CPUs wohl aussreichend gut, um so eine Idee doch nicht interessant genug zu machen.
Okay, ganz zu schweigen von Artchis Argument, dass so etwas ein Jave Werbegack ist und vermutlich ist es so was auch eine gute Idee für eine Diplom-Arbeit gewesen.
Artchi schrieb:
rüdiger schrieb:
Wir reden doch eh von Embedded-Systemen. Da ist ein ändern des Bytecodes eh unwahrscheinlich
Das Ändern des Bytecode-Standards hat IMHO nichts mit embedded zu tun. Der Bytecode muss manchmal geändert werden, um neue Features zu unterstützen, wie zum Beispiel Generics. Das vermeidet Sun um jeden Preis, deshalb gibt es die Generics auch nur auf Sprachebene. Sauberer ist es aber in der Laufzeitumgebung wie bei .Net, weil dort nicht intern mit massenweisen eigentlich unnötigen checked casts gearbeitet wird und man auch value types verwenden kann. Vielleicht ist die vorhandene Hardware mit ein Grund, warum man die Bytecode-Spezifikation dazu nicht angefasst hat, aber auch das ist eben höchst suboptimal. Da wäre es doch besser, man könnte den Bytecode-Standard abändern und für die Hardware neu compilieren (zu native code).
Gibt es überhaupt bestehende Hardware die im realen Einsatz ist. picoJava scheint ja nur ein Forschungsprojekt von SUN gewesen zu sein. (Ich denke eher Third-Party JVMs dürften bei der Entscheidung eine größere Rolle gespielt haben.)
Optimizer schrieb:
Die CPU Bytecode verstehen zu lassen ist wie direkt aus dem AST native code zu erzeugen (denn der Bytecode ist dann in diesem Fall der native code), aber das macht heute kein Compiler (auch C++-native-Compiler generieren Zwischencode), aus gutem Grund. Die zusätzliche Schicht hilft, die verschiedenen Optimierungen richtig einzuordnen und macht Änderungen leichter.
Ja, aber die Optimierungen gibt es bei J2ME gar nicht (da der Bytecode dort so weit ich weiß nur interpretiert wird). Aber auch beim Jitten hast du nur wenig Zeit für Optimierungen und da bekommst du in Hardware sogar noch mehr hin. (Auch wenn das Hardwaredesign dadurch natürlich immer komplexer und unflexibel wird).
-
Artchi schrieb:
....
Dann macht Java bzw. Bytecode doch noch weniger Sinn. Kann ich doch auch gleich Maschinencode "aufspielen". ...
Der Bytecode IST dann doch der Maschinencode !Ich bin ja nun wirklich kein Javaverfechter, kann mir aber zumindestens theoretisch vorstellen, dass es Architekturen gibt, die für Javaanwendungen prädestiniert sind und dann wüste ich nicht, warum man der CPU nicht gleich eine Bytecode-API verpassen sollte.
Die angesprochene "Plattformunabhängigkeit" von Bytecode spielt ja auch jetzt oberhalb der VM keine Rolle ... und ebenso wie es jetzt verschiedene (aber kompatible) Java-VMs und Intel-"RMs" ("real machines" ;), mein Compiler arbeitet auf verschiedenen Intel- und AMD-CPUs) gibt, gäbe es dann verschiedene Java-"RMs"...
BTW: Wenn ich recht informiert bin, gibt's doch auch schon Java-Chipkarten ... das wäre doch schon eine Anwendung.
Gruß,
Simon2.
-
Simon2 schrieb:
BTW: Wenn ich recht informiert bin, gibt's doch auch schon Java-Chipkarten ... das wäre doch schon eine Anwendung.
ja, eigentlich überall, wo Java laufen soll weder speicher noch prozessorleistung für eine VM vorhanden ist, wäre eine Java-RM gut.
-
rüdiger schrieb:
Optimizer schrieb:
rüdiger schrieb:
Registerbelegung, Befehlsumsortierung etc. kannst du dir ja sparen, wenn der Bytecode bereits native von der Hardware verstanden wird.
Die Hardware arbeitet deswegen nicht auf magische Weise stack-basiert sondern muss dann die Registerbelegung zur Laufzeit machen. Da kommt dann natürlich auch was weniger optimales raus, wie wenn ein Compiler eine Stunde lang seinen dependency graph auswertet. Ich glaube weiterhin, dass man damit eine Optimierungsphase einfach auslässt und noch hat mir keiner erklären können, was der Gewinn davon ist.
Du hast doch auch beim Jitter keine Stundenlange Optimierungsphase. Geschweige denn beim Interpreter für J2ME. Ich sehe schon einen praktischen Hintergrund, einfach das so etwas viel Strom spart. Das ist bei Embedded Geräten ein entscheidender Vorteil. Aber mittlerweile sind so wohl Akkus, als auch Embedded CPUs wohl aussreichend gut, um so eine Idee doch nicht interessant genug zu machen.
Wahrscheinlich sind wir uns einig, dass WENN interpretiert wird, dass es besser durch die Hardware gemacht wird als durch ne VM. Ich halte nur das Interpretieren generell für keine gute Sache. Für embedded Systeme ist IMHO das Beste, den Bytecode aufwändig und optimiert in native code zu übersetzen und direkt drauf zu spielen. Also nicht interpretieren oder JITen. Das wäre auch das stromsparendste...
Bei PCs, die vergleichsweise sehr inhomogen sind, halte ich es für eine gute Lösung, den Code zu JITen (ja, da gibt es unterschiedliche Ansichten). "Stundenlang" war natürlich übertrieben, aber heutzutage wenden VMs schon erhebliche Zeit auf, um den Code zu optimieren. Das geschieht aber oft im Hintergrund, die einzelnen Funktionen sind erstmal nur Stubs, die beim Aufruf die Compilierung triggern und bis diese abgeschlossen ist, wird der Code interpretiert... deshalb kriegst du davon nicht viel mit. Und es dauert auch eine ganze Zeit, bis sich der Aufwand gelohnt hat, deswegen hat Java vor allem bei Webservern eine recht gute Gesamtperformance.
-
Whisperer in the Darkness schrieb:
rüdiger schrieb:
Fincki schrieb:
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.
Bei welcher Sprache gäbe es diese Einschränkung nicht?
bei C
Hu?
@Optimizer
Aber die feinen Optimierungen kannst du dir ja sparen, wenn der Bytecode der native Code ist. Oder glaubst du wirklich, dass du mit einer Software JVM eine spezielle CPU schlagen kannst?
-
Optimizer schrieb:
Für embedded Systeme ist IMHO das Beste, den Bytecode aufwändig und optimiert in native code zu übersetzen und direkt drauf zu spielen. Also nicht interpretieren oder JITen. Das wäre auch das stromsparendste
hier: http://www.jopdesign.com/
da wird nix interpretiert
-
Optimizer schrieb:
rüdiger schrieb:
Optimizer schrieb:
rüdiger schrieb:
Registerbelegung, Befehlsumsortierung etc. kannst du dir ja sparen, wenn der Bytecode bereits native von der Hardware verstanden wird.
Die Hardware arbeitet deswegen nicht auf magische Weise stack-basiert sondern muss dann die Registerbelegung zur Laufzeit machen. Da kommt dann natürlich auch was weniger optimales raus, wie wenn ein Compiler eine Stunde lang seinen dependency graph auswertet. Ich glaube weiterhin, dass man damit eine Optimierungsphase einfach auslässt und noch hat mir keiner erklären können, was der Gewinn davon ist.
Du hast doch auch beim Jitter keine Stundenlange Optimierungsphase. Geschweige denn beim Interpreter für J2ME. Ich sehe schon einen praktischen Hintergrund, einfach das so etwas viel Strom spart. Das ist bei Embedded Geräten ein entscheidender Vorteil. Aber mittlerweile sind so wohl Akkus, als auch Embedded CPUs wohl aussreichend gut, um so eine Idee doch nicht interessant genug zu machen.
Wahrscheinlich sind wir uns einig, dass WENN interpretiert wird, dass es besser durch die Hardware gemacht wird als durch ne VM. Ich halte nur das Interpretieren generell für keine gute Sache. Für embedded Systeme ist IMHO das Beste, den Bytecode aufwändig und optimiert in native code zu übersetzen und direkt drauf zu spielen. Also nicht interpretieren oder JITen. Das wäre auch das stromsparendste...
Sorry, wenn ich mich einmische - aber letztlich interpretiert die Hardware doch immer etwas (im PC halt Assembler/Maschinensprache). Die Frage ist nur, wie nahe die von der CPU interpretierte Sprache am Ursprungscode liegt.