Wie funktioniert ein Computer?

Aus

Die Disk-Stations bestehen wie viele andere Computer auch, aus verschiedenen Komponenten bzw. Sub-Systemen, die wiederum fast wie eigene Computersysteme aufgebaut sind: Netzwerk, SATA, USB ... Da diese Sub-Systeme aber nicht für jegliche Aufgabe, sondern meist für spezielle Ansteurungszwecke von Geräten sind, bezeichnet man sie oft als Geräte-Controller oder kurz: Controller.

Im Gegensatz hierzu ist der Zentralprozessor oder auch Central Processing Unit (CPU) nicht für spezielle Zwecke konstruiert, sondern kann für allgemeine Rechen-Aufgaben (Computer = Rechner = rechnen) verwendet werden. Auch die CPU wiederum besteht aus einer Vielzahl an Komponenten, die untereinander kommunizieren oder spezielle Aufgaben wahrnehmen: Arithmetisch-Logische-Einheit (Arithmetic-Logical-Unit, kurz ALU), Gleitkomma-Recheneinheit (Floating Point-Instruction Unit, kurz FPU), schnelle Adress- und Datenzwischenspeichereinheiten (Instruction- bzw. Data-Cache) usw. usw.

Die Ansteuerung dieser Prozessor-internen Komponenten ist recht komplex und durchaus auch (historisch) verschieden (z. B. CISC versus RISC). Damit man mit dieser Komplexität einigermaßen umgehen kann, gibt es eine zentrale Steuereinheit im Prozessor, die diese Ausgabe übernimmt und die Signalsteuerung der Komponenten vornimmt. Um mit dieser Steuereinheit von außen kommunizieren zu können, werden die Funktionalitäten durch einen Bit-Code abgebildet. Der Bit-Code wird sozusagen durch einen Instruktions-Dekodierer (Instruction-Decoder) in diese internen Steuersignale umgewandelt. Da historisch und Anwendungsfall-bezogen sehr viele verschiedene Prozessor-Designs entstanden sind, sind auch die Bit-Codes (Maschinensprache) oft sehr verschieden. Trotzdem gibt es auch viele Gemeinsamkeiten: Register, Adress-Aufbau, grundsätzliche Rechen- und Logik-Befehle usw. Daher hat sind schon recht frühzeitig in der Entwicklungsgeschichte der Computer eine Übersetzungstechnik von eher symbolischen Sprachelementen hin zu den OP-Codes der Maschinensprachen entwickelt, die zwar oft einen 1:1-Abbildung war und daher auch sehr intime Kenntnisse des Prozessoraufbaus verlangten, aber bereits Codefragmente zusammenbasteln ließen (assemblieren, Assembler).

Die Übertragung von Programmen zwischen unterschiedlichen Prozessoren war trotzdem nicht gegeben und so entwickelte man im Laufe Zeit (1950-1980) eine Vielzahl an sogenannten Hochsprachen (FORTRAN, COBOL, ALGOL, BASIC ...), die mittels eines sogenannten Compilers (Übersetzers) dann in einen Assembler des jeweiligen Zielprozessorsystems übersetzt wurden und dann im nächsten Schritt assembliert werden konnten (zum sogenannten Objekt-Code oder Binary). Allerdings setzte dieses Verfahren immer geeignete Compiler voraus sowie eine 'ideale' Prozessorausstattung, denn wenn zu viele Absonderlichkeiten beim Ziel-Prozessor auftreten, kann es sein, dass die Übersetzung fehlschlägt, weil Hardware-technische Voraussetzungen fehlen (z. B. eine Gleitkomma-Recheneinheit). Solange es dann keine Simulation der fehlenden Hardware durch eine geeignetes Programm bzw. eine Programmkomponente gibt, geht die Ausführung schief. Solche Programm-Komponenten werden meist gesammelt in sogenannten Bibliotheken [Libraries]; daher haben auch die Programmkomponenten meist ihren Namen erhalten: math-lib oder floating-point-simulation-lib oder wie auch immer.

Neben dem Verfahren, ein Computer-Hoch-Sprachen-Programm (Source-Programm) per Compiler zu übersetzen - man denke nun an den Ablauf: 1x Übersetzen, Nx Ausführen - gab es auch das Interpreter-Verfahren: jedesmal wird kurz vor dem Ausführen übersetzt. Der Nachteil liegt auf der Hand: es dauert mehr Zeit und der Aufwand ist gegenüber dem Compilieren höher. Allerdings ist die Änderungsfreundlichkeit/Flexibilität enorm hoch. Man kann ad hoc etwas ausprobieren. Und ... man kann die Programme auf jedem Zielprozessorsystem, welches natürlich über einen geeigneten Interpreter verfügen muss, ohne Übersetzung einsetzen. Heutzutage typische Interpreter-Sprachen sind: Shell-Dialekte, Basic, Java, PHP, Perl, Phyton, Pascal ... Typische Compiler-Sprachen sind: C, C++, C# ...

Letztlich ist es immer eine Gesamtbetrachtung, welcher Technik man den Vorzug gibt bzw. welche Technik man auf seinem Computersystem bereits vorfindet. Typisch sind die wichtigsten Softwarekomponenten in einer compilierten Sprache geschrieben (Linux-Kernel, Apache-Webserver, MySQL-Datenbank-Server, aber natürlich müssen auch alle Interpreter irgendwo einmal als Compilat vorliegen, bevor man sie benutzen kann. Liegen sie aber dann in einer für das Zielprozessorsystem geeigneten Form vor (z.B. durch ein geeignetes IPKG eingespielt), dann können alle interpretierbaren Programme sofort eingesetzt werden.

Ich hoffe, dass nun ein wenig deutlicher geworden ist, warum es für unterschiedliche Prozessorfamilien der Disk-Stations unterschiedliche Firmware- und IPKG-Versionen geben muss und warum auf der anderen Seite, manche Shell-Skripte oder PHP-Programme einfach überall auf den DS laufen. Und vielleicht ist auch am Rande deutlich geworden, dass die meisten PCs, die ja bekanntlich mit einem INTEL-Prozessor bzw. einem dazu kompatiblen Prozessor (AMD usw.) ausgestattet sind, diese Problematik nicht ganz betrifft. Ältere Mac-Nutzer können aber schon ein Lied davon singen, dass es Unterschiede zwischen den früheren RISC-Prozessoren und den aktuellen INTEL-Prozessoren gab und gibt. So mancher wird nun sagen, warum gibt es keinen Prozessor-Standard? Viel Geld, Monopole, Patente usw. und mal ganz ehrlich, gäbe es nur einen Standard-Motor in Autos, dann wäre die Formel 1 ganz schön langweilig ;)