warum werden betriebssysteme in c geschrieben?

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?

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.

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.

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).

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

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

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.

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.

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).

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.

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

Artchi schrieb:

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.

alder ne was bist du denn für ein troll, ich habe schon vor 3 seiten oder so hingewiesen dass so ein prozessor beispielsweise im iphone verbaut ist da brauchst du du auch nich mit deinen 1337 kenntnissen kommen. echt würdest du hier nich gepostet haben wär der trhead echt interessant geworden

Artchi schrieb:

Und über ARMs brauchst du mir nichts zu erzählen [...] und heute ARM sehr wohl weiter verfolge.

beweise es!
wovon handelt chapter B3 im 'arm architecture reference manual'?