programmiersprachen

[Marko]

programmiersprachen sind doch eigentlich schon programmierte "programme"!

doch wo ist die wurzel des programmierens?

oder muss man das garnicht als programmierer wissen?

genügt also nur das erlernen einer "programmierten" sprache?

ich hoffe ihr wisst was ich meine, auch wenn ich mich vielleicht nicht richtig ausgedrückt habe!!

mfg marko

[Crush]

Ich würde sagen in der Maschinensprache, weil dorthin im Endeffekt alles übersetzt wird und der Prozessor eine andere Sprache in Wirklichkeit nicht spricht. Wenn man damit arbeiten möchte, dann gibt es nur Assembler ohne jegliche echte Alternative, weil jede andere Programmiersprache eigentlich nur eine Abstraktion von Assembler ist, wobei Assembler-Mnemonics (ist kein Schreibfehler - heißt so) auch nur eine Abstraktion von den Maschinensprachebefehlen sind!

Das bedeutet: Zu 99% übersetzen die Compiler Programme in Assemblersourcecode oder (sehr selten) direkt in Assemblercode um, welcher dann mit einem Assembler-Compiler übersetzt und ausgeführt wird. Also ist jede Programmiersprache nur Mittel zum Zweck.

Maschinensprache ist aber auch nicht ganz das Teil unter der Haube, weil im Motor (der Prozessor) diese Codes wieder erst decodiert und Microcodes übersetzt werden, die das Pipelining und parallele CPU-Befehls-Abläufe ermöglichen. Die Daten und die Steuerbefehle werden wiederum getrennt und durch unterschiedliche Übersetzereinheiten gejagt. Genaugenommen ist der Microcode die tiefste Ebene.

Natürlich muß man das alles als Programmierer nicht unbedingt wissen (hängt aber auch von der Anwendung und des Programmzieles mit ab), aber das Wissen der Technik kann bei Programmentwicklungen (und auch deren Beschleunigungen) sehr hilfreich sein, außerdem auch bei Hardwareprogrammierung.

Daher kommt übrigens auch die Codeoptimierung eines Compilers. Der setzt zwar einerseits auch am Sourcecode des Programmes an, andererseits aber auch an der Übersetzungsweise der Befehlskonstrukte in Assembler und der Ausnutzung von CPU-spezifischen Eigenheiten die den Programmablauf beschleunigen können (z.B. das verwenden von CPU-internen-Registern für Parameterübergabe).

Die Thematik habe ich übrigens aus einer anderen Fragestellung heraus auch schon einmal angeschnitten gehabt.

[nic_power]

Hallo,

Original geschrieben von Crush

Maschinensprache ist aber auch nicht ganz das Teil unter der Haube, weil im Motor (der Prozessor) diese Codes wieder erst decodiert und Microcodes übersetzt werden, die das Pipelining und parallele CPU-Befehls-Abläufe ermöglichen. Die Daten und die Steuerbefehle werden wiederum getrennt und durch unterschiedliche Übersetzereinheiten gejagt. Genaugenommen ist der Microcode die tiefste Ebene.

Mikrocode ist ein typisches CISC-Feature und wird - wenn überhaupt - nur bei komplexen Instuktionen verwendet und bei weitem nicht von jedem Hersteller eingesetzt. Im Prinzip werden beim Einsatz von Mikrocode die CISC-Instruktionen in RISC-MOPs zerlegt, die in einem Takt ausgeführt werden können. Die meisten Instruktionen lassen sich dabei direkt währende der Dekodierung in eine Mikrocode-Operation (MOP) umsetzen. Ist dies nicht möglich, wird beispielsweise ein Pointer auf die entsprechende Mikrocode-Routine gesetzt (bei Intel geschieht dies im TC, d.h. natürlich auch, das in den davorliegenden Pipeline-Stufen ein "stall" auftritt solange der Code abgearbeitet wird.)

Mikrocode ist daher auch keine Voraussetzung fürs Pipelining oder die Parallelisierung auf CPU-Ebene! RISC führen die Befehle üblicherweise direkt aus und verwenden für komplexere Instruktionen Unterprogramme, die beispielsweise über Traps aufgerufen werden (ältere SPARC CPUs haben udiv/umul nicht implementiert, der Compiler erzeugt jedoch grundsätzlich diese Instruktionen im Code. Wird das Programm auf einer CPU ohne udiv/umul ausgeführt, tritt ein Trap auf, der Trap-Handler dekodiert die nicht vorhandene Instruktion und ruft die passende Softwareroutine auf).

Nic

[Crush]

Hinter RISC steckt aber auch eine andere Philosophie: Wenig Befehle mit schneller Ausführungsgeschwindigkeit - was fehlt muß man sich zusammenbasteln. Natürlich gibt es in der Prozessorlandschaft immer wieder einen anderen Ansatz - aber es ist auch etwas umständlich sich ständig mit allen Prozessortypen und -eigenheiten auseinanderzusetzen - alles kann man eh niemals kennen. Standardmäßig gehe ich hier im Forum mal von Intel-Chips aus, wenn nicht ausdrücklich von etwas anderem geredet wird. Allerdings werden auch bei RISC-Chips die Daten von den Befehlen getrennt und in Caches abgelegt. Klar, daß nicht zwingend jeder Prozessor mit Pipelines arbeitet - mein C64 kam auch ganz gut ohne aus =8-)

[nic_power]

Guten morgen,

Deine Argumentation kann ich nicht nachvollziehen, schliesslich diskutieren wie hier nicht im Intel-Developer-Forum. Die Frage war allgemeingültig gestellt und sollte daher auch allgemeingültig beantwortet werden. Wenn nicht ausdrücklich nach der Architektur gefragt wird, gehe ich davon aus, dass auch eine entsprechende Antwort gewünscht ist. Im Zweifelsfall kann man ja darauf hinweisen, dass eine bestimmte CPU angesprochen wird. Ansonsten besteht die Gefahr, dass der Fragesteller der Meinung ist alle CPUs arbeiten mit Mikrocode! Ausserdem stellt auch Intel viele unterschiedliche Prozessoren/Architekturen her, die sich selbst innerhalb einer Familie im Design deutlich unterscheiden (I860, Pentium 1-4, Xeon, Itanium 1 & 2); die Angabe "Intel-Chips" reicht da bei weitem nicht aus.

Wenn Du die Befehlssätze von RISC und CISC CPUs neueren Datums miteinander vergleichst, wirst Du feststellen dass die Unterschiede bei weitem nicht mehr so groß sind wie noch vor einigen Jahren. Natürlich werden auch bei RISC-Architekturen I-/D-Caches und Pfade voneinander getrennt, da es sich ursprünglich um ein typisches RISC-Merkmal handelte, welches später in vielen CISC-Architekturen übernommen wurde.

Nic

[Crush]

Wir haben leider nicht die Zeit jede Architektur auseinanderzuklaumüsern und damit ist der Antwort auch nicht gedient. Wir driften hier langsam aber sicher vom Thema ab, deshalb lassen wir das Technische ab jetzt einfach mal stehen. Um aber die herkömmliche Frage zu beantworten muß man eben etwas weiter schauen. Wenn meine Antwort vielleicht nur zu 70% korrekt ist (Welche ist das auch schon), dann wäre es nur hilfreich die Frage auch nochmal aus anderer Sicht erklärt zu bekommen. Ich bin immer lernbereit und gebe Fehler auch gerne zu, sobald sie mir klar werden. Ich bin ja nicht nur im Forum um Fragen zu beantworten, sondern auch mal Antworten auf interessante Fragen zu sehen und auch Neues dabei zu lernen.