warum werden betriebssysteme in c geschrieben?

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