GRUNDLAGEN DER PROGRAMMIERUNG

...speziell des AT-PC

Ich beginne mit Logik und Maschinensprache, weil dieser Weg in die Welt des Computers der einzige ist, ihn beherrschen zu lernen. Dabei kann man am besten feststellen, wie lächerlich einfach das Prinzip ist... (Als erste aber bitte die letzten Sätze dieses Textes lesen!)

GATTERLOGIK:

Eine CPU (Central-Processor-Unit) besteht aus Transistoren, die nur in einer einzigen von drei möglichen Grundschaltungen betrieben werden: der Sourceschaltung. Und es spielen nur zwei Zustände von fast beliebig vielen möglichen am Ausgang dieser Schaltung eine Rolle.
Ein Transistor hat drei Anschlüsse. Am einen fliessen die Elektronen rein, am zweiten raus, und der dritte, das Gate (oder die Basis), erlaubt, das Fliessen der Elektronen zu verhindern oder zu ermöglichen.
Damit ist der Transistor ein gesteuerter Widerstand. In Logikschaltungen ist der nur sehr gross oder sehr klein. Was an Zwischenwerten erscheint, wird durch Taktung ausgeblendet und erzeugt nur unerwünschte Wärme.
Weil es nahe liegt, den Transistor mit der bekannteren Funktion eines Wasserhahns zu erklären, muss zunächst gesagt werden, dass dabei nicht die ganze Wahrheit zutage treten kann. Die ganze Wahrheit ist, dass erst ein weiterer Widerstand (bei CMOS ist das ein weiterer, komplementärer Transistor) die Funktion ermöglicht, mit der man logische Schaltungen aufbaut. Die Erklärung geht also besser von einem sogenannten Spannungsteiler aus.

Stellen wir uns vor, dass zwischen dem linken und dem rechten Rand dieses Textes eine Spannung von 5 Volt herrscht. Wir legen zwei Widerstände in Serie an diese Spannung, etwa so:

BINÄRWERTE UND DUALZIFFERN:

Binärwerte müssen von Dualziffern strengstens unterschieden werden. Der Unterschied liegt in der Bedeutung von ein und derselben Anordnung von logischen Werten L und H. Und wenn eine Sache schon nicht für sich selbst spricht, muss man sehr genau sein beim vergeben von Bedeutung.
Oben habe ich zwei 1-stellige Argumente, also zwei logische Werte, die zu gleicher Zeit anliegen, eingeführt, um das NOR zu demonstrieren. Hier will ich verallgemeinern auf beliebige Stellenzahlen.
Der Beliebigkeit sind allerdings praktische Grenzen gesetzt, weil irgendwann vor dreissig Jahren jemand einen Ausdruck mit acht logischen Werten für ausreichend hielt, die Welt der Worte darstellbar zu machen.
Ein Argument bzw. Resultat mit einer einzigen Stelle wurde "Bit" genannt, 8-stellige Argumente bzw. Resultate "Byte". Später kamen vielfache davon hinzu. Diese Festlegung ist aber - dem Einsteiger muss es deutlich gesagt werden! - vollkommen willkürlich. Es gibt sehr wohl Maschinen, die mit 12-stelligen Argumenten umgehen (PIC) oder mehr oder weniger. Nur die Vereinfachung der Herstellung von Digitalbausteinen war der Grund der Regel.

Ein Byte kann nun auf verschiedene Weise Bedeutung erlangen. Ich schreibe mal eins hin, damit ich darauf beziehen kann: HLLLHLLL
In vielen Maschinen hat dieses Byte die Bedeutung von zwei Argumenten HLLL, die auch "Nibble" genannt werden. Mit einem Nibble kann man minimal eine Stelle einer Dezimalzahl codieren (6 Wertkombinationen werden dann als irrelevant verworfen). Deshalb ist dies in jeder Maschine das "Format" von binär codierten Dezimalziffern, abgekürzt "BCD" (Binary coded Decimal). Man kann aber auch in den beiden links stehenden Stellen vier Wertekombinationen verpacken, die in einem 8-stelligen Befehl bedeuten, dass der Speicher adressiert wird... Solche Art, den Stellen Bedeutung zu geben, macht aus einem Byte einen Binärwert. Zu einer Dualziffer wird das Byte dagegen nur bei einer ganz bestimmten Bedeutung der Stellen!

Betrachten wir mal eben die vertrauten Dezimalziffern und stellen fest, dass in jeder Stelle zehn verschiedene Ziffern stehen können. Diese Ziffern sind nicht Zahlen! Sie sind Namen für Zahlen und können beliebig ersetzt werden! Sehen wir ab von römischen Ziffern, weil die Römer zu dämlich für schöne stellen-bewertete Ziffernsysteme waren. Aber nehmen wir doch einfach unsere logischen Werte H und L und machen damit dasselbe wie mit den Ziffern im dezimalen System. Wir legen fest, dass L der 0 entspricht und kleiner als H der 1 entsprechend sein soll, und wir schreiben eine weitere Stelle links davon für den nächst grösseren Wert, wenn die rechts stehenden Stellen "voll" sind.
Während wir also im dezimalen System in einer Stelle die Ziffern von 0 bis 9 setzen, um die Stelle "voll" zu machen, erreichen wir diesen Zustand bei nur zwei Werten schon nach einem Zählschritt von 0 auf 1. Wie im dezimalen System die um eins erhöhte 9 zu einer 1 in einer weiteren, linkeren Stelle führt, ist nun die um einen Zählschritt erhöhte 1 eine 10. Ich schreibe mal die ersten acht Zahlen mit den Ziffern 1 und 0 hin, um es klar zu machen: 000, 001, 010, 011, 100, 101, 110, 111
Nur solche Binärwerte sind Dualziffern! (...und auch nur, wenn sie für den Menschen lesbar hingeschrieben werden. In der Gatterlogik kann die links stehende Stelle durchaus recht stehen! - Tatsächlich ist das der für Programmierer wichtigste Unterschied zwischen Intel-Prozessoren und denen von Motorola)
Ganz analog kommt man mit Oktal"zahlen" und Hexadezimal"zahlen" zurecht, wobei letztere beim Programmieren sehr wichtig sind. Mit einer Hexadezimalziffer kann man nämlich genau ein Nibble darstellen.
Im Oktalziffernsystem kommen je Stelle nur die Ziffern 0 bis 7 vor. Bei Hexadezimalziffern kommen je Stelle 16 verschiedene Ziffern vor - 0 bis 9 und weiter mit A bis F. Eine hexadezimale 10 ist also eine dezimale 16, eine oktale 20 und duale 10000. Und jetzt ist wohl auch klar, warum ich nicht nur Binärwerte von Dualziffern, sondern auch Ziffern von Zahlen unterschieden habe. Denn eben habe ich ein und die selbe Zahl mit vier verschiedenen Ziffernanordnungen geschrieben. Allerdings sind diese Namen von Zahlen, wie wir ja wissen, nicht ganz willkürlich gewählt, sondern stellen etwas dar, was ich hier "Stellen-bewertetes System" nennen will, weil damit die Verwandtschaft mit noch ganz anderen Systemen der Namensgebung ausgedrückt werden kann - und weil solche Stellen-bewerteten Systeme beim Programmieren sehr wichtig sind.

DUALARITHMETIK:

Ansich ist dazu nur zu sagen, dass mit Dualziffern nicht anders als mit Dezimalziffern gerechnet wird. Das gilt insbesondere für die Übertragsverrechnung bei der Addition. Allerdings erlauben Dualziffern Vereinfachungen bei verschiedenen Rechenoperationen, und um die geht es jetzt.
Besondere Bedeutung hat das addieren oder subtrahieren von 1 - weiter unten wird das klar. Das Addieren von 1 nennt man "inkrementieren". Das "dekrementieren" ist das subtrahieren von 1, wird aber tatsächlich als inkrementieren mit "invertieren" von Minuend und Resultat ausgeführt.

Man kann zwar Dualziffern ebenso voneinander subtrahieren wie Dezimalziffern. Das ist aber sehr unpraktisch. Man müsste in eine CPU ein Subtrahierwerk einbauen. Keiner tut das, weil bei Dualziffern etwas sehr einfach geht - das "invertieren".
Invertieren ist eigentlich eine logische Operation, weil sie davon Gebrauch macht, dass je Stelle nur zwei Werte möglich sind. Man kann deshalb ganz eindeutig einen Wert in ein und nur ein Gegenteil verkehren: Aus H wird L und aus L wird H.
Zwar spielt das Invertieren bei Binärwerten auch eine wichtige Rolle. Wichtiger ist aber die Tatsache, dass bei Invertieren einer Dualziffer mit einer bestimmten Zahl von Stellen genau die Zahl erzeugt wird, die man addieren muss, wenn man in allen Stellen eine 1 haben will - bzw. die grösste Zahl mit der gegebenen Stellenanzahl.
Wozu das gut ist?

Wenn ich im dezimalen System von einer 3 eine 7 abziehen will, dann kann ich diese Operation auch vollziehen, indem ich die 3 von 9 abziehe (der grösstmöglichen Dezimalziffer mit einer Stelle), das Resultat um 1 erhöhe, mit der 7 addiere und den Übertrag, nämlich die führende 1 beim Resultat 14 ignoriere bzw. als Minuszeichen nehme.
Diese Vorgehensweise, die im dezimalen System keineswegs zu einer Vereinfachung führt, funktioniert im dualen System bestens, weil das Abziehen der 3 von der 9 hier durch eine Invertierung ersetzt werden kann (3+6=grösste Zahl bei gegebener Stellenzahl) - einer einfachen logischen Operation.

Das Resultat einer Invertierung wird "Einerkomplement" genannt, mit dem man ebenfalls subtrahieren kann. Dabei müssen Minuend und Resultat invertiert werden. Gebräuchlich ist aber die Subtraktion mit "Zweierkomplement", was ein inkrementiertes "Einerkomplement" ist. In diesem Fall muss nur der Subtrahend invertiert werden und die höchste Stelle ist bei negativen Ergebnissen immer 1. Sie muss dann ( und nur dann ) invertiert werden, um auf die Ziffer zu kommen, die die negative Zahl darstellt - mit Minuszeichen.
Ein Beispiel macht das schnell klar:
Wir wollen von 00000100, dem Minuenden, 00001011, den Subtrahenden abziehen...
Durch invertieren des Subtrahenden wird aus 00001011 das Einerkomplement 11110100
Das Einerkomplement des Subtrahenden wird durch inkrementieren zum Zweierkomplement 11110101
Addition dieser Operanden:

BINÄRWERT-LOGIK:

Es müssen sehr streng zwei Arten von logischen Operationen unterschieden werden. Die eine erscheint in der Form "H OR L" , die andere in der Form "Sonne oder Regen". Obgleich letzlich beide Arten der Oderierung mit einer logischen Schaltung resultiert werden, sind es völlig verschiedene Wege, auf denen aus den Argumenten der Oderierung resultiert wird. Zuerst werde ich mit Binärwerten umgehen.
Wie ich oben gezeigt habe, würden NORierung und Invertierung genügen, um alle logischen Bedürfnisse zu stillen. Man muss das im Hinterkopf haben, wenn man kompliziertere Zusammenhänge logeln will.
Der normale Bedarf ist aber mit AND, OR, XOR und Invertierung erfüllt, und deshalb sind diese Bool'schen Operatoren in den meisten CPUs festverdrahtet verfügbar. Es werden dabei zwei Binärwerte immer in den jeweils entsprechenden Stellen verknüpft - Stelle 1 des einen Operanden mit der Stelle 1 des anderen usw....
Argumente sind also (wie oben) Bits, die je nach Stellenzahl einen Operanden bilden, z.B. ein Byte (Operand ist lateinisch "der zu behandelnde", Operator "der Behandler"). Der 'normale' Bedarf ist das "setzen"("set") oder "rücksetzen"("reset") und das "vergleichen" ("compare") von Bits. Dabei wird von "setzen" gesprochen, wenn eine Stelle den logischen Wert H annehmen soll, und rückgesetzt wird sie dann zu L ( L setzt man also nicht!). Will man in einem Binärwert z.B. in der 3.Stelle H setzen, dann verknüpft man diesen Binärwert mit einem anderen, der das H nur in seiner 3.Stelle enthält. Diesen anderen Binärwert nennt man "Maske" ("mask").Die Operation 'Binärwert OR Maske' resultiert dann in der 3.Stelle H, in allen anderen Stellen erscheinen nur dann die Werte H, wenn sie im maskierten Binärwert enthalten waren.
Rücksetzen kann man dieses H in der 3.Stelle, indem man dieselbe Maske invertiert und Maske und Binärwert mit AND verknüpft.
Weil diese Art zu rechnen sehr wichtig ist bei der Erzeugung von "Steuerworten" oder Erfassung von "Statusworten", will ich das Beispiel noch sinnfälliger hinschreiben:

CPU UND OPCODE:

Es gibt nur zwei weitere Begriffe, die ich zum Verständnis einer CPU geben muss. Der erste ist der Begriff "Adresse".
Ich erweitere die Schaltung des oben gezeigten NOR um weitere Eingänge und vereinfache das Bild, indem ich für einen Transistor nur "Inverter" schreibe. Dabei sei das Gate am Wortanfang, dem "I" und das Drain am Wortende. Alle Wortenden sollen kurzgeschlossen sein und an einem Widerstand liegen:

ADRESSIERUNG UNG ADRESSBEREICHE:

Ich habe bis jetzt vor allem die Adressen abgehandelt, die in einer CPU und der ALU zu finden sind, und die das sind, wo ein Programm seine Bedeutung erhält, "ausgeführt" wird. Dabei habe ich gezeigt, welch überragende Bedeutung Adressgeber haben.
Ich habe schon angedeutet, dass neben dem Programmzähler weitere Adressgeber mit der gleichen Schaltung verknüpft sind, die ab einer Adresse gelesenen Binärwerte als Opcode zu interpretieren. Dieser Opcode besteht zwar auch aus einer Anzahl von Adressen, adressiert damit aber offenbar in einem anderen Bereich als der Programmzähler!
Ich werde nun unterschiedliche Adressierungsarten abhandeln und die Unterschiede zwischen Adressierungen, die dadurch zustande kommen, dass sie bestimmte Bereiche betreffen. Den Ausdruck Adress-"Raum" werde ich dabei nicht verwenden. Er ist zwar beliebt, aber völlig daneben, weil Adressen nur eine einzige in Bits gequantelte Dimension haben, die Bytes oder vielfache davon betreffen. Es gibt insbesondere keine räumliche Nähe oder Ferne - auch "weite" Sprünge führen nur zum nächsten Kommando und im nächsten Zyklus!

Wir haben festgestellt, dass mit einer Adresse stets der Wert im adressierten Register verfügbar wird. Was aber ist Lesen in einem Computer?
Tatsächlich wird der adressierte Wert nicht aus dem Register entfernt !
Er wird lediglich kopiert, undzwar unter einer weiteren Adresse, die zu gleicher Zeit anliegen muss. Es gibt also stets ein schreibendes und ein lesendes Register und als Resultat eine Übereinstimmung der Binärwerte in beiden Registern. Der Ausgang des Schreibers wird beim lesen mit dem Eingang des Lesers kurz geschlossen (verbunden) und ausserdem muss das lesende Register mit einer Steuerleitung von "speichern" auf "lesen" umgeschaltet werden.
Diese Steuerleitung ist ein Teil der Adressierung (R/W-Bit) und kann unterschiedlich mit der Ablaufsteuerung für den CPU-cycle verknüpft sein.
Nach diesem Vorgang, den auch ich im weiteren einen "Transfer" oder eine "Zuweisung" nennen werde, sind deshalb zwar nach wie vor zwei Adressen aber nur ein Wert unter beiden vorhanden!

Weil die ausdrückliche Programmierung von Leser und Schreiber längeren Opcode, mehr Zeit zur Ausführung und mehr Leitungen für Adressen erfordert, sind bei der Konstruktion von Computern weniger aus logischen als aus wirtschaftlichen Gründen gewisse Adressen festgelegt worden, die ohne besondere Anweisung, also "implizit" verfügbar sind - die wichtigste ist die im Programmzähler. Ein anderer Weg wurde gewählt für den Transfer zwischen Registern, die nur Werte speichern.
Ich habe bereits erwähnt, dass in einem Computer eine Anzahl von Registern vorhanden ist, wo Opcode zur Ausführung bereit gespeichert ist. Ich nenne die zugehörige Anzahl von Adressen im weiteren den "Programmbereich". In den meisten Computern ist dieser Bereich in dem gleichen Adressbereich wie der "Datenbereich" angesiedelt. In dieser "von Neumann Struktur" gibt es nur zwei Busse (Menge von Leitungen für ein Datenwort) für Daten oder Programmcode einerseits und Adressen andererseits. Beide Busse sind einerseits mit Anschlüssen an der CPU, andererseits mit Anschlüssen an Speicherbausteinen verbunden. Diese Speicherbausteine werde ich im weiteren den "Arbeitsspeicher" nennen.
Weil es für den Arbeitspeicher nur einen Adressbus gibt, können Schreiber und Leser nicht zu gleicher Zeit adressiert werden. Eine zweite Adresse kann aber ein Register in der CPU adressieren. Deshalb geht jeder Transfer im Arbeitsspeicher grundsätzlich durch die CPU ! Der Opcode kann kurz ausfallen, weil die Adressen in der CPU meist mit 1-3 Byte für Operation, Schreiber und Leser vollständig definiert werden können und nur für Festwerte und Adressen im Arbeitsspeicher bis zu 72 Bit angefügt werden müssen.

Der Arbeitsspeicher zerfällt grundsätzlich in zwei Teile, weil eine gewisse Menge Opcode sofort nach dem Einschalten durch die CPU adressierbar sein muss. Für diesen Programmcode hat sich der Name "BIOS" (="Basic In Out System") eingebürgert.
Hier ist zunächst wichtig, dass es nicht nur diesen Teilbereich gibt, sondern auch je nach Konstruktion weitere Teilbereiche, die mehr oder weniger unveränderbar sind und durch ihre erste Adresse, die Basis-Adresse gekennzeichnet sind. Alle Teilbereiche werden jedoch über den gleichen Adressbus adressiert!
Wir bleiben aber zunächst beim wichtigsten Teilbereich im Arbeitsspeicher, dem BIOS. Damit es beim Ausschalten nicht verloren geht, ist es "eingebrannt". Dieser Ausdruck kommt von der ursprünglich verwendeten Art der Register, mit denen dieser Teilbereich technisch realisiert wurde. Man konnte die Bits durch Aufschmelzen von Leitungen auf dem Chip, also gezielte Kurzschlüsse, tatsächlich einbrennen. Heute wird weniger rabiat ein Häufchen Ladung in die gewünschte Ecke verschoben, wo sie H oder L bedeutet (EEPROM). Das BIOS beginnt mit einem ersten Opcode auf einer bestimmten Adresse, die ebenfalls nach dem Einschalten sofort vorhanden ist. Manchmal ist es die kleinste, also =0, oft aber (und jedenfalls im AT-PC) die grösste auf dem Adressbus darstellbare. Allerdings sind im AT-PC zunächst weniger Adress-Bits als möglich verfügbar.
Wir sehen also schon mal ein Programm vor uns, das im wesentlichen nicht verzichtbar ist und bereits die CPU beschäftigt hat, bevor auch nur ein weiteres Programm ausgeführt werden kann. Und weil es auf einer bestimmten Adresse beginnt, steht auch jeder Opcode und jede Konstante für irgendwelche Vorbesetzungen auf einer ganz bestimmten Adresse. Wer solch ein Programm schreibt, kann also jedem Opcode, der nach einem Sprung ausgeführt werden soll, eine Adresse zuordnen, die als Teil des Sprungbefehls auf den Adressbus gelegt wird. Ganz offenbar funktioniert das aber nicht mehr, wenn dieses Programm auf einer beliebigen anderen Adresse beginnt!
Wir müssen also feststellen, dass Programme nur mit einer immer gleichen Anfangsadresse gestartet werden können.

Wir können uns zwar ausmalen, ein BIOS zu programmieren, das alle gewünschten Zustände im Computer herstellt. Aber als diese Idee noch verlockend war, war der Adressbereich im Arbeitsspeicher so beschränkt, dass sie nicht realisiert werden konnte. Das eine Programm für alles musste allein deshalb schon in Teile zerlegt werden. Da diese Teile keineswegs alle gleich gross gemacht werden können, hat man auf jeden Fall besondere Anfangsadressen zu verwenden, deren Herleitung und Verwaltung ein besonderes Ding sind. Erst weiter unten werde ich es abhandeln, weil erst in einem anderen Zusammenhang klar gemacht werden kann, dass man diese Aufgabe nicht nur verschieden, sondern auch so lösen kann, dass der Bedarf an Speicherplatz immer die technischen Gegebenheiten übertreffen kann.
Zunächst stelle ich Adressierungsweisen und Adressbereiche vor, die den Umgang mit immer grösser werdenden Wertemengen ohne besondere Neuerungen möglich machen.
Dabei spielt ein Register am Adressbus eine zentrale Rolle, das ich im weiteren das "Index-Register" nenne. Weil einige Varianten möglich, nötig oder auch nur sinnvoll sind, bleibe ich bei diesem Ausdruck auch dann, wenn andere Ausdrücke üblich sind.
Eine Form des Indexregisters habe ich bereits vorgestellt für den Fall einer Verzweigung in Programmen. Diese Form enthält eine Definition aller Adressbits, die aus einem Opcode dorthin kopiert wurden. Damit kann ein mit flags bedingter Sprung gemacht werden, der natürlich auch ohne Beachtung von flags als unbedingter Sprung getan werden kann. Das wäre dann keine Verzweigung mehr, sondern die Fortsetzung des Programmes mit einem anderen Adressinkrement als dem in den Programmzähler eingebauten. So eine Möglichkeit ist unverzichtbar, weil ein Adressbereich nur eine Dimension hat, folglich die "Äste" einer Verzweigung Abschnitte eines Stammes (,um im Bild zu bleiben...)sind. Irgendwann muss man vom Ast springen und kann nicht geradeaus weitermachen, weil dort z.B. der gerade verschmähte andere "Ast" beginnt.
Auch beim Prozeduraufruf wird die im Opcode enthalte Sprungzieladresse über ein Indexregister auf den Adressbus gelegt. Für den besonderen Rücksprung kann ein weiteres besonderes Indexregister die Rücksprungadresse speichern, die aus der Adresse des Opcodes für den Prozeduraufruf abgeleitet wird, undzwar während der Ausführung von der CPU. Ganz allgemein wird jedoch zur Speicherung der Rücksprungadressen von Prozeduren ein Teilbereich im Arbeitsspeicher verwendet, den man "stack" (=Stapel) nennt. Während bei der zuerst abgehandelten Verwendung des Indexregisters die Adresse aus dem Opcode gelesen wurde, wird die Sache eine völlig andere, wenn die Adresse auch aus dem Datenbereich gelesen werden kann!
Dabei gilt es wieder zu unterscheiden, ob die Indexadresse (=Adresse im Index-Register) mit einem besonderen Prozedur-Rücksprung vom Stack gelesen wird oder aus einem anderen Teilbereich des Arbeitsspeichers.
Die zweite Variante ist der "indizierte" Sprung bzw. Prozeduraufruf. Dann dient eine beliebige andere Speicheradresse als Behälter der Adresse, auf die gesprungen werden soll. Solche unter bestimmter Adresse liegenden Adressen können während des Programm- Ablaufes umdefiniert werden. Unten betrachte ich das genauer... Eine sehr wichtige dritte Variante ist ein Interrupt, der ähnlich wie ein indizierter Prozeduraufruf abläuft, aber bedingt ist durch den Zustand am IRQ-Eingang der CPU (Interrupt ReQuest). Allerdings kann diesen Eingang auch die CPU selbst erregen, wenn ein bestimmter Opcode im Programm ist.
Wesentlich ist, dass beim Interrupt-Aufruf die Adressierung von einer Interrupt-Nummer abgeleitet wird, die meist auf dem Datenbus liegen muss, während der IRQ-Pin erregt wird. Diese Nummer wird durch Schieben multipliziert zum Offset, der zu einer Basis-Adresse addiert die Sprungziel-Adresse des "Interrupt handlers" adressiert. Dies ist eine Prozedur, die oft mit einer besonderen Rücksprunganweisung beendet werden muss. Die Tabelle mit den Sprungzieladressen ist ein nicht immer verschieblicher Teilbereich im Arbeitsspeicher. Man spricht dann auch von "Interrupt-Vektoren".

Völlig analog kann man Tansfers zwischen Daten-Registern sowohl mit Adresse im Opcode, wie mit Adresse in einem Index-Register veranstalten.
Ganz allgemein spricht man dann von "indizierter" Adressierung, wenn ein Index-Register die Adresse an den Adressbus legt, in das die Adresse aus dem Datenbereich geschrieben wurde. Im Gegensatz dazu spricht man von "direkter" Adressierung, wenn die Adresse aus dem Opcode stammt - auch wenn sie tatsächlich ebenfalls mittels einem Index-Register an den Adressbus gelangt.
Schliesslich ist noch möglich, nur einen Teil der Adresse aus dem Opcode zu entnehmen oder dort keine auf den Programmanfang bezogene "absolute" sondern auf die Adresse des Opcodes bezogene relative Adresse zu verwerten. Im zweiten Fall ist ein Addierwerk Teil des Indexregisters, das auch einfach zur Verwertung negativer, relativer Adressen aufgerüstet werden kann.
Solch ein Addierwerk kann schliesslich noch so erweitert werden, dass es die Werte in mehreren Registern der CPU mit einer relativen Adresse im Opcode kombiniert.

Ein Index-Register ist also unverzichtbar, wenn man einen Prozeduraufruf veranstalten will - auch wenn der Ablauf völlig äquivalent mit Opcodes für Sprünge vollzogen werden kann, ist die Speicherung einer Rücksprungadresse im Datenbereich unverzichtbar, wenn man innerhalb einer Prozedur noch eine weitere rufen will. Solche Schachtelungen erwiesen sich schon sehr früh als Zauberei, mit der man grosse Programme sehr klein kriegen konnte. Nachdem diese Zauberkraft entdeckt worden war, suchte man noch mehr Zauberkraft mit ausgewachsenen Indexrechnern. Sie sind heute in jeder CPU mit 32-stelligem Adressbus vorhanden.

Eine bestimmte Variante eines Indexrechners war allerdings schon sehr früh nötig. Es war der Moment, als entdeckt wurde, dass man eine Möglichkeit brauchte, ein Programm an einer beliebigen Adresse im Arbeitsspeicher starten zu können.
Wie ich am Beispiel des BIOS erklärt habe, muss ein Programm an einer bestimmten Adresse beginnen, auf die im weiteren alle Adressangaben im Opcode bezogen werden können. Andernfalls führt schon der erste Sprung aus dem gewünschten Zustand heraus.
Wie aber soll das gehen, wenn ich ein Programm mal auf Adresse =0 und mal auf einer anderen Adresse beginnen lassen will?
Die Lösung ist sehr einfach und innerhalb der CPU lösbar:
Statt Adressen aus dem Programm unverändert in das Indexregister zu schreiben, muss jede Adresse dort noch mit einer Basis-Adresse (der Start-Adresse des Programms) addiert werden, bevor der Wert an den Adressbus gelangt.
Dann allerdings entsteht eine weitere Aufgabe, die in dem Programm gelöst werden muss, das das neue Programm startet, indem dorthin gesprungen wird. Das startende Programm muss die Basis-Adresse des neuen Programms in den Index-Rechner als Addend schreiben. Mit der gleichen Adresse kann dann auch indiziert gesprungen werden. Dann adressiert der Programmzähler im neuen Programm. Die Adressen, die im Programm stehen, sind nun nicht mehr die tatsächlich absoluten im Arbeitsspeicher, sondern nur noch ein Teil des Binärwertes, der auf dem Adressbus liegt. Letzterer wird die "wahre" oder auch "physikalische", besser aber "physische" Adresse genannt. Bei den Adressen im Programm spricht man dann auch von "Offset-Adressen", während "relative Adressen" auf irgendeine Offsetadresse bezogen sind.

Auch wenn die technische Ausführung eines solchen Indexrechners je nach Hersteller einer CPU verschieden ausgefallen ist - um die Notwendigkeit einer solchen Einheit kam keiner herum ! In jeder CPU mit 32-stelligem Adressbus ist ein Rechenwerk dieser Art vorhanden. Und oft wird nicht nur mit einer Basis-Adresse gearbeitet. Im AT-PC und im protected mode beispielsweise wird mit der Descriptor-Tabellen-Basis-Adresse+Selector (beides in besonderen CPU-Registern gespeichert) ein 64-stelliger Descriptor adressiert, in dem die absolute Basis-Adresse steckt (neben anderem), zu der wiederum die Offsetadresse im Programm addiert wird.
So abwegig das hier erscheint - so raffiniert erlaubt diese unten genauer beschriebene Adressierung der Basis-Adressen, ein Programm beliebig im Speicher zu verschieben und dennoch alle aktuell gebildeten Bezüge in anderen Programmen unverändert zu lassen, weil diese Bezüge über die im Selector enthaltene Offsetadresse entstehen.
Das Konzept der Deskriptoren, die mit dem protected mode eingeführt wurden, wurde sehr pfiffig gleich noch insofern erweitert, als die damit adressierten Adressbereiche dort auch mit ihrer Länge und ihrem Zweck definiert werden müssen. Insbesondere gibt es einen Unterschied zwischen Programm- und Daten-speicher (im ansich gleichen Adressbereich). Damit darf dieser Modus tatsächlich "protected" (=geschützt) genannt werden. Ein Betriebssystem kann zuverlässig verhindern, dass Programmsegmente an irgendwelche Daten vergeben werden! Allerdings haben alle(!) bekannten Betriebssysteme Hintertüren, über die automatisch etwas zum Programm werden und dann als "Virus" erscheinen kann.
Da solche Hintertüren jedenfalls zusätzlichen Programmcode im Betriebssystem kosten, kann kein vernünftiger Zweifel bestehen, dass Viren gewollt sind - für ein Geschäft mit Anti-Virus-Programmen, mindestens aber für die Ausspähung argloser Computernutzer.

Die Notwendigkeit für solchen Aufwand bei Adressen ergibt sich dann, wenn nicht nur verschiedene Programme mit verschiedenen Basis-Adressen im Arbeitsspeicher liegen sollen, sondern auch zusammen wirken sollen, als wären sie ein Programm. Dann muss nämlich aus dem einen Programm mit einem Opcode in ein anderes gesprungen werden können, der keine Adresse für das Sprungziel enthalten kann! Denn zu der Zeit, zu der das Programm geschrieben wurde, war nicht bekannt, dass das Sprungziel nun auf Adresse soundso steht. Das scheinbar unlösbare Problem, die richtige Sprungziel-Adresse in das Programm zu bringen, kann verschieden gelöst werden (was zu unvereinbaren Welten im Bereich der Betriebssysteme und Programmiersprachen geführt hat). Die Lösung ist im wesentlichen aber sehr einfach: Ein Betriebssystem lädt nicht nur die Programme A,B,C in den Speicher, sondern speichert für sie erreichbar auf einer wohl bekannten Adresse die Basis-Adressen aller drei Programme zusammen mit je einem Namen, damit jedes Programm über den zur Programmierzeit bekannten Namen die aktuelle Basis-Adresse der jeweils beiden anderen Programme finden kann.
Natürlich gibt es noch eine Reihe weiterer Probleme bei dieser Art von Zusammenarbeit. Die resultieren aber nicht aus der Adressierung und werden deshalb woanders abgehandelt.

Aber nicht nur im Programmbereich ist solche Adressarithmetik nötig. Gerade im Datenbereich sind Basis-Adressen von Tabellen allgegenwärtig. Man kann mit beliebig vielen gleichartigen Tabellen umgehen, dabei aber nur eine Programmsequenz benutzen, in der mittels indizierter Adressierung auf die jeweils aktuelle Tabelle zugegriffen wird. Ein einziger Transfer einer neuen Basis-Adresse führt dann zum Tausch der ganzen Tabelle. Das ist z.B. nötig, wenn das Schriftbild auf dem Bildschirm oder dem Drucker getauscht werden soll.

Nachdem einigermassen klar ist, was an Adressierungsarten möglich und nötig ist, will ich nun die zum Teil schon erwähnten Adressbereiche behandeln. Schon gesagt ist, dass ein Teilbereich des Arbeitsspeichers notwendig ein BIOS speichern muss. Die Basis-Adresse dieses Bereiches ist durch die Konstruktion festgelegt und nicht zu ändern. Ein anderer meistens durch die Konstruktion fixierter Teilbereich ist der "Bildwiederholspeicher", aus dem ein Video-Controller die Binärwerte für die Pixel auf dem Bildschirm liest. Ein dritter, nicht notwendig fixierter Teilbereich ist die Interrupt-Vektor-Tabelle.
Immer verschieblich sind der stack, Programm- und Datenbereiche. Ausserdem können diese Bereiche mehrfach vorkommen. Sie werden vom BIOS erstmals definiert, aber meistens von einem Betriebssystem umdefiniert.
Ebenfalls verschieblich und stark abhängig von Betriebssystemen und den damit eingestellten Zuständen sind verschiedene Tabellen für die Einteilung des Arbeitsspeichers. Im AT-PC sind dies die GDT (Global Descriptor Table) und falls der page mode eingeschaltet wurde, die damit notwendig gewordenen page-Tabellen. Weitere Bereiche, die wie heilige Bezirke unantastbar sein können, sind nicht mehr in der Logik des Computers begründete Einteilungen, die hier erst mal nicht interessieren. Sinnvoll ist nur eine Aufteilung des Arbeitsspeichers in Bereiche für Programmcode einerseits und Daten andererseits, wie ich sie oben schon am Beispiel des protected mode vorgestellt habe.

Ich will aber noch den Teilbereich stack genauer erklären, der in jeder Maschine vorkommt und für den in jeder CPU auch besondere Opcodes zur Verfügung stehen. Wie schon erwähnt ist der Stack jener Bereich, in dem die Rücksprungadressen nach Prozeduraufrufen gespeichert werden. Dieser Zweck hat auch zu der besonderen Gestaltung eines Adressgebers geführt, der "stackpointer" genannt wird. Die Adresse in diesem Register wird implizit inkrementiert oder dekrementiert, wenn ein Transfer in diesen Bereich mit speziellen Opcodes angewiesen wird. Ein Prozeduraufruf enthält wiederum implizit einen solchen Opcode, ist also schon ein kleines Programmstück.
Das wesentliche am Stack wird durch seinen Namen bestens ausgedrückt (deutsch:Stapel). Wie bei einem Stapel Papier wächst der Stapel durch Auflegen eines Blattes und schrumpft mit der Entnahme eines Blattes, wobei der stackpointer stets das zuoberst liegende Blatt adressiert. Der Vorteil dieser Adressierung ist, dass Prozeduraufrufe beliebig verschachtelt sein können. Immer liegt die richtige Rücksprungadresse zuoberst.
Als Speicherplatz noch knapp war, bürgerte sich ausserdem ein, auch andere vorübergehend gebrauchte Binärwerte dort abzulegen - oft mehr als sinnvoll ist. Der Nachteil ist nämlich das möglicherweise unkalkulierbare Wachsen des Stapels mit sehr fatalen Folgen. Für Stapel dieser Art ist auch der Ausdruck "LIFO" üblich (="Last In First Out" also etwa: Der Letzte wird der erste sein...). Im Gegensatz dazu werden z.B. Warteschlangen nach dem Prinzip FIFO (="First In First Out") abgehandelt.

Ein wichtiger Adress-Bereich, der in vielen Computern Teilbereich des Arbeitsspeichers ist, ist der I/O-Bereich, wo jene Geräte mit einer CPU verbunden sind, die für den Laien den Computer charakterisieren: Tastatur, Bildschirm, Maus, Drucker, Festplatte und vieles, von dessen Existenz der Laie nichts ahnt, das aber unverzichtbar ist - z.B.eine Stoppuhr. Im AT-PC ist der I/O-Bereich dagegen ein besonderer Bereich mit eigenem Adress- und Daten-Bus und für diesen Bereich speziellen Opcodes.
Seit Einführung des PCI-Busses sind aber die Geräte, die bis dahin praktisch direkt mit dem I/O-Bus der CPU verbunden waren, nun ebenfalls über Teilbereiche des Arbeitsspeichers adressierbar (was erhebliche Vorteile hat - insbesondere bei Videokarten).
Hier soll nur erwähnt werden, dass beim Transfer im I/O-Bereich meist auch zeitliche Dimensionen im Programm behandelt werden müssen, wobei der dabei nötige Timer-Controller selbst im I/O-Bereich liegt. Ausser dem richtigen Timing sind auch völlig asynchrone Zustände zu berücksichtigen, die nur über Interrupts abhandelbar sind, die der ebenfalls im I/O-Bereich liegende Interrupt-Controller für die CPU erfassbar macht.
Neben solchen Bezügen zwischen verschiedenen Geräten spielen jede Menge Opcodes, Statuswerte und besondere Steuer-Bits der Controller die tragende Rolle. Es sind nämlich Controller und nicht wirklich die Geräte, mit denen die CPU im I/O-Bereich verkehrt. Und die haben ihre eigene Logik und ihre eigenen Adressbereiche.

COMPUTER UND BETRIEBSSYSTEM

Nach dem Einschalten eines Computers wird durch eine besondere Logikschaltung ("Reset") ein Sprung in den sicheren, eingebrannten Bereich des BIOS erzwungen. Der Zufall hat gewaltet, und der darf keine Konsequenzen in einer programmierbaren Maschine haben!
Nicht nur der Programmzähler muss ausdrücklich mit der ersten Adresse geladen werden. Nicht nur der erste Opcode muss ein bestimmter sein (meistens ein indizierter Sprung). Auch viele andere Werte wie die flags, die R/W-Bits und auch gewisse Register müssen ausdrücklich einen bestimmten Start-Wert bekommen.
In modernen Computern müssen durchaus so viele Transistoren allein für den Reset eingesetzt werden, wie früher eine ausgewachsene 8-Bit-CPU enthielt. Es ist aber nur ein einziges Bit, mit dem dieser Zustand in der CPU hergestellt wird: der oben erwähnte NMI. Weil aber jeder Controller und auch die Spannungsversorgung Reset-Eingänge haben, muss ein separater Reset-Controller alles in die Reihe bringen. Vieles geht dabei noch durch die Lappen und muss nach dem Reset mittels Programm abgehandelt werden. Wichtigste Aufgabe danach ist die Prüfung des Arbeitsspeichers, ohne den ja nichts geht.
Ein ausgeschalteter Computer befindet sich also in einem Dornröschenschlaf, aus dem er nur liebevoll heraus geführt werden darf.

So wie nach dem ersten Augenaufschlag Dornröschens zwar die ersten Dinge wie Herzschlag und Atmung noch selbstverständlich sind, alles weitere aber immer verschiedener weiter gehen kann (Prinz stinkt aus dem Maul...), so ist das Wirken des BIOS nur der Beginn einer Initialisierung, die sehr verschieden gemacht werden kann, schliesslich aber in eine "unendliche" Schleife mündet - im AT-PC normalerweise und mindestens eine ständig wiederholte Tastaturabfrage.
Es ist der I/O-Bereich und die immer wieder neue Anpassung an Controller und ihre Eigenarten, die schon sehr früh in der Entwicklung der Computer dazu führte, dass man das Booten in zwei Teile stückelte, die getrennt entwickelt und optimiert werden können:
1.) "BIOS"
2.) "OS", die Abkürzung für "Operating System" (Betriebssystem)
Die Grenze zwischen den Aufgabenbereichen dieser Systeme ist eigentlich beliebig. Es gibt aber einen wichtigen praktischen Grund für Stückelung und Grenzziehung: den Speicherbedarf. Das BIOS liegt im Arbeitsspeicher und sollte deshalb möglichst wenig Platz verbrauchen für Opcode, der im wesentlichen nur nach dem Einschalten dort liegen muss. Das OS aber liegt auf Plattenspeichern oder Disketten, wo der Speicherplatz wesentlich billiger ist.
Schliesslich erlaubt die Tauschbarkeit des Betriebssystems den Prinzen an Dornröschens Geschmack und an den des Benutzers der Beziehung anzupassen. Märchenhafte Träume sind nämlich schnell vergessen, wenn man mit einem Coumputer bestimmte Aufgaben erledigen will...

Nach einigen Kontrollen, die bei jedem Reset stets von neuem sein müssen, macht das BIOS schliesslich vor allem mal eins - es startet zunächst Floppydrive, Festplatte oder neuerdings auch CDROM oder USB und liest aus dem ersten Sektor Binärwerte, die es in den Speicher schreibt und als Programm startet, indem ein Sprungbefehl dorthin ausgeführt wird. Dieses Stückchen Programm nennt man den "Bootsector". Er besteht im AT-PC aus 512 Byte. Beginnend mit dem Bootsector wird das Betriebssystem transferiert und schliesslich angesprungen. Diesen Teil der Intialisierung eines Computers nennt man "Boot(en)", abgeleitet vom englischen Ausdruck für "Der Lotse geht an Bord". So kommt man vom Allgemeinen zum Besonderen.

Ursprünglich war die Aufgabe eines Betriebssystems nur der Umgang mit magnetischen Speichermedien. Deshalb hatten diese Betriebssysteme immer die drei Buchstaben DOS ("Disk Operating System") im Namen. Dort muss eine Ordung geschaffen werden, die erlaubt, gespeicherte Daten verschiedener Menge auch wiederzufinden - als "Dateien" in einem "Dateisystem". Dateisysteme sind im wesentlichen die Verknüpfung einer Sektoradressierung zu Namen von Dateien. Das ist die Lösung eines Problems, das sich bei der Speicherung von Daten immer dann stellt, wenn sie ihre Bedeutung behalten sollen, obwohl sie unter beliebiger Adresse liegen. Dann nämlich kann die Adresse nicht mehr die Bedeutung repräsentieren. Oft erscheint solche Namensgebung als Vorteil, weil sie dem Menschen verständlicher ist. Logisch betrachtet muss man sie vermeiden, weil die Suche nach einem Namen in einer Liste wesentlich umständlicher ist als eindeutige Adressbezüge zu Elementen gleichen Umfangs! Weil aber Dateien im Laufe ihres Lebens an- und abschwellen oder erlöschen und damit wieder verfügbaren Speicherplatz freigeben können, sind eindeutige Adressbezüge nicht wie im Arbeitsspeicher möglich.

Eine weitere ursprüngliche Aufgabe eines Betriebssystems ist die Verwaltung des Arbeitsspeichers und das Starten von "Anwendungen", also den Programmen, mit denen der Benutzer eines Computers umgeht, wenn er schreibt, Fotos bearbeitet oder Klänge. Weil auch diese Programme im Prinzip unkalkulierbaren Umfang bei beliebigen Anfangsadressen haben können, sind auch bei dieser Aufgabe Namen notwendig. Insbesondere dann, wenn ein Programm mit bestimmten anderen Programmen zu einer funktionellen Einheit verknüpft werden soll. Die Art und Verwaltung solcher Verknüpfungen ("linking") und die Bereitstellung zigfach gebrauchter Programmteile macht schliesslich die Eigenart eines Betriebssystems aus. Es diktiert mit einem Linker, wie im Prinzip immer gleiche notwendige Teile des Systems verknüpft werden müssen, um brauchbar zu sein.

Mit einem Betriebssystem wird jedenfalls entschieden, wie Treiber gerufen werden müssen, wie der Speicher für Programme und Daten aufgeteilt wird, wo unverzichtbare Konstanten und Variable gespeichert werden, wo der stack liegt, wie mit dem stackpointer umgegangen werden darf (manchmal garnicht) und vieles mehr, was zunächst nicht betrachtet werden soll. Solche Entscheidungen, die immer auch Einschränkungen sind, müssen jedenfalls gefallen sein und manche können beim besten Willen nicht aufgehoben werden!
Ein Programmierer hat sich deshalb nicht nur mit den logischen Gegebenheiten in CPU und Controllern zu befassen, sondern auch mit den Eigenarten des Betriebssystems, unter dem sein Programm laufen soll. Dabei spielt natürlich eine grosse Rolle, ob man solche Eigenarten gut dokumentiert und frei verfügbar erhält, oder ob man womöglich noch viel Geld zahlen muss für Geheimwissen. Selbst wenn ein Betriebssystem umsonst zu haben ist und der Programmcode für jedermann lesbar gemacht wurde, kann alles so unüberschaubar sein, dass auch Geheimniskrämerei Programme nicht geheimnisvoller machen könnte! Weil Betriebssysteme ihre jeweils eigene und der Willkür von Programmierern folgende Logik haben, gehe ich hier nur insoweit darauf ein, als die weiter unter vorgestellte Programmiersprache C/C++ eine bestimmte Art von Betriebssystem voraussetzt. Hier geht es jedenfalls um Programmieren und nicht Programme.
Es muss aber gesagt werden, dass viele Dinge, die ich in folgenden Absätzen anspreche, gerade in den am häufigsten genutzten Betriebssystemen garnicht programmierbar sind bzw. nur über verschlungene Pfade aus einem Programm heraus regierbar sind.

PROGRAMMIERSPRACHEN UND PROGRAMME:

Zunächst mal ist ja klar, dass der Umgang mit der CPU nur gepflegt werden kann, wenn man sie mit der richtigen Anordnung von Opcodes füttert. Wegen einst knappem Speicherplatz war aber auch klar, dass diese Opcodes verschiedene Anzahlen von Stellen enthalten mussten, wenn man nicht unzählige Stellen verschwenden wollte. Dann aber kann aus der Stellung eines Opcodes in einem Programm nicht mehr auf die Adresse des Opcodes im Programm geschlossen werden, bevor nicht alles bis zu diesem Kommando übersetzt wurde. Damit wurde die Festlegung von Adressen in diesen Opcodes zum grossen Problem. Wenn man nämlich eine Adresse in einen Opcode einfügen muss, die noch garnicht bekannt sein kann, weil sie erst später im Programm feststeht, dann kann nur mit Namen adressiert werden, die schliesslich gegen Adressen getauscht werden.
Damit ist also auch klar, dass das Erzeugen von Programmen äusserst schwierig wird, wenn man nicht nur die Bedeutungen von Stellen in Binärwerten zu bedenken hat, sondern auch noch neben dem Programm selbst Tabellen fortschreiben muss, die einem erlauben, Adressen in Opcodes einzufügen, wenn man sie denn endlich kennt...

Sehr früh in der Entwicklung des Computers zum allgegenwärtigen Ding stand deshalb fest, dass das Schreiben von Programmen in zwei Schritten zu erfolgen hat, zwischen denen ein ganz besonderes Programm steht. Es hatte mindestens den Zweck zu erfüllen, Adressierungen mit Namen ausdrückbar zu machen. Weil aber damit ohnehin das Erkennen von Buchstabenfolgen erledigt sein musste, konnten auch die Bitbedeutungen mit Buchstabenkürzeln ausdrückbar gemacht werden. Damit war der erste Schritt zu einer höheren Programmiersprache getan, in der mittels Buchstaben programmiert wird, die nicht wie Ziffern die Bitbedeutungen in den Opcodes repräsentieren, sondern erst durch ein Übersetzungsprogramm zu Opcodes werden.

Diese ersten Schritte gingen jedoch nicht so weit, dass die Abfolge der Opcodes in irgendwelche neuen Formen gegossen wurde. Man schuf Kürzel für Operationen ("mnemonic") und erlaubte Namen für Operanden und eine Rechtschreibung, in der solche Elemente in einem "Quelltext" (="sourcecode") auftreten durften.
Ganz allgemein nennt man solche Sprachen und Übersetzungsprogramme "Assembler".
Damit kann man Adressen zwar noch mit einer Ziffer definieren, muss (und kann) aber alle Adressen, die während der Programmerzeugung noch nicht bekannt sein können, mit einem Namen definieren. Diese Namen werden "label" genannt.
Neben der Namensgebung für Adressen wurden auch Kommentare ermöglicht, die das Übersetzungsprogramm ignoriert, und Vereinfachungen für die resevierten Kürzel der Opcodes eingeführt - z.B. ein "mov"-Kommando für verschiedene Opcodes in der Intel-CPU...
In einem Assemblerprogramm werden jedenfalls alle Opcodes 1:1 in Buchstaben abgebildet und insbesondere ist die Abfolge der Kürzel exakt die gleiche wie die der Opcodes. Deshalb wird Assembler auch allgemein nicht als "höhere" Programmiersprache bezeichnet.

Mit der Prozedur habe ich eine höhere Einheit eines Programms vorgestellt, die zwar noch eine Entsprechung in der Logik der Maschine hat (wegen der automatischen Benutzung des Stapels), die aber im Gegensatz zu Opcodes eine offene Stellenzahl hat. Tatsächlich ist damit also über die Bedeutung der einzelnen Opcodes eine gestülpt worden, deren Adressierung nicht feststeht wie die der Register in der CPU, aber ähnlich wie ein Addierwerk hinter Registern eine ganz bestimmte Funktion hat. Weil ein in einer Prozedur enthaltener Ablauf aber wie ein Kommando an prinzipiell beliebigen Stellen eingefügt werden kann, kann mit Prozeduren sozusagen die Zahl der möglichen Kommandos in einer Maschine beliebig erweitert werden. Dennoch ist ein Prozedurruf nichts weiter als eine Variante eines Sprunges!
Aber die Prozedur erlaubte Namen für ganze Abläufe und war damit nicht nur geeignet für ihren eigentlichen Zweck, den Speicherbedarf zu minimieren, sondern auch den Aufwand zum Schreiben von Programmen. Für viele Rechenarten gab es ursprünglich keine Kommandos in Form einzelner Opcodes. Um eine Multiplikation anzuweisen, hatte man deshalb viele Zeilen Assembler zu schreiben. Die Idee, solche Abläufe nicht nur in Prozeduren zu packen, sondern die Aufrufe zu Quasikommandos an das Übersetzungsprogramm zu machen, das diese Abläufe dann aus Dateien extrahierte und automatisch in Quelltexte oder Binary einfügte, lag nahe. Das war der erste Schritt zu "höheren" Programmiersprachen, in denen deshalb der Prozedurbegriff eine wichtige Rolle spielt.

Ohne weitere scharfe Grenzen geht schliesslich die kleine Einheit Prozedur in die grosse eines Programms über, das meistens mehr als eine Prozedur enthält. Ein Programm von einer Prozedur zu unterscheiden, macht nur Sinn, wenn man (wie üblich) unter einem Programm die Menge Code versteht, die als "Übersetzungseinheit" von einem Übersetzungsprogramm übersetzt wird. Damit sind vor allem mal die Namen in ihrer Bedeutung für den Opcode beschränkt. Der gleiche Name in verschiedenen Programmen kann sehr verschiedene Bedeutungen haben. Aber auch diese Grenze ist verwaschen, wie ich unten noch genauer darstellen werde. Ich will deshalb gleich sagen: Jede weitere Unterscheidung von Mengen von Opcodes hat nichts mehr mit der Logik der CPU zu tun, sondern Zwecken des Opcodes oder auch besonderen Strukturen in Betriebssystemen.

Ursprünglich war ein wichtiger Zweck, die Programmstücke, die die Bedienung der Controller behandelten, als unabhängige Teile handhaben zu können. Sie wurden "Treiber" (="driver") genannt und ihre Verfügbarkeit für ein bestimmtes Gerät konnte den Verkauf enorm steigern. Einst war nämlich sehr komplizierter Code nötig, weil die Controller kaum eigene Logik enthielten und infolgedessen die gesamte Steuerung von der CPU erledigt werden musste. Mittlerweile sind nicht nur Controller einfacher anzusteuern. Auch der Arbeitsspeicher ist grösser geworden und höhere Rechenarten inclusive trigonometrischer Funktionen sind zu Opcodes geworden. Treiber sind als BIOS eingebrannt und mit einer Interruptanforderung verfügbar. Damit sind die ursprünglichen Zwecke für "höhere" Programmiersprachen eigentlich verschwunden.
Es gibt allerdings einen wichtigen Zweck, der eine "höhere" Programmiersprache als Assembler nötig macht. Mittlerweile sind nämlich Computer auch nicht mehr überschaubar in Büros miteinander vernetzt, sondern über das Telephonnetz weltweit. Damit sind die Möglichkeiten für Angriffe auf einzelne Maschinen enorm gewachsen.
Da aber der Empfang von Anweisungen nicht ausgeschlossen werden darf, weil nur der Sender wissen kann, wie die gesendeten Daten zur sinnvollen Botschaft werden können, ist eine Programmiersprache nötig, die dem Empfänger dennoch die vollständige Kontrolle über die Interpretation gibt.
Eine solche Programmiersprache baut darauf auf, dass man mit Prozeduren Kommandos geben kann, deren Wirkung gegenüber Opcode eingeschränkt ist. Man kann also mit Prozedurnamen eine Zielmaschine programmierbar machen, die tatsächlich nicht die Empfängermaschine ist, sondern eine Untermenge der dort vorhandenen Möglichkeiten.
Programmiersprachen, deren Befehlsvorrat vollständig aus Prozedurnamen besteht, nennt man "Interpretersprachen". Damit kann man zuverlässig die Fernsteuerung von Maschinen auf der Empfängerseite beschränken. Das "HTML", mit dem ich die Darstellung dieses Textes für den Leser programmiert habe, ist das derzeit prominenteste Beispiel einer Interpretersprache. Programmcode, wie ihn ein "Computervirus" darstellt, kann also nur dann die gefürchtete Wirkung entfalten, wenn der Empfänger (bzw.sein Betriebssystem) das erlaubt!

Zum Begriff "Programm" ist schliesslich zu sagen, dass ein Computer keineswegs einen Sinn dafür hat, was ein Benutzer für nützlich und deshalb für ein Programm hält. Wie oben schon gezeigt, ist ein Computer die denkbar dümmste Maschine. Beinahe jeder Binärwert bedeutet ihr was, was blindlings exekutiert wird, wenn es vom Programmzähler adressiert wird.
Wie bedeutsam diese Form des Begriffes ist, merkt ein Programmierer als erstes, wenn er sein selbst geschriebenes Programm mal startet. Dann nämlich macht er Bekanntschaft mit der Natur der Sache:
Die Zahl der möglichen Programme ist ungeheuer viel grösser als die Zahl der nützlichen! Dass das menschliche Hirn überhaupt imstande ist, die paar Stecknadeln im unermesslichen Heuhaufen zu finden, muss einen wundern. Und das nützliche unterscheidet sich vom Schrott oft nur durch ein nicht fehlendes kleines "h", ein "e" statt einem "f" usw...
Aber ich gehe erst am Ende dieses Textes auf das ein, was tatsächlich der Alltag beim Programmieren ist: die Fehlersuche.
Erst mal also, wie man Fehler überhaupt mal machen kann...

ASSEMBLER:

Diese Programmiersprache ist die einzige, die gestattet, wirklich jede Eigenheit einer CPU und angeschlossener Controller zu programmieren.
Weil aber bereits vorgestellte grosse Unterschiede zwischen verschiedenen CPUs und Controllern bestehen, sind folgerichtig dem jeweils besonderen "Befehlssatz" jeweils besondere Assembler zugeordnet, weil die ja den Opcode 1:1 abbilden.
Wie ebenfalls schon gesagt, führt kein Eigensinn daran vorbei, dass kein Programm mehr enthält als Kommandos für Transfers von Binärwerten! - Aber natürlich mit sehr verschiedenen Konsequenzen...
Die Unterschiede liegen also im einzig verbleibenden Teil der Angelegenheit, den besonderen Adressen und Adressierungsarten, womit neben CPU und FPU auch solche Dinge wie "cache" (=schneller Zwischenspeicher) und besondere Teilbereiche des Arbeitsspeichers wie GDT oder page-tables gemeint sind.
In Motorola-CPUs kommen sehr viel mehr Adressierungsarten und Register vor als in einer Intel-CPU. Letztere dagegen kennt einen Adressbereich, die I/O-Adressen, der in anderen CPUs nicht vorhanden ist.
Immer aber gibt es I/O-Adressen, die in der Intel-Welt über einen eigenen Adressbus, in der Motorola-Welt aber über den Adressbus des Arbeitsspeichers gegeben werden.
Weitere Unterschiede sind durch die Breite der Datenbusse gegeben, weshalb man oft dies Merkmal zur Klassifizierung einer CPU verwendet ("8-Bitter"). Ansich ist das Unsinn, weil man sehr wohl einen 8-stelligen Bus zwischen 32-stelligen Registern haben kann - oder Adressen für 8-stellige Register bei einem 32-stelligen Datenbus, wie im AT-PC seit Einführung der CPU i486 von Intel.

Die Vorführung solcher Unterschiede könnte noch viele weitere Seiten füllen. Ich werde sie aber abbrechen, weil ich auf wesentliches hinaus will.
Assemblerkommandos haben immer die gleiche Gestalt. Sie bestehen aus einem Kürzel (="Mnemonik"), das die Operation definiert, und keinem oder mehr Operanden, die Register adressieren oder Festwerte definieren. Und man kann ausserdem feststellen:
-> Für alle CPUs gibt es ein Kommando namens "mov" oder ähnlich für das Wort "move".
Das bedeutet den Transfer von Daten.
-> Für alle CPUs gibt es ein Kommando namens "jmp" für das Wort "jump".
Das bedeutet einen Sprung.
-> Immer gibt es auch ein Kommando namens "call" oder ähnlich für den Ausdruck "call procedure".
-> Es gibt immer Kommandos für logische und arithmetische Operationen der ALU. Sie sind ebenfalls Kürzel (die der Leser selbst enträtseln kann): "add","sub", "mul", "nor", "neg", "and"....
-> Immer gibt es Kürzel für die Register der CPU, die als Zwischenspeicher für Operanden dienen, oder solche, wo ihre flags, der Status und die Konfiguration von Maschinenzuständen stehen. Hier unterscheiden sich die Befehlssätze aber am meisten.
Die Bedeutung von speziellen Kommandos für Operationen, die diese Register betreffen, ist nur durch die Bauweise einer CPU begründet. Im Zusammenhang mit dem nur bei den Intel-CPUs für den AT-PC vorhandenen "protected mode" beispielsweise gibt es gleich eine ganze Rasselbande von Kommandos sowie spezielle Registerkürzel und Bitbedeutungen in Registern.

Auch die Art der Operanden ist nicht beliebig. Es gibt bei Transfers eine Quelle und ein Ziel, bei Sprüngen ein Ziel, bei arithmetischen oder logischen Operationen ein oder zwei (selten drei) Operanden. Diese Argumente eines Kommandos folgen dem Mnemonik, das die Operation definiert.
Man muss also, um ein Assemblerprogramm zu schreiben, eigentlich nur die Kommandos "mov", "jmp" und "call" und die paar Varianten für verschiedene Adressierungsarten oder Kriterien für bedingte Sprünge im Kopf haben! Dazu kommen ein paar arithmetische und logische Operationen. Alles andere braucht man fast nie. Man kann es nachlesen. Es genügt die Ahnung, dass da noch was zu haben ist...
Man muss wissen, wie man ein Label schreibt und insbesondere, womit man Kommentar von Kommandos trennen kann. Ein Assemblerprogramm enthält dann also Zeilen wie folgende:

PROGRAMMIEREN MIT NASM-ASSEMBLER:

Auch über die Ausdrucksweise in einem Assemblerprogramm konnte keine Einigkeit erzielt werden! Es gibt mindestens ein halbes Dutzend Dialekte und zwei Normungsversuche allein für die Programmierung des AT-PC.
Ich muss also endgültig die allgemeine Betrachtung hinter mir lassen und abhandeln, was tatsächlich nur im AT-PC von Bedeutung ist und wie das in einem bestimmten Assemblerdialekt geschrieben wird.
Ich werde den NASM-Assembler-Dialekt vorstellen und damit in die Assemblerprogrammierung einführen. Diese Schreibweise ist der am ähnlichsten, die von Intel eingeführt wurde und auch in der Fachliteratur gebräuchlich ist. Der NASM-Assembler ist im Internet frei erhältlich und kommt mit sehr guter Dokumentation, auf die ich zur Ergänzung verweise.
Davon ausgehend werde ich in weiteren Kapiteln den GNU-Assembler-Dialekt beschreiben, mit dem der inline-Assembler für C/C++ unter Linux formuliert wird - wenn ich in C/C++ eingeführt habe. Erst dann kann man nämlich verstehen, warum da so eigenartig anders formuliert werden muss. In einer anderen Datei stelle ich einen von mir entwickelten Assembler-Dialekt vor, der wohl nicht mehr zu vereinfachen ist. Der ist aber nur unter dem von mir geschriebenen Betriebssystem ASMOS benutzbar, das im NASM-Dialekt geschrieben wurde.

Ich werde nicht den kompletten Befehlssatz der CPUs in einem AT-PC vorstellen. Er besteht aus rund 300 Kürzeln, die alle sehr gut beschrieben in der Dokumentation zu NASM aufgeführt werden. Wer ins Detail der Assemblierung eindringen will, ist mit den Quellprogrammen meiner in NASM geschriebenen Assembler ASMn bzw. ASMat bestens bedient, wo ausserdem im Kommentar auch die abgehandelten Kommandos vollständig beschrieben werden (auch deutsch).
Ich werde hier also nur die Kommandos vorstellen, die 90% aller Programme ausmachen. Das sind nämlich nur zwei Dutzend. Vor allem aber will ich die Anwendung von Adressierungsarten und elementare Abläufe vorstellen, die immer in jedem Programm enthalten sind und deshalb zum Gegenstand neuer Ausdrücke in "höheren" Programmiersprachen wurden.

Ein Kommando kann im NASM-Dialekt entweder auf ein Label folgen oder muss als erstes links in einer Zeile stehen. Die Mnemoniks bestehen meistens aus drei Buchstaben. Darauf folgt ein Zwischenraum, dem abhängig vom Mnemonik Operandendefinitionen folgen, die durch Kommata
voneinander getrennt werden.
Das wichtigste Mnemonik überhaupt ist "mov", mit dem ein Kommando so aussieht:
mov Ziel,Quelle ; ...gefolgt evtl. von Kommentar, der in NASM stets mit einem Semikolon eingeleitet werden muss!
"mov" weist den Transfer eines Binärwertes an, muss also Adressen von Schreiber und Leser enthalten, wobei mindestens einer von beiden ein Register in der CPU sein muss - das Kommando darf also höchstens eine Adresse im Arbeitsspeicher enthalten!
Während die Registeradressen innerhalb der CPU unveränderliche Namen haben (eax,ebx,ecx,edx...), sind Adressen im Arbeitsspeicher mit "effektiver" Adresse zu definieren, einer Ausdrucksweise, die ich zunächst für den Fall vorstelle, dass die Adresse innerhalb des Programms liegt und beliebig benamt als "Label" im Programm definiert wird.
Namen von Labeln können in NASM entweder mit abschliessendem Doppelpunkt oder ohne geschrieben werden. Nach einem Zwischenraum folgt ein Opcode oder eine von drei Längendefinitionen, mit denen tatsächlich alles gemacht werden kann, weil es im AT-PC bei Speicherzugriffen nur die nach 8-, 16- oder 32-stelligen Werten gibt.

PROGRAMMSEQUENZEN:

Ich komme nun zu den aus mehreren Kommandos bestehenden Abläufen, die in verschiedenen Abwandlungen in jedem Programm vorkommen. Dabei benutze ich Begriffe, die man sich nicht unbedingt merken muss, weil sich die Eigenarten eines Ablaufes in einem Assemblerprogramm immer auch aus den Kommandos direkt ableiten lassen. Dann muss man sich zunächst kaum mehr merken als das, was ich oben schon aufschrieb.
In "höheren" Programmiersprachen allerdings werden all diese Begriffe zu reservierten Ausdrücken und sind mit einem zwingenden Regelwerk für die Schreibweise verbunden. Weil beeindruckende Formulierungskünste vorspiegeln, dass es sich jeweils um ganz neues, nur durch Verwendung einer gewissen Sprache überhaupt mögliches handle, will ich ausdrücklich gesagt haben:
"Höhere" Programmiersprachen erlauben stets nur eine Untermenge dessen zu programmieren, was in Assembler ausgedrückt werden kann!

Ich beginne mit dem Begriff der Prozedur, die nur insofern was besonderes ist, als der in ihr enthaltene Ablauf zwischen verschiedenen Teilen eines Programms eingeschoben werden kann, ohne abgeändert werden zu müssen. Denn das, was sich zwischen Prozedurruf und Rückkehr abspielt, spielt sich ja exakt zwischen zwei Kommandos ab.
Sinnvollerweise entscheidet man sich für die Definition einer Prozedur nur dann, wenn man beim Programmieren feststellt, dass man sich wiederholen muss. Das praktische Vorgehen besteht dann darin, den nochmal gebrauchten Ablauf im Quelltext woanders anzuordnen, mit Einsprunglabel zu versehen und "ret"-Kommando abzuschliessen. Und natürlich muss dann an die ursprüngliche Stelle dieses Ablaufes im Quelltext ein Prozeduraufruf gesetzt werden. Man wird das dann noch ein bisschen zurecht stutzen müssen, braucht eventuell einen anderen Anlauf für andere Ansprünge über ein darüber liegendes weiteres label, oder muss in einem der Abläufe, wo die Prozedur gerufen werden soll evtl. Register anders benutzen...lauter Kleinigkeiten, die am Zweck orientiert sind, und die keineswegs mit Systemphilosophien geregelt werden müssen.
Natürlich gibt es häufig gebrauchte Abläufe, die man als solche schon erkennt, bevor man sie geschrieben hat, z.B.Zugriffe im Dateisystem.
Das aber ist der Ausnahmefall und kein Grund für eine Globalisierung von Prozeduren, wie sie in "höheren" Programmiersprachen vorkommt!

Schliesslich kann ein Ablauf, der als Prozedur ausgegliedert wird, auch ohne "call" und "ret" genau gleich oder sogar brauchbarer arbeiten. Es kann nämlich die Situation gegeben sein, dass innerhalb der Prozedur Fehlerzustände möglich sind, die die Rückkehr zum "Rufer" zur schlechtesten Wahl machen. Es kann aber auch andere Gründe geben, vielfach gebrauchte Abläufe nicht zu einem Rufer "zurück" kehren zu lassen, sondern je nach Rufer zu verschiedenen weiteren Abläufen. Dies wird mit indizierten Sprüngen erzielt, die ich oben bereits angesprochen habe. Statt mit dem "call"-Kommando eine Rückkehradresse auf dem stack abzulegen, kann man auch mehr als eine Rückkehradresse in Variablen schreiben, die in der nun nicht gerufenen, sondern angesprungenen Sequenz fallweise als "Rückkehr"-Adressen in einem indizierten Sprung verwendet werden. Ein Assembler-Programmierer hat aber meistens mehr als eine Möglichkeit zur Lösung eines Problems! Er kann nämlich auch innerhalb der Prozedur den Stapel inkrementieren (+4 !), damit die Rücksprungadresse tilgen (ein "ret" ohne Sprung tun...), und dann mit einem Sprung direkt z.B. zur geigneten Fehlerabhandlung springen. Er kann schliesslich mitten aus seiner Prozedur raus und in eine andere Prozedur rein und mit deren "ret"-Kommando zum Rufer zurückkehren - weil kein "call" zum Einsprung in die zweite Prozedur benutzt wurde, steht tatsächlich die originale Rücksprungadresse bereit!
All diese raffinierten Sprünge sind in "höheren" Programmiersprachen nicht möglich. Insbesondere ist der Umgang mit dem Stack nicht möglich.

Der in vielen "höheren" Programmiersprachen erlaubte "rekursive" Ruf einer Prozedur ist in Assembler natürlich ebenfalls zu machen, indem die Einganswerte stets über einen Stapel definiert werden, der wachsen kann.
Aber tatsächlich ist diese Form der Rekursion reichlich dumm, weil man sie nämlich ohne viel Trara auf dem Stack schneller in einer Schleife macht - in der natürlich auch ein Stapel für verschiedene Rekursionsebenen benutzt werden muss. Dann aber kann ein Schleifenzähler die Zahl der Rekursionen kontrollieren, und die "Rückkehr" von der letzten Rekursion muss nicht eine Kette von Rücksprüngen durch die Ebenen sein, sondern kann ein einfacher Sprung sein!

Nur bedingt sind auch eine besondere Art von Prozeduren formulierbar, die im Gegensatz zu dem eben beschriebenen, am besten intuitiv entwickelten Typ, sehr wohl überlegt sein müssen:
Interrupt-Behandler
Diese Prozeduren unterscheiden sich auf den ersten Blick nur durch das Rückkehrkommando "iret" statt "ret" bzw. "retf" von den anderen Prozeduren, werden aber vor allem mal auf eine völlig andere Weise gerufen. In einem Programm dürfen sie auf keinen Fall mittels "call"-Kommando gerufen werden!
Oben habe ich schon angesprochen, dass es die Möglichkeit gibt (und geben muss), den normalen Ablauf eines Programmes zu unterbrechen, undzwar immer dann, wenn zeitlich nicht kalkulierbare Ereignisse, die aber im Programm verwertet werden sollen, synchronisiert werden sollen. Das passiert meistens in einer Warteschleife, in der auf ein solches Ereignis gewartet wird, das z.B. eine Betätigung der Tastatur ist.
Das hier wichtige Detail ist allerdings, dass die Einsprungadresse (der "Interrupt vector") auf einem besonderen Stapel liegen muss. Im protected mode heisst dieser Stapel "Interrupt Descriptor Table" (=IDT) und enthält ebenfalls 64-stellige Deskriptoren, die allerdings völlig anders aufgebaut sind als die Deskriptoren, die in der GDT erlaubt sind. Insbesondere enthalten diese Interrupt-Deskriptoren (mehrere Typen gibt es) eine vollständige Adresse des Labels eines Interrupt-Behandlers, undzwar als 48-stellige Zeiger ("pointer") definiert.
Die Deskriptoren, und damit die Pointer in der IDT werden statt mit einem Selektor mit einer 8-stelligen (=1Byte) Interruptnummer adressiert, die zu einer Basisadresse im Register "idtr" addiert wird, nachdem sie um drei Stellen links geschoben und damit mit 8 multipliziert wurde. Hier ist zunächst nicht weiter interessant, dass praktisch alle Geräte, die über einen Controller an den AT-PC angeschlossen sind, sowie CPU und FPU mindestens einen Interruptgeber enthalten und folglich nur regierbar sind, wenn ein Interrupt-Behandler geschrieben wurde. Diese Interrupt-Behandler sind nämlich normalerweise schon Teil des Betriebssystems.
Es gibt aber ausser diesen "hardware interrupts" auch "software interrupts", die durch das "int"-Kommando betätigt werden. Dieses Kommando, gefolgt von der Interruptnummer, entspricht also dem "call"-Kommando, wobei allerdings alle Register auf den Stack gerettet werden und eben deshalb nur mit dem besonderen Rückkehrkommando "iret" wieder zurück geschrieben werden.

"int"-Kommandos sind eigentlich Blödsinn, aber je nach Betriebssystem dann unverzichtbar, wenn dies keine Chance lässt, in der IDT herum zu schreiben, also auch das Schreiben von Interrupt-Behandlern verbietet. Alle gängigen Betriebssysteme sind dieser Art und stellen dann mindestens einen "Betriebssysteminterrupt" zur Verfügung, über den mittels Funktionsnummern Zubringerdienste geordert werden können, z.B. den Code einer gedrückten Taste zu geben.
Manchem mag angenehm sein, sich nicht um oftmals komplizierte Controller kümmern zu müssen - Anderen ist das garnicht angenehm, weil erstens ein Betriebssysteminterrupt enorm Zeit frisst und man zweitens dem ausgeliefert ist, was einer in den Interrupt-Behandler reingeschrieben hat. Das ist oft nicht die beste Lösung und manchmal absolut untauglich.
Ausserdem ist nur ein Betriebssysteminterrupt vorhanden, über den viele Dienste natürlich nur mit vielen Funktionsnummern geordert werden können, die wiederum eine zeitraubende Selektion nötig machen.
Will man eigene Interrupt-Behandlung, muss man mindestens ein Betriebssystem haben, das man selber umschreiben kann, das also als Quelltext zu haben ist.

Die eben angesprochenen 48-stelligen Zeiger sind Adressen, die immer aus einer 32-stelligen Offsetadresse in den Stellen 0-31 und einem 16-stelligen Selektor in den Stellen 32-47 bestehen. Sie liegen mit dem untersten Byte auf niederster Adresse im Speicher und können dort mit einem besonderen Kommando direkt in die CPU transferiert werden:
lds eax,[pointer]
... schreibt die unteren vier Byte ab Adresse von "pointer" an eax, während die darüber stehenden zwei Byte an das Segmentregister ds geschrieben werden. Als Ziel der Offsetadresse kann jedes beliebige Register dienen, als Ziel der Selektorbytes ausser cs jedes beliebige andere, indem dessen Name mit Präfix "l" versehen zum Mnemonik wird: lds, les, lfs, lgs, lss
Diese Zeiger werden immer zur Adressierung benutzt, wenn in einem fernen Segment adressiert werden muss und infolgedessen auch Selektoren definiert werden müssen.
Ein Beispiel für einen Ruf über Segmentgrenzen hinweg mit Adresse der Sprungzieladresse auf absoluter Adresse:

PROGRAMMIEREN MIT GNU-C/C++ :

Weil Viele, die gerne Computer programmieren wollten, mit der Logik, die diese Maschinen kennzeichnet, haderten, wurde fleissig daran gearbeitet, sie nicht mit ihrer in Assembler 1:1 übersetzten Sprache, sondern über neue Ausdrucksweisen ansprechbar zu machen - ganz so wie Hundebesitzer auch lieber nicht bellen, sondern "Platz!" oder "Fass!" rufen wollen.
Und natürlich wollte keiner dieser Vielen sein Unverständnis eingestehen, sondern edle Zwecke vortragen für sein Bemühen, Computer zu dressieren...
Es gibt deshalb angeblich insgesamt rund 1000 Programmiersprachen - ich habe nicht nachgezählt. Sie alle können aber nicht mehr ausdrückbar und programmierbar machen, als das, was der Opcode einer Zielmaschine ausdrückbar und programmierbar macht, und was infolgedessen 1:1 in Assembler programmierbar ist.
Das darf man nicht vergessen, während man das folgende liest!
Neben in der Frühzeit durchaus vorhandenen vernünftigen Zwecken für Ergänzungen des Assemblers, die ich oben bereits ansprach, gab es aber bald auch andere Gründe.
Es stellte sich heraus, dass viel Geld mit neuen Programmiersprachen gemacht werden konnte - es konnten sogar Weltfirmen darauf gegründet werden!
Das darf man auch nicht vergessen, während man das folgende liest!

Auch für die Dressur des AT-PC gibt es nicht nur mehrere "höhere" Programmiersprachen, es gibt insbesondere bei C/C++ noch mindestens ein halbes Dutzend Dialekte, die nur bedingt kompatibel sind. Das Übersetzungsprogramm, der "Compiler", für den einen Dialekt verarbeitet den anderen nicht. Man muss allerdings den GNU-Compiler "g++/gcc" ausnehmen, wo Optionen für verschiedene Dialekte vorhanden sind. Man kann auch einige Ausdrücke mehr als in der standardisierten Form verwenden, aber die werden nicht mehr von anderen Compilern akzeptiert werden.
Ausgangspunkt dieser Sprach-Entwicklung waren 1970 erste Schritte in der Firma AT&T Bell Laboratories zu einem universellen Betriebssystem, das UNIX genannt wurde. Aber erst durch die Absicht, UNIX auf DEC-Rechnern zu implementieren, wurde aus der wesentlich von Dennis M.Ritchie aus B entwickelten Sprache C der erste Haufen Funktionen, die zunächst benutzt wurden, UNIX für die Zielmaschine PDP-11 zu programmieren.
Seit 1983 bemüht sich ein ANSI-Normungsgremium um eine C-Sprachdefinition, die ausdrücklich "maschinenunabhängig" sein sollte. Damit ist gemeint:
-> Weniger Buchstaben für Mnemoniks und ihre Verallgemeinerung.
-> Erübrigung des "Umwegs" über CPU-Register beim Transfer von Werten.
-> Statt vieler Namen für Label eine formelartige Ausdrucksweise mit Klammern und Klammerebenen.
-> Formulierungen mathematischer Operationen in der aus der Schule gewohnten Form.
-> Ausgrenzung von CPU-spezifischen Methoden der Adressierung zugunsten allgemeiner.
-> Ausgrenzung von Controller-spezifischen Methoden des Zugriffs auf Daten.
Solche Abstraktionen sollten erlauben, Programme auf beliebigen Zielmaschinen laufen zu lassen, ohne sie umschreiben zu müssen. Den Umgang mit Eigenarten einer Maschine auf ein angepasstes Betriebssystem und den Compiler zu verschieben, gelang aber bis heute nicht, wie man an der Unzahl von Optionen leicht feststellen kann, die die Bedienungsanleitung (="manpage") des GNU-Compilers auflistet. Ein Programmierer hat also sowohl die Zielmaschine, als auch das Ziel-Betriebssystem mit dem darunter verfügbaren Dialekt zu berücksichtigen!

Mit Verallgemeinerungen wird zwar eine Zielmaschine Mensch fertig, weil der aufgrund von Erfahrungen Einzelheiten rekonstruieren kann, nicht aber eine Zielmaschine CPU und auch dann nicht, wenn ein Compiler die menschliche Erfahrung einbringen soll, die dann nämlich nur eine Suche nach dem kleinsten gemeinsamen Nenner sein kann.
Tatsächlich sind die ursprünglichen Vorstellungen Zug um Zug in einem langwierigen Normungsprozess erodiert worden bis hin zum "inline-Assembler", der mittlerweile gemäss Normierung Teil eines C-Compilers zu sein hat, dessen Dialekt aber nicht normiert ist! Dennoch fällt den meisten schwer, wahr zu haben, dass damit der Ansatz der Entwicklung "höherer" Programmiersprachen ad absurdum ist.
Immerhin wird nicht mehr nur die Unabhängigkeit von der Maschine, sondern auch die Nähe zu ihr als erstrebenswert und erreicht gefeiert.
Weil aber tatsächlich das eine nur auf Kosten des anderen gehen kann, ist C/C++ auch höchstens den Maschinen "näher" als andere "höhere" Programmierssprachen, nicht aber "maschinennah". Als Beispiel für "maschinenfern" soll "PASCAL" erwähnt sein, wo man überhaupt nur auf niedrigere Adressen springen konnte. Ein besser nicht namentlich genannter Professor aus Zürich war nicht imstande, seinem PASCAL-Compiler eine Label-Adress-Zuweisung einzubauen, die die Mühe wert gewesen wäre. Allerdings wurde auch diese Programmiersprache bald nach der Einführung um einen inline-Assembler ergänzt.

Die Maschinennähe von C/C++ geht jedenfalls nicht allzu weit und bedeutet für den AT-PC, dass der page mode eingeschaltet werden muss, weil in C keinerlei Möglichkeiten für den Umgang mit Selektoren vorhanden sind. Der page mode arbeitet Prinzip bedingt mit mindestens drei zusätzlichen Arbeitsspeicherzugriffen bei jedem einzelnen Arbeitsspeicherzugriff, der andernfalls nur einen zusätzlichen Zugriff auf die GDT erfordert. Dadurch wird die Ausführungsgeschwindigkeit jedes Programms auf weniger als die Hälfte reduziert!
Es muss aber auch ein UNIX-artiges Betriebssystem vorhanden sein, weil in C/C++ auf Abstraktionen bezogen wird, die UNIX kennzeichnen. Das gilt insbesondere für die Verwertung von Flags und die Behandlung von Daten-, Datei- und I/O-Transfer.
Deshalb muss ich einige Sätze zu UNIX machen, das zum Stammvater aller Betriebssysteme geworden ist.
UNIX basierte zunächst auf Abstraktionen, die angesichts wirklich niedlicher Maschinen entstanden. 1970 hatte der Computer im Pentagon nicht mal die Arbeitsspeichergrösse, die heute jeder PC-Benutzer zur Verfügung hat. Angesichts der damals verfügbaren Geräte für Ein- und Ausgabe konnte man auch die Hoffnung haben, das Wirken von Controllern hinter der Abstraktion von "device" und die Eigenart von Datenmengen hinter der Abstraktion von "files" verschwinden lassen zu können, die flüssig werden in "streams" und sich dann in "channels" bewegen - kurz: mit einigen wenigen Funktionen wie printf(....), fread(....) usw. alles regierbar zu machen.
Tatsächlich sind solche Abstraktionen ebenso sinnfällig wie daneben. Schon die Abläufe beim Schreiben der immer gleichen Datei auf verschiedene Magnetmedien wie Band, Diskette oder Festplatte sind sehr verschieden. Ein Benutzer möchte zwar den gleichen Effekt, wenn er eine Datei abspeichert, aber ein Programmierer hat sich konkret mit den Gegebenheiten und eben nicht mit Ähnlichkeiten zu befassen. Deshalb ist auch in C trotz eines immer gleichen Funktionsrufes namens fread(...) stets über das, was zwischen den Klammern steht, genau zu definieren, welches Gerät Ziel oder Quelle eines Transfers ist. Das ist kein bisschen abgekürzter als ein aequivalenter Ruf in einem Assemblerprogramm! Während dort aber eine bezifferte Adresse den Unterschied macht, muss in "höheren" Programmiersprachen in den Namensbereich ausgewichen werden.
Die notwendige Folge sind immer neue Namen für Dinge, die keinen Namen brauchen, und die maschinell mit Namen schwieriger als ohne Namen, aber mit Adresse zu finden sind.

"Höhere" Programmiersprachen sind grundsätzlich dadurch gekennzeichnet, dass Namen als Abstraktion nicht nur für Adressen in Quellprogrammen (Label) zugelassen sind, sondern verschwenderisch an alles und jedes vergeben werden, das irgendwie unterscheidbar sein sollte - und das ist sehr viel. Viel mehr, als sich die Abstrahierer der ersten Stunde denken konnten! Und leider kann die Namensschöpfung auch noch Gewinn bringend betrieben werden.
Während also in Assembler längst alles ausdrückbar ist, ringen Hochsprachler immer noch um Worte...

Das führt zu ewigen Listen und langwieriger Zeichenkettenerkennung als Grundlage von Abläufen, die ohne weiteres auch mit Adressen und Bit-Tests vollzogen werden könnten. Erst moderne AT-PCs verdecken mit ihrer enormen Geschwindigkeit die enorme Verschwendung von Speicherplatz und Laufzeit solcher Philosophie.
Ein sofort erfahrbarer Effekt aber ist, dass man ein Programm überhaupt nur verstehen kann, wenn man alle standardisierten Bezeichnungen kennt und sie nicht als Label verkennt.
Ausserdem gibt es Bibliotheken von Standardfunktionen, die ebenfalls reservierte Namen haben. Allein die Auflistung der Namen mit kürzest möglicher Nennung der Funktion füllt mindestens 200 Buchseiten. Wer unbedingt auf der Höhe der Entwicklung sein will, muss unter den Namen der Normungsgremien im Internet stöbern:
"ANSI X3J16" oder auch "ISO WG21"
Die Standardfunktionen sind allerdings nur ein Bruchteil der Funktionen, die in zahlreichen anderen Bibliotheken schlummern. Die werden dann wichtig, wenn man mehr als eine Ein- und Ausgabe von Zeichenketten haben will - z.B.farbige Darstellung von Bildern. Diese weiteren Bibliotheken sind allerdings stark abhängig vom Ziel-Betriebssystem.
Hier führe ich deshalb nur in die Programmiersprache C so gründlich ein, dass man ohne weitere Informationen damit programmieren kann. Ich handle also auch die praktische Nutzung des GNU-Compilers und notwendiges Drumherum unter LINUX ab, sowie diejenigen C-Standardfunktionen, die für normale Zwecke unverzichtbar sind.
Die Erweiterung C++ dagegen handle ich vor allem im Hinblick auf Eigenarten und Schlüsselworte ab, die als Vorteile gegenüber C gepriesen werden.
Das Wissen um die zugehörigen Bibiliotheksfunktionen muss woanders bezogen werden. Ohne weitere Informationen kann man deshalb nicht mit C++ programmieren, kann aber C++ Quelltexte wenigstens als solche erkennen und vielleicht sogar verstehen.

Fangen wir also an mit den standardisierten Ausdrücken der Programmiersprache C/C++ :

Mnemoniks bestehen hier aus ein oder zwei Zeichen, die nicht Abkürzungen englischer Worte sind, sondern eher gewohnte. Allerdings ist die Bedeutung oder Abfolge oft keineswegs die aus dem Mathematikunterricht gewohnte. Das heisst: Nichts ist wie gewohnt, sondern täuschend anders! Man spart auch nicht etwa irgendein Kommando ein! Mindestens implizit müssen genau so viele (wenn nicht mehr) Kommandos als in Assembler gegeben werden.
Daneben aber gibt es eine grosse Anzahl standardisierter Ausdrücke, die nicht mehr Abkürzungen, sondern vollständige englische Ausdrücke sind. Diese "reservierten Bezeichner", die jeweils ganz bestimmte Bedeutung haben, dürfen nicht beliebig als Namen verwendet werden. Sie müssen, um vom Compiler erkannt zu werden, von einem Zwischenraum gefolgt werden, sofern sie nicht als einzelne Zeichen anstelle von Mnemoniks Bedeutung haben.
Das, was sie in einen verständlichen Zusammenhang bringt - der Kommentar - steht in C immer geklammert zwischen den Doppelzeichen /*..blabla...*/ (Abfolge von "/" und "*" beachten!). Dazwischen kann jedes beliebige Zeichen und auch das Absatzzeichen verwendet werden.
In GNU-C/C++ kann man alternativ bis zum jeweiligen Zeilenende Text als Kommentar mittels dem eigentlich nur in C++ genormten Präfix "//" kennzeichnen.
Die Sprache C/C++ ist "format-frei". Es gibt also nicht das Absatzzeichen als Trenner zwischen Kommandos wie in Assembler, sondern darüber hinaus das Semikolon und schliessende Klammern. Weil dadurch allerlei undurchschaubares rauskommt, findet man in jedem Lehrbuch ein Flehen, es doch soundso zu machen. Die reinste Lehre besteht darin, Leerzeilen nach jeder Zeile und nur einen Befehl in ihr zu schreiben. Das macht ein C-Programm jedenfalls noch platzraubender als ein Assembler-Programm...
Zum Beispiel schreibt man eine Addition:

FUNKTIONEN UND KLASSEN:

INLINE-ASSEMBLER:

Während ein Inline-Assembler nach ANSI-Standard Bestandteil von C/C++ sein muss, ist der zu verwendende Assembler-Dialekt keineswegs standardisiert, sondern vorgeschrieben durch den jeweiligen Erzeuger eines Compilers. Ich handle hier nur den GNU-Assembler-Dialekt ab, der z.B. unterhalb LINUX zu verwenden ist. Er kommt aber auch gleich in zwei Varianten daher, deren Wahl abhängig ist vom Zweck. Ich gehe hier aber nicht auf den Zweck ein, eine Übersetzungseinheit ohne C/C++ Code zu schreiben. Ich stelle nur die Schreibweise für den Zweck des inline Assemblers vor. Wird dieser inline-Assembler benutzt, muss mit g++ ,dem C++-Compiler compiliert werden!

Alle Variablen, die in Assemblerkommandos benutzt werden, müssen global deklariert werden, also ausserhalb jeden Blocks vor main()!
Der Assemblercode selbst ist dagegen keineswegs global, sondern lokal innerhalb von Funktionen. Allerdings kann man zwischen Teile von Assemblercode innerhalb einer Funktion Funktionsaufrufe in C schreiben und auch darüber hinweg springen. Es ist also z.B. erlaubt, mit:

STANDARDFUNKTIONEN:

Die C/C++Standardfunktionen arbeiten nur innerhalb einer UNIX-artigen Betriebssystemumgebung und gehen deshalb alle durch den Flaschenhals des Interrupts 0x80, der jedenfalls unter LINUX der Betriebssysteminterrupt ist. Neben der Abfolge und Bedeutung der Parameter sind besondere Typen für Eingaben oder Rückgabewerte zu beachten und eventuell zu konvertieren (mit type-cast):
"void ", "size_t " und "FILE ".
Hier stelle ich nur die wichtigsten C-Standardfunktionen mit den unter LINUX gültigen Regeln und Kürzeln vor. Alle Funktionen sind ausserdem gut innerhalb der LINUX-Quellen dokumentiert, undzwar im Verzeichnis /usr/scr/linux/Documentation/....
Die Funktionen sind stets der Inhalt von "header"-Dateien, die mittels Präprozessoranweisungen zum Teil eines Programms gemacht und damit "eingebunden" (="included") werden. Wie solche Anweisungen formuliert werden müssen, erkläre ich erst weiter unten. Die hier genannten Funktionen befinden sich alle in einer der beiden Headerdateien "stdio.h" und "stdlib.h". Beide müssen praktisch immer eingebunden wurden (oder die Äquivalente in C++).

Wer für irgendwelche Daten-Ein- oder -Ausgaben Speicherplatz braucht, darf niemals annehmen, dass der auch verfügbar sei. Stets gibt es eine erste (niedrigste) Adresse, die frei ist, und eine letzte, die darüber noch verfügbar ist. Nur das Betriebssystem kann die Arbeitsspeicherbelegung kennen und muss deshalb mit verschiedenen Standardfunktionen zur Freigabe von Speicherplatz (="allocation") bewegt werden, deren wichtigste "void *malloc(size_t Speicherplatzbedarf)" ist. Die Freigabe des mit dieser Funktion aquirierten Speicherplatzes erfolgt mit

PRÄPROZESSOR:

Das GNU-Programm für diesen Zweck heisst "cpp". Es ist nicht nur ein Instrument, das Einfügen von Programmteilen vorzunehmen, sondern erlaubt auch abhängig von der maschinellen Umwelt das Entfernen von Programmteilen. Funktionen und Konstanten im Programm können also bedingungsabhängig ein und aus geblendet werden.
Ausserdem kann man mit dem Präprozessor noch Abkürzungen für beliebige Programmteile bilden, die man "Makro" nennt. Damit wird der Präprozessor auch zum "Makroprozessor". Das Ersetzen der selbst gewählten Abkürzungen durch die abgekürzten Programmteile nennt man "Makroexpansion". Dann sind verallgemeinerte Typen möglich wie bei Templates.
Mit solchen Methoden kann aus einem Programm ein ganz anderes gemacht werden, ohne den C/C++ Quelltext umschreiben zu müssen. Der Präprozessor ist innerhalb der UNIX-Welt das unverzichtbare Mittel, den Traum von maschinenunabhängigen Programmen zu verwirklichen. Mit C/C++ allein geht's nämlich nicht.
Neben der Ausführung solcher Anweisungen erfüllt der Präprozessor seine eigentlichen Zwecke,
-> ersetzt alle Kommentare durch einen Zwischenraum,
-> ersetzt alle Wagenrücklauf- und Absatzzeichen durch einen Zwischenraum
-> ersetzt "Trigraphsequenzen" ("Drei-Zeichen-Folgen", die im ASCII-Zeichensatz nicht
definierte Zeichen als Zeichenfolgen darstellen)
-> kürzt alle Folgen von Zwischenräumen auf einen zusammen.
Alle anderen Zwecke erreicht man mit einer nicht allzu grossen Menge von Präprozessoranweisungen, die alle mit dem Präfix "#" als erstem Zeichen in einer Zeile geschrieben werden müssen.
Ich stelle hier nur die wichtigsten vor.
Weil der Präprozessor mittels "Umgebungsvariablen" auch ein Bild des aktuellen UNIX-Systems und der Maschine enthält, ist er natürlich nicht stets der gleiche! Man hat sich also mit dem jeweils gegebenen Präprozessor und Betriebssystem zu beschäftigen. Innerhalb LINUX findet man die cpp-Dokumentation normalerweise im Verzeichnis /usr/doc/Books

PROGRAMMIERUMGEBUNG FÜR ASSEMBLER UND C/C++:

Mit dem Wissen um die richtige Ausdrucksweise beim Programmieren ist es längst nicht getan! Abgesehen davon, dass Quelltexte mit jedem Editor geschrieben werden können, sind der Umgang mit Übersetzungsprogrammen und der Test erklärungsbedürftig. Weil es auch da sehr viele Möglichkeiten gibt, beschränke ich mich auf die Paarung von LINUX und g++/gcc und die Programmierung mit NASM in dieser Umgebung. Ich gehe ausserdem davon aus, dass einer der Windowmanager benutzt wird, also z.B. KDE oder wmaker.
Für den schnellen Einstieg stelle ich zunächst Programme vor, die unbedingt nötig sind: bash, binutils, gcc, g++, glibc, mc, vim
Der Dateimanager mc muss meist ausdrücklich installiert werden, während die übrigen Programme in einer Installation vorhanden sind, wenn die als Paket formulierten Programmier-Programme installiert werden. "mc" ist ein einfaches, fehlerfreies Programm, das dennoch wichtige Operationen erlaubt, die in den sonst unter Windowmanagern benutzten Dateimanagern nicht zu haben sind. Es ist auch ein Editor eingebaut, der die aktuelle Datei unter dem Cursor hexadezimal dumpen kann. Diese Datei kann auch ein Binary sein!
Zum Schreiben eines Programms benutzt man aber besser ein Programm wie "ate"(="kate"). Ähnlich wie im deutlich umfangreicheren "emacs" sind dann synoptische Darstellungen (Teilfester) möglich, was bei umfangreichen Programmen unverzichtbar ist.

Neben diesen Programmen braucht man noch einige Kenntnisse über die Benutzung von "bash-scripten" und "bash", die als "shell" die Nahtstelle zwischen OS und Benutzer bildet. Das Programm bash hat nur eine sichtbare Stelle, allerdings mit überragender Bedeutung - die Kommandoeingabe, den "Prompt". Dieses Programm verbirgt sich auch hinter dem Menüpunkt "xterm" bzw."run". In UNIX-artigen Betriebssystemen ist das mehr als ein Befehlsinterpreter für Handbedienung. Man kann statt Namen auch Dateien zur Eingabe machen, die in einer besonderen Programmiersprache formuliert sein müssen. Diese "bash-scripte" sind immer dann wichtig, wenn nicht nur ein Programm gestartet werden soll, sondern mindestens ein Ablauf mit bestimmten Ein- und Ausgabedateien. Ein bash-script wird mit beliebigem Editor geschrieben und mit einem besonderen Kommando zum ausführbaren Programm gemacht.
Das Programm bash ist in LINUX der Standard-Kommandointerpreter und (auf englisch) bestens dokumentiert mittels Kommando:
man bash(1)
oder auch:
info bash
...sowie in HOWTO-Publikationen.
Ich stelle deshalb hier nur das Wesentliche vor, nötig, um Programme übersetzen zu können und mit anderen Programmen verknüpfbar zu machen, indem dort main() gerufen wird.

Ein bash-script ist eine normal editierbare Datei mit drei Besonderheiten:
Die beiden ersten Zeichen müssen sein:
#!
Danach muss die benutzte shell mit Pfadnamen erscheinen, gefolgt von LF
Die Datei muss zur ausführbaren Programmdatei gemacht worden sein mit dem Befehl am Prompt:
chmod -c 100 Pfadname/Dateiname_des_bash_scripts
(s.man chmod und info chmod für weiteres!)

Ich stelle ein bash-script für den Start von g++ vor:

PRAXIS:

Das wichtigste an einer Programmierumgebung ist natürlich der Programmierer!
Der muss nicht nur fit sein, sondern sich gezielt fit halten, indem er irgendeinen Sport treibt oder wenigstens zwischendurch spazieren geht. Auch während der Arbeit ist nicht das richtig, was als "Ergonomie" gepriesen wird. Richtig ist, ständig mit der körperlichen Lage zu spielen, sich zu fletzen und zu räkeln, und aufzustehen, wenn's reicht.
Ich sage das aus bitterer Erfahrung, denn der Alltag eines Programmierers besteht eben nicht aus dem Absondern von Machtworten, sondern allfälliger Ohnmacht angesichts von Fehlern! Kämpfe und Krämpfe sind das physische Resultat.
Der Kern des Problems ist, dass man nicht nur Fehler macht, sondern sich dessen schämt! Wenn einem im Laufe eines Tages die denkbar dümmste Maschine der Welt ein halbes Dutzend mal und meistens frech (=schwarzer Bildschirm) mitgeteilt hat, dass man zu blöde ist, dann geht das an die Ehre. Und tatsächlich bedarf es eines gezielten Trainings von zweckgebundener Schamlosigkeit, damit man nicht Adrenalin anstaut, was der natürliche Reflex in solchen Situationen ist. Und Adrenalin wird natürlicherweise mit körperlicher Bewegung abgebaut.

Wer glaubt, auch nur ein Dutzend Programmzeilen fehlerfrei schreiben zu können, macht den wichtigsten Fehler. Wer glaubt, auf Kommentar in seinen Programmen verzichten zu können, macht den zweitwichtigsten Fehler.
Fehler werden nicht kraft Glaubens oder mit reservierten Bezeichnern verhindert, sondern damit, dass man mit möglichst wenig Regeln, möglichst wenig besonderen Ausdrücken und möglichst wenig Suchvorgängen zu tun hat.
Programmieren ist keine Kunst! Es ist auch keine erfinderische Tätigkeit!
Man braucht weder motorische oder sensorische Fertigkeiten wie bei künstlerischen Treiben, das letztlich menschliche Hirne programmiert, noch kann man für die erstrebten Zwecke andere und neue physikalische oder chemische Effekte nutzen, wie bei erfinderischem Treiben. Programmieren ist eine besondere Sorte Mathematik und anspruchsvoller als jede andere, weil zwar das kleine Einmaleins bei jedem Schritt im Adressbereich genügt, Abläufe und Querbezüge aber äusserst kompliziert werden können. Weil die Zahl der Lösungen einer Aufgabe selten =1 ist, ist der Lösungsweg eher mit einem Spiel zu vergleichen, einem sehr schwierigen, weil auch der Lösungsweg selbst ein Teil der Lösung ist - er muss kurz ausfallen.
Schach ist wesentlich anspruchsloser, weil man da mit 64 Adressen und 6 verschiedenen Operatoren für das Versetzen von Figuren zu tun hat, weil der Ablauf eines Spiels beliebig lang sein darf, und weil es überhaupt nur 1,5 Zwecke für das Vorgehen gibt - Schach oder Schachmatt.
Ich habe schon festgestellt, dass die Zahl der Möglichkeiten für Programme gigantisch gross ist. Es gibt also nicht nur eine grosse Zahl von erstrebenswerten Zielen, sondern vor allem mal sehr viel mehr, was man nicht erstreben wird. Anders als bei anderer Mathematik hat man sich aber mit dem nicht erstrebenswerten genau so gründlich zu befassen. Oft besteht die Hälfte der Programme nur aus der Prüfung von Grenzfällen oder Zuständen. Damit hat man ingenieurmässig umzugehen, hat also Testphasen zu veranstalten, in denen unerlaubte Zustände produziert werden, um den Umgang des Programms damit zu erfahren.

Die Logik der Maschine macht schliesslich eine Konzentration beim Schreiben von Programmen nötig, die keine Ablenkung durch Dinge neben dieser Logik erlaubt. Also sind nicht nur Musik oder Gequatsche mit Hausgenossen daneben...
Ärger und Ablenkung können auch durch falsches Werkzeug erzeugt werden.
Das heisst ganz praktisch, dass man zunächst einen Editor (ein Schreibprogramm) braucht, den man im Halbschlaf bedienen kann. Eine Mausbedienung für Vorgänge, die man häufig braucht, ist gerade kein Vorteil! Das nämlich zwingt, die Hände von der Tastatur zu nehmen und nicht gerade im Schlaf eine Marke zu bewegen. Ganz besonders störend sind womöglich nötige Wühlarbeiten in Stapeln von Fenstern oder Kommandos, die man nicht im Menü findet, sondern fehlerfrei aus dem Gedächtnis tippen muss - Kennzeichen der UNIX-Welt.
Der Editor sollte unbedingt eine synoptische Darstellung verschiedener Dateiinhalte in einem Bild ermöglichen und weitest gehende Menuführung haben.
Beim Programmieren von C-Programmen gibt es mindestens eine weitere Datei oder Dokumentation, die im Blickfeld sein muss. Beim Programmieren mit Assembler ist es meist nur eine Datei, mit der man arbeitet; die aber muss in verschiedenen Abschnitten zu gleicher Zeit überschaubar sein. Auch Kopier- und Einfüge-Funktionen müssen einfach bedienbar sein, weil sie sehr häufig gebraucht werden. Programme schreibt man nämlich nicht wie Briefe runter. Man hat ja im wesentlichen mit Abläufen zu tun, die auch dann falsch sein können, wenn die nötigen Anweisungen zwar alle richtig dastehen, die Abfolge aber falsch ist. Oder man hat irgendeine Definition oder einen Bezug vergessen.
Dann schreibt man natürlich nicht alles nochmal, sondern nutzt die Kopierfunktionen. Auch Namen sollte man nur einmal schreiben, im weiteren aber als Kopien und nicht durch Tipperei in den Quelltext einfügen.
Wenn man in Assembler programmiert, hat man ausserdem den Vorteil, dass man viele Abläufe ebenfalls durch einfaches Kopieren&Einfügen wieder verwenden kann. Man hat dann nur noch mit Abänderungen (insbesondere natürlich der Namen!) zu tun, nicht aber mit viel Tipperei. In C-Programmen ist allerdings selten etwas auf diese Weise wieder verwendbar.
Aber auch die Möglichkeit, Buchzeichen zu setzen und Namen zu suchen, ist vorteilhaft. Ebenso wünschenswert ist, dass der Anlauf zum Öffnen der für die Arbeit wichtigen Dateien schnell geht.

Ärger und Ablenkung können aber auch durch falsches Vorgehen entstehen.
Weil ich Literatur zum Thema kenne, in der eine breit angelegte konzeptionelle Phase empfohlen wird, die 40% der gesamten Arbeitszeit am Programm betragen solle, will ich die Dinge zurecht rücken.
Ich habe nie mehr als ein, zwei Tage damit verschwendet, eine Idee und einen Plan zur Umsetzung zu erbrüten. Dann kam der erste Schritt!
Aber dieser erste Schritt darf niemals so aussehen, dass man sich hinsetzt und das ganze Programm erstmal runterschreiben will, um es dann an einem hohen Feiertag erstmals zu übersetzen und sich am gelungenen Streich zu ergötzen. Der Misserfolg ist garantiert!
Nicht nur die CPU arbeitet schrittig, auch der Programmierer hat schrittig vorzugehen. Und er hat seine Schritte so zu setzen, wie man sie im sumpfigen Gelände zu setzen hat:
Das Gewicht erst dann auf das bewegte Bein verlagern, wenn es Halt gefunden hat.
Ein Problem in einer konzeptionellen Phase vollständig überschauen zu wollen, ist vollkommen vermessen, wenn ein Programm im Quelltext den Inhalt einiger Schreibmaschinenseiten übersteigt. Es ist im übrigen genau diese Erfahrung, die der Ausgangspunkt von Systemphilosophien ist. Der eine hält das funktionelle Denken hoch, der andere beschwört Objekt-orientierte Kapseln. Ich sage mit Franz Beckenbauer: "Schaun' mer mal, dann sehn' wir schon...!"
Das heisst ganz konkret:
Man schreibt nicht ein Programm, man schreibt mindestens doppelt soviel, wie man am Ende stehen lassen kann. Und man sollte an allen Stolperstellen Kommentar absondern, damit man nicht vergisst, was man nicht gleich sehen konnte.

Die erste Prüfung, die ein Quelltext zu bestehen hat, ist, dass er sich übersetzen lässt. Das sollte man so häufig wie möglich prüfen, damit die Zahl der Fehlermeldungen beim Durchgang klein bleibt (und der Ärger). Dabei sollte man den Quelltext zunächst als Kommentar formulieren, den man schliesslich während der Arbeit fortschreibt und verfeinert. Auf diese Weise erarbeitet man Abläufe und im gleichen Zuge eine einfach lesbare Beschreibung.
Die zweite Prüfung, die ein Quelltext zu bestehen hat, ist, dass er sich starten und auch wieder beenden lässt. Und weil das keineswegs selbstverständlich ist, schreibt man Zug um Zug immer nur das rein, was für einen prüfbaren Effekt nötig ist und macht ihn dann auch prüfbar. Man schreibt also immer auch Programmzeilen, die nicht zum Programm gehören, sondern der Prüfung dienen! Dabei kann man garnicht umsichtig und gründlich genug sein, denn das Ziel solcher Prüfungen muss sein, bestimmte Abschnitte so fehlerfrei zu bekommen, dass man dort nicht mehr nach Fehlern suchen muss. Dann muss man im günstigen Falle Fehler nur noch im zuletzt geschriebenen Teil suchen. Andernfalls riskiert man sehr viel umständlichere Einkreisungen des Fehlers. Ist das Programm gross, wird das Auffinden nämlich zum Glücksspiel. Als ich an meinen Übersetzungsprogrammen für Assembler schrieb, hatte ich z.B. am Ende nur noch einen rätselhaften Fehler, der allerdings das ganze Programm untauglich machte. Unter einer Viertelmillion Buchstaben war ein einziger falsch - eine 3 statt einer 4 in einem Inkrement. Hätte ich den Abschnitt, in dem der Fehler steckte, genau geprüft, nachdem ich ihn geschrieben hatte, hätte ich das sofort gefunden. So aber hatte ich tagelang zu grübeln...
Natürlich ist das prüfende Vorgehen abhängig von der Aufgabe, die man sich gestellt hat, und nur über das muss man sich in einer konzeptionellen Phase den Kopf zerbrechen. Schreibt man einen Gerätetreiber, ist z.B. der Griff nach Dokumentation die erste Regung in Richtung Ziel. Und bei der Prüfung hat man auch zu bedenken, dass die Dokumentation falsch, ungenügend oder missverständlich ist - ich habe es nie anders erlebt. Entwirft man ein Dateisystem, dann hat man sich zunächst mit dem zu beschäftigen, was bei der Benutzung vorkommen kann oder wünschenswert wäre. Und erst nach vielen Rekursionen kann man sich endlich mit der Struktur von Dateiattributen befassen, weil das das Dach ist, das nicht vor dem Haus gebaut werden kann. Will man eine Formatwandlung für gewisse Dateiformate, dann gibt es meistens ein Beispiel, das man nur noch abzuwandeln hat. Dann braucht man eine konzeptionelle Phase =0 ...
Und natürlich muss man stets bereit sein, zu verwerfen, was man konzeptionell erbrütet hat! Es ist also geistige Beweglichkeit, die zum Ziel führt und nicht die Kenntnis von Regeln, die als Formeln angepriesen werden, tatsächlich aber keine sind, weil andernfalls die nimmermüde verheissenen "noch besser optimierenden" Compiler längst vorhanden wären.

Ich will das zu einigen Ratschlägen zusammen fassen:
> Als erstes jede Information zum Gegenstand des Programms finden und eventuell in einer eigenen Zusammenfassung aufarbeiten. Das ist die Problemanalyse.
Sie kann auch von einem Beispiel für ähnliche Aufgaben ausgehen.
Sie kann auch aus ein paar handschriftlichen Notizen vor dem Einschlafen bestehen.
> Als zweites die Aufgabe so zerlegen, dass prüfbare Abschnitte entstehen, die gründlich getestet werden können. Dabei ist auch die Prüfung zu durchdenken, die alle Eventualitäten erfassen muss.
> Ein Programm ausgehend von umgangssprachlichen Notizen gestalten, die man während der Arbeit und Prüfung zum lesbaren, aussagekräftigen Kommentar verfeinert. Ohne Kommentar versteht man auch die eigenen Programme binnen weniger Wochen nicht mehr!
> Funktionierende Versionen des Programms nicht fortschreiben, ohne sie in einer weiteren Datei gesichert zu haben! Und regelmässig alle wichtigen Dateien auf FD oder CDROM retten, undzwar doppelt oder dreifach, um Transferfehler reparierbar zu haben. Wer das versäumt, kann viel Arbeit verlieren, falls sein Betriebssystem neu installiert werden muss. (Mein LINUX musste ich in 7 Jahren mindestens einmal pro Jahr neu installieren, wobei alle nicht geretteten Dateien verloren gingen...)
> Wenn man einen Fehler nicht finden kann, erstmal ganz was anderes machen. Der Abstand bringt die dann nötige Übersicht. Böse Fehler stecken nämlich da, wo man sie erstmal nicht sucht.
> Höllische Fehler nicht weiter suchen, sondern das Programm von einer funktionierenden Zwischenversion ausgehend neu aufbauen und die neuen Schritte noch sorgfältiger prüfen. Denkfehler findet man nur so.
> Alle Erwartungen prüfen! Ein Programm ist erst dann fertig, wenn jeder Eventualfall getestet wurde. Meistens muss man diese Eventualfälle künstlich erzeugen, wenn es um irgendwelche Bereichsgrenzen geht. Das muss sein, wenn man böse Überraschungen vermeiden will!

Dem Einsteiger, der mir bis hierher gefolgt ist, muss ich wohl nicht mehr ausdrücklich sagen, dass er umso weniger Regeln verletzen kann, je weniger Regeln er beachten muss. Er kann allein aus dem Umfang der Erläuterungen in diesem Text ermessen, dass der Einstieg leichter über Assemblerprogramme zu schaffen ist - ein ganzes Drittel des Textes betrifft ja allein die Abhandlung von C/C++, wo schaumreduziert draufsteht, aber nicht drin ist.
Es ist nur noch hinzu zu fügen, dass auch die Fehlersuche bei Assembler-Programmen erheblich einfacher zu machen ist, undzwar schon deshalb, weil das Übersetzungsprogramm so schnell arbeitet, dass man damit jede Zeile auf Richtigkeit prüfen kann - das kostet jedenfalls in meinen Übersetzungsprogrammen ASMn und ASMat nicht mehr Zeit als ein Absatz. Die Fehlermeldungen erfolgen dort übrigens anders als in anderen Assemblern nicht durch Meldungen und einer Zuordnung über Zeilennummern, sondern Schwärzen im Listing ab der Stelle im Mnemonik, die unverdaulich war. Nur in gewissen Ausnahmefällen wird nicht der ganze Quelltext übersetzt.
Beide Programme sind ausserdem der beste Beweis dafür, dass man mit Assembler nicht nur kürzere Binaries bekommt (was niemand bestreitet), sondern dass man bei gleicher Funktionalität auch weniger zu schreiben hat (was jeder Hochsprachler sofort bestreitet). Man kann aber mein ASMn mit dem in C geschriebenen NASM vergleichen und feststellen, dass das stimmt - undzwar selbst dann, wenn man berücksichtigt, dass ich eine Menge Unsinn (Makros, Linkerheader...) wegoptimiert habe. Ausserdem zeige ich mit dem Zusammenwirken meiner Programme mit meinem Betriebssystem ASMOS auch, wie einfach man solche Dinge machen kann. Auch diesbezüglich lohnt sich der Vergleich mit einem unter LINUX laufenden NASM.

Natürlich muss man LINUX oder andere UNIX-artige Betriebssysteme nutzen, wenn man in C/C++ programmieren will. Abgesehen davon, dass der GNU-Compiler und alles nur denkbare Drumherum praktisch kostenfrei zu haben ist, ist das alles auch auf dem höchsten Stand, der auf dem Gebiet erreicht wurde! Allerdings hat man viel zu suchen und zu lesen, bevor man einigermassen weiss, wohin man wie greifen muss...
Will man in Assembler programmieren, ist wichtig, was man erstrebt. Ich habe klar gemacht, dass man unter den gängigen Betriebssystemen nur sehr umständlich bis garnicht an die wesentlichen Teile der Maschine ran kommt, und dass man infolgedessen nicht daran vorbei kommt, mindestens einen Rahmen für den Assemblercode in C/C++ zu schreiben. Will man aber mit der fast jungfräulichen Maschine umgehen und jede Wahl für eigene Projekte haben, gibt es meines Wissens nur mein ASMOS als Sprungbrett und Entwicklungsumgebung. Ich hätte es nicht geschrieben, wenn ich ähnliches gefunden hätte. Es ist ausserdem sehr ausführlich und auch auf deutsch kommentiert und taugt deshalb jedenfalls als Lehrmaterial und Wühlkiste für Codeschnipsel und Methodik.
Weitere Besonderheiten, Vorzüge und Einschränkungen erfährt man auf meiner Homepage und in den Quelltexten...