warum werden betriebssysteme in c geschrieben?

[Simon2]

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.

[Mountain of Madness]

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.

[Gast]

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.

[rüdiger]

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?

[RM not VM]

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

[CStoll]

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.

[Gast]

rüdiger schrieb:

@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?

Das erklärt meines Erachtens nach gar nicht, warum ich mir jetzt die Optimierung der Registerbelegung sparen kann. Da kann die CPU noch so "speziell" sein.

Ich schätze mal es wird in den Fällen, wo diese CPU eingesetzt wird, halt einfach wurscht sein. Vielleicht ist es auch nur Wirtschaftler-Gefasel, dass die CPU für Java schnell ist und ein paar haben es geglaubt. Ein großer kommerzieller Erfolg scheint das ja eh nicht zu sein.

[Bitte geben Sie einen Ben]

Optimizer schrieb:

Vielleicht ist es auch nur Wirtschaftler-Gefasel, dass die CPU für Java schnell ist und ein paar haben es geglaubt. Ein großer kommerzieller Erfolg scheint das ja eh nicht zu sein.

warum baut dann einer der größten mikrochipshersteller solche prozessoren in serie?

[rüdiger]

RM not VM schrieb:

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

Und schon wieder ein reiner Forschungs Java-Prozessor.

It is part of a PhD thesis at the Vienna University of Technology, Austria.

Bei opencores findet man davon einige

Optimizer schrieb:

Das erklärt meines Erachtens nach gar nicht, warum ich mir jetzt die Optimierung der Registerbelegung sparen kann. Da kann die CPU noch so "speziell" sein.

Macht das nicht der Compiler (also der der den Bytecode erzeugt)?

Bitte geben Sie einen Ben schrieb:

Optimizer schrieb:

Vielleicht ist es auch nur Wirtschaftler-Gefasel, dass die CPU für Java schnell ist und ein paar haben es geglaubt. Ein großer kommerzieller Erfolg scheint das ja eh nicht zu sein.

warum baut dann einer der größten mikrochipshersteller solche prozessoren in serie?

Welcher? (Bitte mit Link).

[ARM Fan]

rüdiger schrieb:

Welcher? (Bitte mit Link)

ich weiss zwar auch nicht, welchen er meint, aber da steckt bestimmt ein ARM9/26EJ core drin.
--> http://www.arm.com/products/CPUs/ARM926EJ-S.html

[Java Fan]

@rüdi:
http://www.ajile.com/
http://www.imsystech.com/products/microprocessors.htm
^ ∞

[Artchi]

ARM Fan schrieb:

rüdiger schrieb:

Welcher? (Bitte mit Link)

ich weiss zwar auch nicht, welchen er meint, aber da steckt bestimmt ein ARM9/26EJ core drin.
--> http://www.arm.com/products/CPUs/ARM926EJ-S.html

ARM Ltd. ist definitiv kein Prozessor-Hersteller. Das ARM ein CPU-Design im Angebot hat, muß nicht heißen, das es auch hergestellt wird. Erst recht muß es nicht heißen, das es massig hergestellt wird.

[Bitte geben Sie einen Ben]

Artchi schrieb:

ARM Fan schrieb:

rüdiger schrieb:

Welcher? (Bitte mit Link)

ich weiss zwar auch nicht, welchen er meint, aber da steckt bestimmt ein ARM9/26EJ core drin.
--> http://www.arm.com/products/CPUs/ARM926EJ-S.html

ARM Ltd. ist definitiv kein Prozessor-Hersteller.

excuse moi, mr korinthenkacker, dass deren prozessoren in chinesischen sweatshops bezahlt von anderen firmen hergestellt werden wusste ich auch, geht aber total am punkt vorbei.

Erst recht muß es nicht heißen, das es massig hergestellt wird.

apple und nintendo sind nur 2 große unternehmen die arm chips kaufen.

[Gast]

rüdiger schrieb:

Macht das nicht der Compiler (also der der den Bytecode erzeugt)?

Nein, der Bytecode ist rein stackbasiert. Also push a, push b, add. Macht ja auch Sinn, der Bytecode soll schließlich maschinenunabhängig sein. Deshalb tu ich mir so schwer mit dem Gedanken, dass eine CPU dafür ideal ausgelegt sein kann.

[Gast]

Also zumindest zum ARM9 kann ich mal sagen, dass der Bytecode nicht der native Befehlssatz ist. Es gibt wohl eine J-irgendwas Version, mit einer Erweiterung, die nennt sich Jazelle, die dann auch den Java-Bytecode versteht. Das hört sich für mich nicht viel versprechend an (und vor allem hört es sich so an, als würde die Menschheit das nicht brauchen). Es ist halt "interpretieren" (übersetzen in Micro-Ops) was jede CISC-CPU in irgendeiner Weise macht und durch die Hardware wohl auch nicht langsam, aber es ist bestimmt besser, Bytecode hochoptimiert in die nativen Instruktionen zu übersetzen. Alleine schon, weil der Bytecode weiter von der Maschine weg ist (wir erinnern uns: Das ist die Idee und das Designziel vom Bytecode) als z.B. die x86-Befehle für eine x86-CPU.

[Artchi]

Bitte geben Sie einen Ben schrieb:

Erst recht muß es nicht heißen, das es massig hergestellt wird.

apple und nintendo sind nur 2 große unternehmen die arm chips kaufen.

Blub!!! Es ging um Java-CPUs! Und ARM-CPUs sind per Definition erstmal keine Java-CPUs. Es gibt für einen Chip-Hersteller die Möglichkeit eine Jazell ranzupflanzen, genauso wie eine FPU oder einen Grafikchip. Und ja, Nintendo verbaut ARM-CPUs (genauso wie fast jeder Mobiledevice-Hersteller). Aber bestimmt nicht um Java-Bytecode auszuführen.

Und über ARMs brauchst du mir nichts zu erzählen, da ich schon damals zu Acorns besten Zeiten (als ARM noch Acorn Risc Maschine hieß) auf einem ARCHIMEDES darauf programmiert habe und heute ARM sehr wohl weiter verfolge. Die meisten haben wahrscheinlich ARCHIMEDES-Computer nicht mal von Namen gekannt.

[rüdiger]

ARM Fan schrieb:

rüdiger schrieb:

Welcher? (Bitte mit Link)

ich weiss zwar auch nicht, welchen er meint, aber da steckt bestimmt ein ARM9/26EJ core drin.
--> http://www.arm.com/products/CPUs/ARM926EJ-S.html

ah, ok. Wenn ARM so etwas nicht gehabt hätte, wäre es wohl wirklich unbedeutend gewesen

Aber wie schon angemerkt ist das wohl keine Java-CPU, sondern eine CPU mit JIT in der Hardware. Aber das ist vermutlich eh der vernünftigste Weg so etwas zu bauen.

Java Fan schrieb:

@rüdi:
http://www.ajile.com/
http://www.imsystech.com/products/microprocessors.htm
^ ∞

also die beiden Firmen sind einer der größten microchiphersteller? ^[e]infin[/e]+1 :p

Optimizer schrieb:

rüdiger schrieb:

Macht das nicht der Compiler (also der der den Bytecode erzeugt)?

Nein, der Bytecode ist rein stackbasiert. Also push a, push b, add. Macht ja auch Sinn, der Bytecode soll schließlich maschinenunabhängig sein. Deshalb tu ich mir so schwer mit dem Gedanken, dass eine CPU dafür ideal ausgelegt sein kann.

Dann baut man eben eine "stackbasierte CPU".

Optimizer schrieb:

Also zumindest zum ARM9 kann ich mal sagen, dass der Bytecode nicht der native Befehlssatz ist. Es gibt wohl eine J-irgendwas Version, mit einer Erweiterung, die nennt sich Jazelle, die dann auch den Java-Bytecode versteht. Das hört sich für mich nicht viel versprechend an (und vor allem hört es sich so an, als würde die Menschheit das nicht brauchen). Es ist halt "interpretieren" (übersetzen in Micro-Ops) was jede CISC-CPU in irgendeiner Weise macht und durch die Hardware wohl auch nicht langsam, aber es ist bestimmt besser, Bytecode hochoptimiert in die nativen Instruktionen zu übersetzen. Alleine schon, weil der Bytecode weiter von der Maschine weg ist (wir erinnern uns: Das ist die Idee und das Designziel vom Bytecode) als z.B. die x86-Befehle für eine x86-CPU.

Warum sollte eine speziell dafür ausgelegte Hardware schlechter optimieren als eine Software? Den Punkt verstehe ich immer noch nicht. (Und nein, er wird nicht interpretiert, du selbst sprichst ja von übersetzen).

[Gast]

rüdiger schrieb:

Dann baut man eben eine "stackbasierte CPU".

Mit Verlaub, aber das ist doch Unsinn. Schon mal eine rein stackbasierte CPU gesehen? CPUs haben halt Register, in den denen sie Daten vom Hauptspeicher reinladen, damit rechnen und wieder zurückschreiben. Und im Bytecode steht nichts von Registern. Warum? Weil jede CPU nen anderen Registersatz hat. Da der Bytecode CPU-unabhängig sein soll, würde das keinen Sinn machen.

Wenn du im Bytecode was berechnen willst, pusht du es auf den Stack, anstatt es in ein Register zu laden und führst dann die Berechnung aus. Das ist aber nicht zu verwechseln mit dem Call stack, sondern es ist ein Berechnungs-Stack für die Postfix-Notation. Das ganze hat nichts damit zu tun, wie man eine CPU bauen würde.

[rüdiger]

@Optimizer
Und nun hält mich genau was davon ab eine CPU zu bauen, die keine Register hat, sondern einen internen Datenstack? "Normale" CPUs haben Register. Aber wir reden hier von einer CPU die speziell entworfen wurde.

btw. es gibt auch CPUs die FORTH Bytecode direkt ausführen können. Die werden ja auch so etwas intern haben.

[Hochstapler]

Optimizer schrieb:

rüdiger schrieb:

Dann baut man eben eine "stackbasierte CPU".

Mit Verlaub, aber das ist doch Unsinn. Schon mal eine rein stackbasierte CPU gesehen? CPUs haben halt Register, in den denen sie Daten vom Hauptspeicher reinladen, damit rechnen und wieder zurückschreiben. Und im Bytecode steht nichts von Registern. Warum? Weil jede CPU nen anderen Registersatz hat. Da der Bytecode CPU-unabhängig sein soll, würde das keinen Sinn machen.

was ist los mit dir? fehlt dir die vorstellungskraft für sowas?
--> http://www.ece.cmu.edu/~koopman/stack_computers/sec1_4.html