beginner_de

Avr-Asm-Tutorial S. 6
2.6 Interpreterkonzept und Assembler
Bei einem Interpreter übersetzt die CPU selbst den menschenverständlichen Code erst in ihr verständliche
Binärworte. Der Interpreter würde die Zeichenfolge "A = A + B" einlesen (neun
Zeichen), würde die Leerzeichen darin herausschälen, die Parameter A und B identifizieren, würde
das "+" in eine Addition übersetzen und letztlich vielleicht das Gleiche ausführen wie die Assemblerformulierung
weiter oben.
Im Unterschied zum Assembler oben, bei der die CPU nach dem Assemblieren sofort ihr Lieblingsfutter,
16-bittige Instruktionsworte, vorgeworfen bekommt, ist die CPU beim Interpreterkonzept
überwiegend erst mit Übersetzungsarbeiten beschäftigt. Da zum Übersetzen vielleicht 20 oder 200
CPU-Schritte erforderlich sind, bevor die eigentliche Arbeit geleistet werden kann, ist ihre Ausführungsgeschwindigkeit
nur als lahm zu bezeichnen.
Was bei schnellen Prozessoren noch verschmerzt werden kann, ist bei zeitkritischen Abläufen prohibitiv:
niemand weiss, was die CPU wann macht und wie lange sie dafür tatsächlich braucht. Die
Vereinfachung, sich nicht mit irgendwelchen Ausführungszeiten befassen zu müssen, bewirkt, dass
der Programmierer sich damit gar nicht befassen kann, weil ihm die nötigen Informationen darüber
auch noch vorenthalten werden.
2.7 Hochsprachenkonzepte und Assembler
Hochsprachen ziehen zwischen die CPU und den Quelltext noch weitere undurchaubare Ebenen
ein. Ein durchgängiges Konzept sind z. B. sogenannte Variablen. Das sind Speicherplätze, die für
eine Zahl, einen Text oder auch nur einen einzigen Wahrheitswert vorbereitet werden und im Quelltext
der Hochsprache für den betreffenden Speicherplatz stehen.
Vergessen Sie für das Erlernen von Assembler zu allererst das ganze Variablenkonzept, es führt Sie
nur an der Nase herum und hält Sie davon ab, das Konzept zu durchblicken. Assembler kennt nur
Bits und Bytes, Variablen sind ihm völlig fremd.
Hochsprachen fordern zum Beispiel, dass Variablen vor ihrer Verwendung zu deklarieren sind, also
z. B. als Byte (8-Bit) oder Double-Word (16-Bit-Wort). Compiler platzieren solche Variablen dann
je nach Geschmack irgendwo in den Speicherraum oder in die im AVR reichlich vorhandenen 32
Register. Ob er den Speicherort, wie der Assemblerprogrammierer, mit Übersicht und Nachdenken
entscheidet, ist von den Kosten für den Compiler abhängig. Der Programmierer kann nur noch versuchen
herauszufinden, wo die Variable denn letztlich steckt. Die Verfügungsgewalt darüber hat er
dem Compiler überlassen.
Die Instruktion "A = A + B" ist jetzt auch noch typgeprüft: ist A ein Zeichen (Char) und B eine Zahl
(1), dann wird die Formulierung so nicht akzeptiert, weil man Zeichencodes angeblich nicht zum
Addieren benutzen kann. Der Schutzeffekt dieses Verbots ist ungefähr Null, aber Hochsprachenprogrammierer
glauben dass sie dadurch vor Unsinn bewahrt werden. In Assembler hindert nichts und
niemand daran, zu einem Byte z. B. sieben dazu zu zählen oder 48 abzuziehen, egal ob es sich bei
dem Inhalt des Bytes um ein Zeichen oder eine Zahl handelt. Was in dem Register R0 drin steht,
entscheidet der Programmierer, nicht der Compiler. Ob eine Operation mit dem Inhalt Sinn macht,
entscheidet der Programmierer und nicht der Compiler. Ob vier Register einen 32-Bit-Wert repräsentieren
oder vier ASCII-Zeichen, ob die in auf- oder absteigender Reihenfolge oder völlig durcheinander
liegen, kann sich der Assemblerprogrammierer auch aussuchen, der Hochsprachenprogrammierer
nicht. Typen gibt es in Assembler nicht, alles besteht aus beliebig vielen Bits und Bytes
an bliebigen Orten im verfügbaren weitläufigen Speicherraum.
Von ähnlichem Effekt sind auch die anderen Regeln, denen sich der Programmierer in Hochsprachen
zu unterwerfen hat. Angeblich ist es sicherer und übersichtlicher, alles in Unterprogrammen zu