FreeBSD Developers' Handbook
Zurück | Kapitel 11. x86-Assembler-Programmierung | Weiter

# 11.13. Die FPU verwenden

Übersetzt von Fabian Borschel.

Seltsamerweise erwähnt die meiste Literatur zu Assemblersprachen nicht einmal die Existenz der FPU, oder floating point unit (Fließkomma-Recheneinheit), geschweige denn, daß auf die Programmierung mit dieser eingegangen wird.

Dabei kann die Assemblerprogrammierung gerade bei hoch optimiertem FPU-Code, der nur mit einer Assemblersprache realisiert werden kann, ihre große Stärke ausspielen.

## 11.13.1. Organisation der FPU

Die FPU besteht aus 8 80–bit Fließkomma-Registern. Diese sind in Form eines Stacks organisiert—Sie können einen Wert durch den Befehl `push` auf dem TOS (top of stack) ablegen, oder durch `pop` von diesem holen.

Da also die Befehle `push` und `pop` schon verwendet werden, kann es keine op-Codes in Assemblersprache mit diesen Namen geben.

Sie können mit einen Wert auf dem TOS ablegen, indem Sie `fld`, `fild`, und `fbld` verwenden. Mit weiteren op-Codes lassen sich Konstanten—wie z.B. Pi—auf dem TOS ablegen.

Analog dazu können Sie einen Wert holen, indem Sie `fst`, `fstp`, `fist`, `fistp`, und `fbstp` verwenden. Eigentlich holen (`pop`) nur die op-Codes, die auf p enden, einen Wert, während die anderen den Wert irgendwo speichern (`store`) ohne ihn vom TOS zu entfernen.

Daten können zwischen dem TOS und dem Hauptspeicher als 32–bit, 64–bit oder 80–bit real, oder als 16–bit, 32–bit oder 64–bit Integer, oder als 80–bit packed decimal übertragen werden.

Das 80–bit packed decimal-Format ist ein Spezialfall des binary coded decimal-Formates, welches üblicherweise bei der Konvertierung zwischen der ASCII- und FPU-Darstellung von Daten verwendet wird. Dieses erlaubt die Verwendung von 18 signifikanten Stellen.

Unabhängig davon, wie Daten im Speicher dargestellt werden, speichert die FPU ihre Daten immer im 80–bit real-Format in den Registern.

Ihre interne Genauigkeit beträgt mindestens 19 Dezimalstellen. Selbst wenn wir also Ergebnisse im ASCII-Format mit voller 18–stelliger Genauigkeit darstellen lassen, werden immer noch korrekte Werte angezeigt.

Des weiteren können mathematische Operationen auf dem TOS ausgeführt werden: Wir können dessen Sinus berechnen, wir können ihn skalieren (z.B. können wir ihn mit dem Faktor 2 Multiplizieren oder Dividieren), wir können dessen Logarithmus zur Basis 2 nehmen, und viele weitere Dinge.

Wir können auch FPU-Register multiplizieren, dividieren, addieren und subtrahieren, sogar einzelne Register mit sich selbst.

Der offizielle Intel op-Code für den TOS ist `st` und für die Register `st(0)`– `st(7)`. `st` und `st(0)` beziehen sich dabei auf das gleiche Register.

Aus welchen Gründen auch immer hat sich der Originalautor von nasm dafür entschieden, andere op-Codes zu verwenden, nämlich `st0`– `st7`. Mit anderen Worten, es gibt keine Klammern, und der TOS ist immer `st0`, niemals einfach nur `st`.

### 11.13.1.1. Das Packed Decimal-Format

Das packed decimal-Format verwendet 10 Bytes (80 Bits) zur Darstellung von 18 Ziffern. Die so dargestellte Zahl ist immer ein Integer.

> Tipp: Sie können durch Multiplikation des TOS mit Potenzen von 10 die einzelnen Dezimalstellen verschieben.

Das höchste Bit des höchsten Bytes (Byte 9) ist das Vorzeichenbit: Wenn es gesetzt ist, ist die Zahl negativ, ansonsten positiv. Die restlichen Bits dieses Bytes werden nicht verwendet bzw. ignoriert.

Die restlichen 9 Bytes enthalten die 18 Ziffern der gespeicherten Zahl: 2 Ziffern pro Byte.

Die signifikantere Ziffer wird in der oberen Hälfte (4 Bits) eines Bytes gespeichert, die andere in der unteren Hälfte.

Vielleicht würden Sie jetzt annehmen, das `-1234567` auf die folgende Art im Speicher abgelegt wird (in hexadezimaler Notation):

    80 00 00 00 00 00 01 23 45 67

Dem ist aber nicht so! Bei Intel werden alle Daten im little–endian-Format gespeichert, auch das packed decimal-Format.

Dies bedeutet, daß `-1234567` wie folgt gespeichert wird:

    67 45 23 01 00 00 00 00 00 80

Erinnern Sie sich an diesen Umstand, bevor Sie sich aus lauter Verzweiflung die Haare ausreißen.

> Anmerkung: Das lesenswerte Buch—falls Sie es finden können—ist Richard Startz' 8087/80287/80387 for the IBM PC & Compatibles. Obwohl es anscheinend die Speicherung der packed decimal im little–endian-Format für gegeben annimmt. Ich mache keine Witze über meine Verzweiflung, als ich den Fehler im unten stehenden Filter gesucht habe, bevor mir einfiel, daß ich einfach mal versuchen sollte, das little–endian-Format, selbst für diesen Typ von Daten, anzuwenden.

## 11.13.2. Ausflug in die Lochblendenphotographie

Um sinnvolle Programme zu schreiben, müssen wir nicht nur unsere Programmierwerkzeuge beherrschen, sondern auch das Umfeld, für das die Programme gedacht sind.

Unser nächster Filter wird uns dabei helfen, wann immer wir wollen, eine Lochkamera zu bauen. Wir brauchen also etwas Hintergrundwissen über die Lochblendenphotographie, bevor wir weiter machen können.

### 11.13.2.1. Die Kamera

Die einfachste Form, eine Kamera zu beschreiben, ist die eines abgeschlossenen, lichtundurchlässigen Raumes, in dessen Abdeckung sich ein kleines Loch befindet.

Die Abdeckung ist normalerweise fest (z.B. eine Schachtel), manchmal jedoch auch flexibel (z.B. ein Balgen). Innerhalb der Kamera ist es sehr dunkel. Nur durch ein kleines Loch kann Licht von einem einzigen Punkt aus in den Raum eindringen (in manchen Fällen sind es mehrere Löcher). Diese Lichtstrahlen kommen von einem Bild, einer Darstellung von dem was sich außerhalb der Kamera, vor dem kleinen Loch, befindet.

Wenn ein lichtempfindliches Material (wie z.B. ein Film) in der Kamera angebracht wird, so kann dieses das Bild einfangen.

Das Loch enthält häufig eine Linse, oder etwas linsenartiges, häufig auch einfach Objektiv genannt.

### 11.13.2.2. Die Lochblende

Streng genommen ist die Linse nicht notwendig: Die ursprünglichen Kameras verwendeten keine Linse, sondern eine Lochblende. Selbst heutzutage werden noch Lochblenden verwendet, zum einen, um die Funktionsweise einer Kamera zu erlernen, und zum anderen, um eine spezielle Art von Bildern zu erzeugen.

Das Bild, das von einer Lochblende erzeugt wird, ist überall scharf. Oder unscharf. Es gibt eine ideale Größe für eine Lochblende: Wenn sie größer oder kleiner ist, verliert das Bild seine Schärfe.

### 11.13.2.3. Brennweite

Dieser ideale Lochblendendurchmesser ist eine Funktion der Quadratwurzel der Brennweite, welche dem Abstand der Lochblende von dem Film entspricht.

         D = PC * sqrt(FL)

Hier ist `D` der ideale Durchmesser der Lochblende, `FL` die Brennweite und `PC` eine Konstante der Brennweite. Nach Jay Bender hat die Konstante den Wert `0.04`, nach Kenneth Connors `0.037`. Andere Leute haben andere Werte vorgeschlagen. Des weiteren gelten diese Werte nur für Tageslicht: Andere Arten von Licht benötigen andere konstante Werte, welche nur durch Experimente bestimmt werden können.

### 11.13.2.4. Der f–Wert

Der f–Wert ist eine sehr nützliche Größe, die angibt, wieviel Licht den Film erreicht. Ein Belichtungsmesser kann dies messen, um z.B. für einen Film mit einer Empfindlichkeit von f5.6 eine Belichtungsdauer von 1/1000 Sekunden auszurechnen.

Es spielt keine Rolle, ob es eine 35–mm- oder eine 6x9cm-Kamera ist, usw. Solange wir den f–Wert kennen, können wir die benötigte Belichtungszeit berechnen.

Der f–Wert läßt sich einfach wie folgt berechnen:

        F = FL / D

Mit anderen Worten, der f–Wert ergibt sich aus der Brennweite (FL), dividiert durch den Durchmesser (D) der Lochblende. Ein großer f–Wert impliziert also entweder eine kleine Lochblende, oder eine große Brennweite, oder beides. Je größer also der f–Wert ist, um so länger muß die Belichtungszeit sein.

Des weiteren sind der Lochblendendurchmesser und die Brennweite eindimensionale Meßgrößen, während der Film und die Lochblende an sich zweidimensionale Objekte darstellen. Das bedeutet, wenn man für einen f–Wert `A` eine Belichtungsdauer `t` bestimmt hat, dann ergibt sich daraus für einen f–Wert `B` eine Belichtungszeit von:

        t * (B / A)²

### 11.13.2.5. Normalisierte f–Werte

Während heutige moderne Kameras den Durchmesser der Lochblende, und damit deren f–Wert, weich und schrittweise verändern können, war dies früher nicht der Fall.

Um unterschiedliche f–Werte einstellen zu können, besaßen Kameras typischerweise eine Metallplatte mit Löchern unterschiedlichen Durchmessers als Lochblende.

Die Durchmesser wurden entsprechend obiger Formel gewählt, daß der resultierende f–Wert ein fester Standardwert war, der für alle Kameras verwendet wurde. Z.B. hat eine sehr alte Kodak Duaflex IV Kamera in meinem Besitz drei solche Löcher für die f–Werte 8, 11 und 16.

Eine neuere Kamera könnte f–Werte wie 2.8, 4, 5.6, 8, 11, 16, 22, und 32 (und weitere) besitzen. Diese Werte wurden nicht zufällig ausgewählt: Sie sind alle vielfache der Quadratwurzel aus 2, wobei manche Werte gerundet wurden.

### 11.13.2.6. Der f–Stopp

Eine typische Kamera ist so konzipiert, daß die Nummernscheibe bei den normalisierten f–Werten einrastet. Die Nummernscheibe stoppt an diesen Positionen. Daher werden diese Positionen auch f–Stopps genannt.

Da die f–Werte bei jedem Stopp vielfache der Quadratwurzel aus 2 sind, verdoppelt die Drehung der Nummernscheibe um einen Stopp die für die gleiche Belichtung benötigte Lichtmenge. Eine Drehung um 2 Stopps vervierfacht die benötigte Belichtungszeit. Eine Drehung um 3 Stopps verachtfacht sie, etc.

## 11.13.3. Entwurf der Lochblenden-Software

Wir können jetzt festlegen, was genau unsere Lochblenden-Software tun soll.

### 11.13.3.1. Verarbeitung der Programmeingaben

Da der Hauptzweck des Programms darin besteht, uns beim Entwurf einer funktionierenden Lochkamera zu helfen, wird die Brennweite die Programmeingabe sein. Dies ist etwas, das wir ohne zusätzliche Programme feststellen können: Die geeignete Brennweite ergibt sich aus der Größe des Films und der Art des Fotos, ob dieses ein "normales" Bild, ein Weitwinkelbild oder ein Telebild sein soll.

Die meisten bisher geschriebenen Programme arbeiteten mit einzelnen Zeichen, oder Bytes, als Eingabe: Das hex-Programm konvertierte einzelne Bytes in hexadezimale Werte, das csv-Programm ließ entweder einzelne Zeichen unverändert, löschte oder veränderte sie, etc.

Das Programm ftuc verwendete einen Zustandsautomaten, um höchstens zwei gleichzeitig eingegebene Bytes zu verarbeiten.

Das pinhole-Programm dagegen kann nicht nur mit einzelnen Zeichen arbeiten, sondern muß mit größeren syntaktischen Einheiten zurrecht kommen.

Wenn wir z.B. möchten, daß unser Programm den Lochblendendurchmesser (und weitere Werte, die wir später noch diskutieren werden) für die Brennweiten `100 mm`, `150 mm` und `210 mm` berechnet, wollen wir etwa folgendes eingeben:

    100, 150, 210

Unser Programm muß mit der gleichzeitigen Eingabe von mehr als nur einem einzelnen Byte zurecht kommen. Wenn es eine `1` erkennt, muß es wissen, daß dies die erste Stelle einer dezimalen Zahl ist. Wenn es eine `0`, gefolgt von einer weiteren `0` sieht, muß es wissen, daß dies zwei unterschiedliche Stellen mit der gleichen Zahl sind.

Wenn es auf das erste Komma trifft, muß es wissen, daß die folgenden Stellen nicht mehr zur ersten Zahl gehören. Es muß die Stellen der ersten Zahl in den Wert `100` konvertieren können. Und die Stellen der zweiten Zahl müssen in den Wert `150` konvertiert werden. Und die Stellen der dritten Zahl müssen in den Wert `210` konvertiert werden.

Wir müssen festlegen, welche Trennsymbole zulässig sind: Sollen die Eingabewerte durch Kommas voneinander getrennt werden? Wenn ja, wie sollen zwei Zahlen behandelt werden, die durch ein anderes Zeichen getrennt sind?

Ich persönlich mag es einfach. Entweder etwas ist eine Zahl, dann wird es verarbeitet, oder es ist keine Zahl, dann wird es verworfen. Ich mag es nicht, wenn sich der Computer bei der offensichtlichen Eingabe eines zusätzlichen Zeichens beschwert. Duh!

Zusätzlich erlaubt es mir, die Monotonie des Tippens zu durchbrechen, und eine Anfrage anstelle einer simplen Zahl zu stellen:

    Was ist der beste Lochblendendurchmesser
    	  bei einer Brennweite von 150?

Es gibt keinen Grund dafür, die Ausgabe mehrerer Fehlermeldungen aufzuteilen:

    Syntax error: Was
    Syntax error: ist
    Syntax error: der
    Syntax error: beste

Et cetera, et cetera, et cetera.

Zweitens mag ich das `#`-Zeichen, um Kommentare zu markieren, die ab dem Zeichen bis zum Ende der jeweiligen Zeile gehen. Dies verlangt nicht viel Programmieraufwand, und ermöglicht es mir, Eingabedateien für meine Programme als ausführbare Skripte zu handhaben.

In unserem Fall müssen wir auch entscheiden, in welchen Einheiten die Dateneingabe erfolgen soll: Wir wählen Millimeter, da die meisten Photographen die Brennweite in dieser Einheit messen.

Letztendlich müssen wir noch entscheiden, ob wir die Verwendung des dezimalen Punktes erlauben (in diesem Fall müssen wir berücksichtigen, daß in vielen Ländern der Welt das dezimale Komma verwendet wird).

In unserem Fall würde das Zulassen eines dezimalen Punktes/Kommas zu einer fälschlicherweise angenommenen, höheren Genauigkeit führen: Der Unterschied zwischen den Brennweiten `50` und `51` ist fast nicht wahrnehmbar. Die Zulassung von Eingaben wie `50.5` ist also keine gute Idee. Beachten Sie bitte, das dies meine Meinung ist. In diesem Fall bin ich der Autor des Programmes. Bei Ihren eigenen Programmen müssen Sie selbst solche Entscheidungen treffen.

### 11.13.3.2. Optionen anbieten

Das wichtigste, was wir zum Bau einer Lochkamera wissen müssen, ist der Durchmesser der Lochblende. Da wir scharfe Bilder schießen wollen, werden wir obige Formel für die Berechnung des korrekten Durchmessers zu gegebener Brennweite verwenden. Da Experten mehrere Werte für die `PC`-Konstante anbieten, müssen wir uns hier für einen Wert entscheiden.

In der Programmierung unter UNIX® ist es üblich, zwei Hauptvarianten anzubieten, um Parameter an Programme zu übergeben, und des weiteren eine Standardeinstellung für den Fall zu haben, das der Benutzer gar keine Parameter angibt.

Warum zwei Varianten, Parameter anzugeben?

Ein Grund ist, eine (relativ) feste Einstellung anzubieten, die automatisch bei jedem Programmaufruf verwendet wird, ohne das wir diese Einstellung immer und immer wieder mit angeben müssen.

Die feste Einstellung kann in einer Konfigurationsdatei gespeichert sein, typischerweise im Heimatverzeichnis des Benutzers. Die Datei hat üblicherweise denselben Namen wie das zugehörige Programm, beginnt jedoch mit einem Punkt. Häufig wird "rc" dem Dateinamen hinzugefügt. Unsere Konfigurationsdatei könnte also `~/.pinhole` oder `~/.pinholerc` heißen. (Die Zeichenfolge `~/` steht für das Heimatverzeichnis des aktuellen Benutzers.)

Konfigurationsdateien werden häufig von Programmen verwendet, die viele konfigurierbare Parameter besitzen. Programme, die nur eine (oder wenige) Parameter anbieten, verwenden häufig eine andere Methode: Sie erwarten die Parameter in einer Umgebungsvariablen. In unserem Fall könnten wir eine Umgebungsvariable mit dem Namen `PINHOLE` benutzen.

Normalerweise verwendet ein Programm entweder die eine, oder die andere der beiden obigen Methoden. Ansonsten könnte ein Programm verwirrt werden, wenn eine Konfigurationsdatei das eine sagt, die Umgebungsvariable jedoch etwas anderes.

Da wir nur einen Parameter unterstützen müssen, verwenden wir die zweite Methode, und benutzen eine Umgebungsvariable mit dem Namen `PINHOLE`.

Der andere Weg erlaubt uns, ad hoc Entscheidungen zu treffen: "Obwohl ich normalerweise einen Wert von 0.039 verwende, will ich dieses eine Mal einen Wert von 0.03872 anwenden." Mit anderen Worten, dies erlaubt uns, die Standardeinstellung außer Kraft zu setzen.

Diese Art der Auswahl wird häufig über Kommandozeilenparameter gemacht.

Schließlich braucht ein Programm immer eine Standardeinstellung. Der Benutzer könnte keine Parameter angeben. Vielleicht weiß er auch gar nicht, was er einstellen sollte. Vielleicht will er es "einfach nur ausprobieren". Vorzugsweise wird die Standardeinstellung eine sein, die die meisten Benutzer sowieso wählen würden. Somit müssen diese keine zusätzlichen Parameter angeben, bzw. können die Standardeinstellung ohne zusätzlichen Aufwand benutzen.

Bei diesem System könnte das Programm widersprüchliche Optionen vorfinden, und auf die folgende Weise reagieren:

1. Wenn es eine ad hoc-Einstellung vorfindet (z.B. ein Kommandozeilenparameter), dann sollte es diese Einstellung annehmen. Es muß alle vorher festgelegten sowie die standardmäßige Einstellung ignorieren.

2. Andererseits, wenn es eine festgelegte Option (z.B. eine Umgebungsvariable) vorfindet, dann sollte es diese akzeptieren und die Standardeinstellung ignorieren.

3. Ansonsten sollte es die Standardeinstellung verwenden.

Wir müssen auch entscheiden, welches Format unsere `PC`-Option haben soll.

Auf den ersten Blick scheint es einleuchtend, das Format `PINHOLE=0.04` für die Umgebungsvariable, und `-p0.04` für die Kommandozeile zu verwenden.

Dies zuzulassen wäre eigentlich eine Sicherheitslücke. Die `PC`-Konstante ist eine sehr kleine Zahl. Daher würden wir unsere Anwendung mit verschiedenen, kleinen Werten für `PC` testen. Aber was würde passieren, wenn jemand das Programm mit einem sehr großen Wert aufrufen würde?

Es könnte abstürzen, weil wir das Programm nicht für den Umgang mit großen Werten entworfen haben.

Oder wir investieren noch weiter Zeit in das Programm, so daß dieses dann auch mit großen Zahlen umgehen kann. Wir könnten dies machen, wenn wir kommerzielle Software für computertechnisch unerfahrene Benutzer schreiben würden.

Oder wir könnten auch sagen "Pech gehabt! Der Benutzer sollte es besser wissen."

Oder wir könnten es für den Benutzer unmöglich machen, große Zahlen einzugeben. Dies ist die Variante, die wir verwenden werden: Wir nehmen einen impliziten 0.-Präfix an.

Mit anderen Worten, wenn der Benutzer den Wert `0.04` angeben will, so muß er entweder `-p04` als Parameter angeben, oder `PINHOLE=04` als Variable in seiner Umgebung definieren. Falls der Benutzer `-p9999999` angibt, so wird dies als `0.9999999` interpretiert—zwar immer noch sinnlos, aber zumindest sicher.

Zweitens werden viele Benutzer einfach die Konstanten von Bender oder Connors benutzen wollen. Um es diesen Benutzern einfacher zu machen, werden wir `-b` als `-p04`, und `-c` als `-p037` interpretieren.

### 11.13.3.3. Die Ausgabe

Wir müssen festlegen, was und in welchem Format unsere Anwendung Daten ausgeben soll.

Da wir als Eingabe beliebig viele Brennweiten erlauben, macht es Sinn, die Ergebnisse in Form einer traditionellen Datenbank–Ausgabe darzustellen, bei der zeilenweise zu jeder Brennweite der zugehörige berechnete Wert, getrennt durch ein `tab`-Zeichen, ausgegeben wird.

Optional sollten wir dem Benutzer die Möglichkeit geben, die Ausgabe in dem schon beschriebenen CSV-Format festzulegen. In diesem Fall werden wir zu Beginn der Ausgabe eine Zeile einfügen, in der die Beschreibungen der einzelnen Felder, durch Kommas getrennt, aufgelistet werden, gefolgt von der Ausgabe der Daten wie schon beschrieben, wobei das `tab`-Zeichen durch ein `Komma` ersetzt wird.

Wir brauchen eine Kommandozeilenoption für das CSV-Format. Wir können nicht `-c` verwenden, da diese Option bereits für verwende Connors Konstante steht. Aus irgendeinem seltsamen Grund bezeichnen viele Webseiten CSV-Dateien als "Excel Kalkulationstabelle" (obwohl das CSV-Format älter ist als Excel). Wir werden daher `-e` als Schalter für die Ausgabe im CSV-Format verwenden.

Jede Zeile der Ausgabe wird mit einer Brennweite beginnen. Dies mag auf den ersten Blick überflüssig erscheinen, besonders im interaktiven Modus: Der Benutzer gibt einen Wert für die Brennweite ein, und das Programm wiederholt diesen.

Der Benutzer kann jedoch auch mehrere Brennweiten in einer Zeile angeben. Die Eingabe kann auch aus einer Datei, oder aus der Ausgabe eines anderen Programmes, kommen. In diesen Fällen sieht der Benutzer die Eingabewerte überhaupt nicht.

Ebenso kann die Ausgabe in eine Datei umgelenkt werden, was wir später noch untersuchen werden, oder sie könnte an einen Drucker geschickt werden, oder auch als Eingabe für ein weiteres Programm dienen.

Es macht also wohl Sinn, jede Zeile mit einer durch den Benutzer eingegebenen Brennweite beginnen zu lassen.

Halt! Nicht, wie der Benutzer die Daten eingegeben hat. Was passiert, wenn der Benutzer etwas wie folgt eingibt:

    00000000150

Offensichtlich müssen wir die führenden Nullen vorher abschneiden.

Wir müssen also die Eingabe des Benutzers sorgfältig prüfen, diese dann in der FPU in die binäre Form konvertieren, und dann von dort aus ausgeben.

Aber...

Was ist, wenn der Benutzer etwas wie folgt eingibt:

    17459765723452353453534535353530530534563507309676764423

Ha! Das packed decimal-Format der FPU erlaubt uns die Eingabe einer 18–stelligen Zahl. Aber der Benutzer hat mehr als 18 Stellen eingegeben. Wie gehen wir damit um?

Wir könnten unser Programm so modifizieren, daß es die ersten 18 Stellen liest, der FPU übergibt, dann weitere 18 Stellen liest, den Inhalt des TOS mit einem Vielfachen von 10, entsprechend der Anzahl der zusätzlichen Stellen multipliziert, und dann beide Werte mittels `add` zusammen addiert.

Ja, wir könnten das machen. Aber in diesem Programm wäre es unnötig (in einem anderen wäre es vielleicht der richtige Weg): Selbst der Erdumfang in Millimetern ergibt nur eine Zahl mit 11 Stellen. Offensichtlich können wir keine Kamera dieser Größe bauen (jedenfalls jetzt noch nicht).

Wenn der Benutzer also eine so große Zahl eingibt, ist er entweder gelangweilt, oder er testet uns, oder er versucht, in das System einzudringen, oder er spielt— indem er irgendetwas anderes macht als eine Lochkamera zu entwerfen.

Was werden wir tun?

Wir werden ihn ohrfeigen, gewissermaßen:

    17459765723452353453534535353530530534563507309676764423	???	???	???	???	???

Um dies zu erreichen, werden wir einfach alle führenden Nullen ignorieren. Sobald wir eine Ziffer gefunden haben, die nicht Null ist, initialisieren wir einen Zähler mit `0` und beginnen mit drei Schritten:

1. Sende die Ziffer an die Ausgabe.

2. Füge die Ziffer einem Puffer hinzu, welchen wir später benutzen werden, um den packed decimal-Wert zu erzeugen, den wir an die FPU schicken können.

3. Erhöhe den Zähler um eins.

Während wir diese drei Schritte wiederholen, müssen wir auf zwei Bedingungen achten:

- Wenn der Zähler den Wert 18 übersteigt, hören wir auf, Ziffern dem Puffer hinzuzufügen. Wir lesen weiterhin Ziffern und senden sie an die Ausgabe.

- Wenn, bzw. falls, das nächste Eingabezeichen keine Zahl ist, sind wir mit der Bearbeitung der Eingabe erst einmal fertig.

  Übrigends können wir einfach Zeichen, die keine Ziffern sind, verwerfen, solange sie kein `#`-Zeichen sind, welches wir an den Eingabestrom zurückgeben müssen. Dieses Zeichen markiert den Beginn eines Kommentars. An dieser Stelle muß die Erzeugung der Ausgabe fertig sein, und wir müssen mit der Suche nach weiteren Eingabedaten fortfahren.

Es bleibt immer noch eine Möglichkeit unberücksichtigt: Wenn der Benutzer eine Null (oder mehrere) eingibt, werden wir niemals eine von Null verschiedene Zahl vorfinden.

Wir können solch einen Fall immer anhand des Zählerstandes feststellen, welcher dann immer bei `0` bleibt. In diesem Fall müssen wir einfach eine `0` an die Ausgabe senden, und anschließend dem Benutzer erneut eine "Ohrfeige" verpassen:

    0	???	???	???	???	???

Sobald wir die Brennweite ausgegeben, und die Gültigkeit dieser Eingabe verifiziert haben, (größer als `0` und kleiner als 18 Zahlen) können wir den Durchmesser der Lochblende berechnen.

Es ist kein Zufall, daß Lochblende das Wort Loch enthält. In der Tat ist eine Lochblende buchstäblich eine Loch Blende, also eine Blende, in die mit einer Nadel vorsichtig ein kleines Loch gestochen wird.

Daher ist eine typische Lochblende sehr klein. Unsere Formel liefert uns das Ergebnis in Millimetern. Wir werden dieses mit `1000` multiplizieren, so daß die Ausgabe in `Mikrometern` erfolgt.

An dieser Stelle müssen wir auf eine weitere Falle achten: Zu hohe Genauigkeit.

Ja, die FPU wurde für mathematische Berechnungen mit hoher Genauigkeit entworfen. Unsere Berechnungen hier erfordern jedoch keine solche mathematische Genauigkeit. Wir haben es hier mit Physik zu tun (Optik, um genau zu sein).

Angenommen, wir wollten aus eine Lastkraftwagen eine Lochkamera bauen (wir wären dabei nicht die ersten, die das versuchen würden!). Angenommen, die Länge des Laderaumes beträgt `12` Meter lang, so daß wir eine Brennweite von `12000` hätten. Verwenden wir Benders Konstante, so erhalten wir durch Multiplizieren von `0.04` mit der Quadratwurzel aus `12000` einen Wert von `4.381780460` Millimetern, oder `4381.780460` Micrometern.

So oder so ist das Rechenergebnis absurd präzise. Unser Lastkraftwagen ist nicht genau `12000` Millimeter lang. Wir haben diese Länge nicht mit einer so hohen Genauigkeit gemessen, weswegen es falsch wäre zu behaupten, unser Lochblendendurchmesser müsse exakt `4.381780460` Millimeter sein. Es reicht vollkommen aus, wenn der Durchmesser `4.4` Millimeter beträgt.

> Anmerkung: Ich habe in obigem Beispiel das Rechenergebnis "nur" auf 10 Stellen genau angegeben. Stellen Sie sich vor, wie absurd es wäre, die vollen uns zur Verfügung stehenden, 18 Stellen anzugeben!

Wir müssen also die Anzahl der signifikanten Stellen beschränken. Eine Möglichkeit wäre, die Mikrometer durch eine ganze Zahl darzustellen. Unser Lastkraftwaren würde dann eine Lochblende mit einem Durchmesser von `4382` Mikrometern benötigen. Betrachten wir diesen Wert, dann stellen wir fest, das `4400` Mikrometer, oder `4.4` Millimeter, immer noch genau genug ist.

Zusätzlich können wir noch, unabhängig von der Größe eines Rechenergebnisses, festlegen, daß wir nur vier signifikante Stellen anzeigen wollen (oder weniger). Leider bietet uns die FPU nicht die Möglichkeit, das Ergebnis automatisch bis auf eine bestimmte Stelle zu runden (sie sieht die Daten ja nicht als Zahlen, sondern als binäre Daten an).

Wir müssen also selber einen Algorithmus entwerfen, um die Anzahl der signifikanten Stellen zu reduzieren.

Hier ist meiner (ich denke er ist peinlich—wenn Ihnen ein besserer Algorithmus einfällt, verraten sie ihn mir bitte):

1. Initialisiere einen Zähler mit `0`.

2. Solange die Zahl größer oder gleich `10000` ist, dividiere die Zahl durch `10`, und erhöhe den Zähler um eins.

3. Gebe das Ergebnis aus.

4. Solange der Zähler größer als `0` ist, gebe eine `0` aus, und reduziere den Zähler um eins.

> Anmerkung: Der Wert `10000` ist nur für den Fall, daß Sie vier signifikante Stellen haben wollen. Für eine andere Anzahl signifikanter Stellen müssen Sie den Wert `10000` mit `10`, hoch der Anzahl der gewünschten signifikanten Stellen, ersetzen.

Wir können so den Lochblendendurchmesser, auf vier signifikante Stellen gerundet, ausgeben.

An dieser Stellen kennen wir nun die Brennweite und den Lochblendendurchmesser. Wir haben also jetzt genug Informationen, um den f–Wert zu bestimmen.

Wir werden den f–Wert, auf vier signifikante Stellen gerundet, ausgeben. Es könnte passieren, daß diese vier Stellen recht wenig aussagen. Um die Aussagekraft des f–Wertes zu erhöhen, könnten wir den nächstliegenden, normalisierten f–Wert bestimmen, also z.B. das nächstliegende Vielfache der Quadratwurzel aus 2.

Wir erreichen dies, indem wir den aktuellen f–Wert mit sich selbst multiplizieren, so daß wir dessen Quadrat (`square`) erhalten. Anschließend berechnen wir den Logarithmus zur Basis 2 von dieser Zahl. Dies ist sehr viel einfacher, als direkt den Logarithmus zur Basis der Quadratwurzel aus 2 zu berechnen! Wir runden dann das Ergebnis auf die nächstliegende ganze Zahl. Genau genommen können wir mit Hilfe der FPU diese Berechnung beschleunigen: Wir können den op-Code `fscale` verwenden, um eine Zahl um 1 zu "skalieren", was dasselbe ist, wie eine Zahl mittels `shift` um eine Stelle nach links zu verschieben. Am Ende berechnen wir noch die Quadratwurzel aus allem, und erhalten dann den nächstliegenden, normalisierten f–Wert.

Wenn das alles jetzt viel zu kompliziert wirkt—oder viel zu aufwendig—wird es vielleicht klarer, wenn man den Code selber betrachtet. Wir benötigen insgesamt 9 op-Codes:

    fmul    st0, st0
        fld1
        fld     st1
        fyl2x
        frndint
        fld1
        fscale
        fsqrt
        fstp    st1

Die erste Zeile, `fmul st0, st0`, quadriert den Inhalt des TOS (Top Of Stack, was dasselbe ist wie `st`, von nasm auch `st0` genannt). Die Funktion `fld1` fügt eine `1` dem TOS hinzu.

Die nächste Zeile, `fld st1`, legt das Quadrat auf dem TOS ab. An diesem Punkt befindet sich das Quadrat sowohl in `st` als auch in `st(2)` (es wird sich gleich zeigen, warum wir eine zweite Kopie auf dem Stack lassen.) `st(1)` enthält die `1`.

Im nächsten Schritt, `fyl2x`, wird der Logarithmus von `st` zur Basis 2 berechnet, und anschließend mit `st(1)` multipliziert. Deshalb haben wir vorher die `1` in `st(1)` abgelegt.

An dieser Stelle enthält `st` den gerade berechneten Logarithmus, und `st(1)` das Quadrat des aktuellen f–Wertes, den wir für später gespeichert haben.

`frndint` rundet den TOS zur nächstliegenden ganzen Zahl. `fld1` legt eine `1` auf dem Stack ab. `fscale` shiftet die `1` auf dem TOS um `st(1)` Stellen, wodurch im Endeffekt eine 2 in `st(1)` steht.

Schließlich berechnet `fsqrt` die Quadratwurzel des Rechenergebnisses, also des nächstliegenden, normalisierten f–Wertes.

Wir haben nun den nächstliegenden, normalisierten f–Wert auf dem TOS liegen, den auf den Logarithmus zur Basis 2 gerundeten, nächstliegenden ganzzahligen Wert in `st(1)`, und das Quadrat des aktuellen f–Wertes in `st(2)`. Wir speichern den Wert für eine spätere Verwendung in `st(2)`.

Aber wir brauchen den Inhalt von `st(1)` gar nicht mehr. Die letzte Zeile, `fstp st1`, platziert den Inhalt von `st` in `st(1)`, und erniedrigt den Stackpointer um eins. Dadurch ist der Inhalt von `st(1)` jetzt `st`, der Inhalt von `st(2)` jetzt `st(1)` usw. Der neue `st` speichert jetzt den normalisierten f–Wert. Der neue `st(1)` speichert das Quadrat des aktuellen f–Wertes für die Nachwelt.

Jetzt können wir den normalisierten f–Wert ausgeben. Da er normalisiert ist, werden wir ihn nicht auf vier signifikante Stellen runden, sondern stattdessen mit voller Genauigkeit ausgeben.

Der normalisierte f–Wert ist nützlich, solange er so klein ist, daß wir ihn auf einem Photometer wiederfinden können. Ansonsten brauchen wir eine andere Methode, um die benötigten Belichtungsdaten zu bestimmen.

Wir haben weiter oben eine Formel aufgestellt, über die wir einen f–Wert mit Hilfe eines anderen f–Wertes und den zugehörigen Belichtungsdaten bestimmen können.

Jedes Photometer, das ich jemals gesehen habe, konnte die benötigte Belichtungszeit für f5.6 berechnen. Wir werden daher einen "f5.6 Multiplizierer" berechnen, der uns den Faktor angibt, mit dem wir die bei f5.6 gemessene Belichtungszeit für unsere Lochkamera multiplizieren müssen.

Durch die Formel wissen wir, daß dieser Faktor durch Dividieren unseres f–Wertes (der aktuelle Wert, nicht der normalisierte) durch `5.6` und anschließendes Quadrieren, berechnen können.

Mathematisch äquivalent dazu wäre, wenn wir das Quadrat unseres f–Wertes durch das Quadrat von `5.6` dividieren würden.

Numerisch betrachtet wollen wir nicht zwei Zahlen quadrieren, wenn es möglich ist, nur eine Zahl zu quadrieren. Daher wirkt die erste Variante auf den ersten Blick besser.

Aber...

`5.6` ist eine Konstante. Wir müssen nicht wertvolle Rechenzeit der FPU verschwenden. Es reicht aus, daß wir die Quadrate der einzelnen f–Werte durch den konstanten Wert `5.6²` dividieren. Oder wir können den jeweiligen f–Wert durch `5.6` dividieren, und dann das Ergebnis quadrieren. Zwei Möglichkeiten, die gleich erscheinen.

Aber das sind sie nicht!

Erinnern wir uns an die Grundlagen der Photographie weiter oben, dann wissen wir, daß sich die Konstante `5.6` aus dem 5-fachen der Quadratwurzel aus 2 ergibt. Eine irrationale Zahl. Das Quadrat dieser Zahl ist exakt `32`.

`32` ist nicht nur eine ganze Zahl, sondern auch ein Vielfaches von 2. Wir brauchen also gar nicht das Quadrat eines f–Wertes durch `32` zu teilen. Wir müssen lediglich mittels `fscale` den f–Wert um fünf Stellen nach rechts shiften. Aus Sicht der FPU müssen wir also `fscale` mit `st(1)`, welcher gleich `-5` ist, auf den f–Wert anwenden. Dies ist sehr viel schneller als die Division.

Jetzt wird es auch klar, warum wir das Quadrat des f–Wertes ganz oben auf dem Stack der FPU gespeichert haben. Die Berechnung des f5.6 Multiplizierers ist die einfachste Berechnung des gesamten Programmes! Wir werden das Ergebnis auf vier signifikante Stellen gerundet ausgeben.

Es gibt noch eine weitere nützliche Zahl, die wir berechnen können: Die Anzahl der Stopps, die unser f–Wert von f5.6 entfernt ist. Dies könnte hilfreich sein, wenn unser f–Wert außerhalb des Meßbereiches unseres Photometers liegt, wir aber eine Blende haben, bei der wir unterschiedliche Geschwindigkeiten einstellen können, und diese Blende Stopps benutzt.

Angenommen, unser f–Wert ist 5 Stopps von f5.6 entfernt, und unser Photometer sagt uns, daß wir eine Belichtungszeit von 1/1000 Sek. einstellen sollen. Dann können wir unsere Blende auf die Geschwindigkeit 1/1000 einstellen, und unsere Skala um 5 Stopps verschieben.

Diese Rechnung ist ebenfalls sehr einfach. Alles, was wir tun müssen, ist, den Logarithmus des f5.6 Multiplizierers, den wir schon berechnet haben (wobei wir dessen Wert vor der Rundung nehmen müssen) zur Basis 2 zu nehmen. Wir runden dann das Ergebnis zur nächsten ganzen Zahl hin, und geben dies aus. Wir müssen uns nicht darum kümmern, ob wir mehr als vier signifikante Stellen haben: Das Ergebnis besteht höchstwahrscheinlich nur aus einer oder zwei Stellen.

## 11.13.4. FPU Optimierungen

In Assemblersprache können wir den Code für die FPU besser optimieren, als in einer der Hochsprachen, inklusive C.

Sobald eine C-Funktion die Berechnung einer Fließkommazahl durchführen will, lädt sie erst einmal alle benötigten Variablen und Konstanten in die Register der FPU. Dann werden die Berechnungen durchgeführt, um das korrekte Ergebnis zu erhalten. Gute C-Compiler können diesen Teil des Codes sehr gut optimieren.

Das Ergebnis wird "zurückgegeben", indem dieses auf dem TOS abgelegt wird. Vorher wird aufgeräumt. Sämtliche Variablen und Konstanten, die während der Berechnung verwendet wurden, werden dabei aus der FPU entfernt.

Was wir im vorherigen Abschnitt selber getan haben, kann so nicht durchgeführt werden: Wir haben das Quadrat des f–Wertes berechnet, und das Ergebnis für eine weitere Berechnung mit einer anderen Funktion auf dem Stack behalten.

Wir wußten, daß wir diesen Wert später noch einmal brauchen würden. Wir wußten auch, daß auf dem Stack genügend Platz war (welcher nur Platz für 8 Zahlen bietet), um den Wert dort zu speichern.

Ein C-Compiler kann nicht wissen, ob ein Wert auf dem Stack in naher Zukunft noch einmal gebraucht wird.

Natürlich könnte der C-Programmierer dies wissen. Aber die einzige Möglichkeit, die er hat, ist, den Wert im verfügbaren Speicher zu halten.

Das bedeutet zum einen, daß der Wert mit der FPU-internen, 80-stelligen Genauigkeit in einer normalen C-Variable vom Typ double (64 Bit) oder vom Typ single (32 Bit) gespeichert wird.

Dies bedeutet außerdem, daß der Wert aus dem TOS in den Speicher verschoben werden muß, und später wieder zurück. Von allen Operationen mit der FPU ist der Zugriff auf den Speicher die langsamste.

Wann immer also mit der FPU in einer Assemblersprache programmiert wird, sollte nach Möglichkeiten gesucht werden, Zwischenergebnisse auf dem Stack der FPU zu lassen.

Wir können mit dieser Idee noch einen Schritt weiter gehen! In unserem Programm verwenden wir eine Konstante (die wir `PC` genannt haben).

Es ist unwichtig, wieviele Lochblendendurchmesser wir berechnen: 1, 10, 20, 1000, wir verwenden immer dieselbe Konstante. Daher können wir unser Programm so optimieren, daß diese Konstante immer auf dem Stack belassen wird.

Am Anfang unseres Programmes berechnen wir die oben erwähnte Konstante. Wir müssen die Eingabe für jede Dezimalstelle der Konstanten durch `10` dividieren.

Multiplizieren geht sehr viel schneller als Dividieren. Wir teilen also zu Beginn unseres Programmes `1` durch `10`, um `0.1` zu erhalten, was wir auf dem Stack speichern: Anstatt daß wir nun für jede einzelne Dezimalstelle die Eingabe wieder durch `10` teilen, multiplizieren wir sie stattdessen mit `0.1`.

Auf diese Weise geben wir `0.1` nicht direkt ein, obwohl wir dies könnten. Dies hat einen Grund: Während `0.1` durch nur eine einzige Dezimalstelle dargestellt werden kann, wissen wir nicht, wieviele binäre Stellen benötigt werden. Wir überlassen die Berechnung des binären Wertes daher der FPU, mit dessen eigener, hoher Genauigkeit.

Wir verwenden noch weitere Konstanten: Wir multiplizieren den Lochblendendurchmesser mit `1000`, um den Wert von Millimeter in Micrometer zu konvertieren. Wir vergleichen Werte mit `10000`, wenn wir diese auf vier signifikante Stellen runden wollen. Wir behalten also beide Konstanten, `1000` und `10000`, auf dem Stack. Und selbstverständlich verwenden wir erneut die gespeicherte `0.1`, um Werte auf vier signifikante Stellen zu runden.

Zu guter letzt behalten wir `-5` noch auf dem Stack. Wir brauchen diesen Wert, um das Quadrat des f–Wertes zu skalieren, anstatt diesen durch `32` zu teilen. Es ist kein Zufall, daß wir diese Konstante als letztes laden. Dadurch wird diese Zahl die oberste Konstante auf dem Stack. Wenn später das Quadrat des f–Wertes skaliert werden muß, befindet sich die `-5` in `st(1)`, also genau da, wo die Funktion `fscale` diesen Wert erwartet.

Es ist üblich, einige Konstanten per Hand zu erzeugen, anstatt sie aus dem Speicher zu laden. Genau das machen wir mit der `-5`:

        	fld1			; TOS =  1
        	fadd	st0, st0	; TOS =  2
        	fadd	st0, st0	; TOS =  4
        	fld1			; TOS =  1
        	faddp	st1, st0	; TOS =  5
        	fchs			; TOS = -5

Wir können all diese Optimierungen in einer Regel zusammenfassen: Behalte wiederverwendbare Werte auf dem Stack!

> Tipp: PostScript® ist eine Stack-orientierte Programmiersprache. Es gibt weit mehr Bücher über PostScript, als über die Assemblersprache der FPU: Werden Sie in PostScript besser, dann werden Sie auch automatisch in der Programmierung der FPU besser.

## 11.13.5. pinhole—Der Code

    ;;;;;;; pinhole.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;
    ; Find various parameters of a pinhole camera construction and use
    ;
    ; Started:	 9-Jun-2001
    ; Updated:	10-Jun-2001
    ;
    ; Copyright (c) 2001 G. Adam Stanislav
    ; All rights reserved.
    ;
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    %include	'system.inc'

    %define	BUFSIZE	2048

    section	.data
    align 4
    ten	dd	10
    thousand	dd	1000
    tthou	dd	10000
    fd.in	dd	stdin
    fd.out	dd	stdout
    envar	db	'PINHOLE='	; Exactly 8 bytes, or 2 dwords long
    pinhole	db	'04,', 		; Bender's constant (0.04)
    connors	db	'037', 0Ah	; Connors' constant
    usg	db	'Usage: pinhole [-b] [-c] [-e] [-p <value>] [-o <outfile>] [-i <infile>]', 0Ah
    usglen	equ	$-usg
    iemsg	db	"pinhole: Can't open input file", 0Ah
    iemlen	equ	$-iemsg
    oemsg	db	"pinhole: Can't create output file", 0Ah
    oemlen	equ	$-oemsg
    pinmsg	db	"pinhole: The PINHOLE constant must not be 0", 0Ah
    pinlen	equ	$-pinmsg
    toobig	db	"pinhole: The PINHOLE constant may not exceed 18 decimal places", 0Ah
    biglen	equ	$-toobig
    huhmsg	db	9, '???'
    separ	db	9, '???'
    sep2	db	9, '???'
    sep3	db	9, '???'
    sep4	db	9, '???', 0Ah
    huhlen	equ	$-huhmsg
    header	db	'focal length in millimeters,pinhole diameter in microns,'
    	db	'F-number,normalized F-number,F-5.6 multiplier,stops '
    	db	'from F-5.6', 0Ah
    headlen	equ	$-header

    section .bss
    ibuffer	resb	BUFSIZE
    obuffer	resb	BUFSIZE
    dbuffer	resb	20		; decimal input buffer
    bbuffer	resb	10		; BCD buffer

    section	.text
    align 4
    huh:
    	call	write
    	push	dword huhlen
    	push	dword huhmsg
    	push	dword [fd.out]
    	sys.write
    	add	esp, byte 12
    	ret

    align 4
    perr:
    	push	dword pinlen
    	push	dword pinmsg
    	push	dword stderr
    	sys.write
    	push	dword 4		; return failure
    	sys.exit

    align 4
    consttoobig:
    	push	dword biglen
    	push	dword toobig
    	push	dword stderr
    	sys.write
    	push	dword 5		; return failure
    	sys.exit

    align 4
    ierr:
    	push	dword iemlen
    	push	dword iemsg
    	push	dword stderr
    	sys.write
    	push	dword 1		; return failure
    	sys.exit

    align 4
    oerr:
    	push	dword oemlen
    	push	dword oemsg
    	push	dword stderr
    	sys.write
    	push	dword 2
    	sys.exit

    align 4
    usage:
    	push	dword usglen
    	push	dword usg
    	push	dword stderr
    	sys.write
    	push	dword 3
    	sys.exit

    align 4
    global	_start
    _start:
    	add	esp, byte 8	; discard argc and argv[0]
    	sub	esi, esi

    .arg:
    	pop	ecx
    	or	ecx, ecx
    	je	near .getenv		; no more arguments

    	; ECX contains the pointer to an argument
    	cmp	byte [ecx], '-'
    	jne	usage

    	inc	ecx
    	mov	ax, [ecx]
    	inc	ecx

    .o:
    	cmp	al, 'o'
    	jne	.i

    	; Make sure we are not asked for the output file twice
    	cmp	dword [fd.out], stdout
    	jne	usage

    	; Find the path to output file - it is either at [ECX+1],
    	; i.e., -ofile --
    	; or in the next argument,
    	; i.e., -o file

    	or	ah, ah
    	jne	.openoutput
    	pop	ecx
    	jecxz	usage

    .openoutput:
    	push	dword 420	; file mode (644 octal)
    	push	dword 0200h | 0400h | 01h
    	; O_CREAT | O_TRUNC | O_WRONLY
    	push	ecx
    	sys.open
    	jc	near oerr

    	add	esp, byte 12
    	mov	[fd.out], eax
    	jmp	short .arg

    .i:
    	cmp	al, 'i'
    	jne	.p

    	; Make sure we are not asked twice
    	cmp	dword [fd.in], stdin
    	jne	near usage

    	; Find the path to the input file
    	or	ah, ah
    	jne	.openinput
    	pop	ecx
    	or	ecx, ecx
    	je near usage

    .openinput:
    	push	dword 0		; O_RDONLY
    	push	ecx
    	sys.open
    	jc	near ierr		; open failed

    	add	esp, byte 8
    	mov	[fd.in], eax
    	jmp	.arg

    .p:
    	cmp	al, 'p'
    	jne	.c
    	or	ah, ah
    	jne	.pcheck

    	pop	ecx
    	or	ecx, ecx
    	je	near usage

    	mov	ah, [ecx]

    .pcheck:
    	cmp	ah, '0'
    	jl	near usage
    	cmp	ah, '9'
    	ja	near usage
    	mov	esi, ecx
    	jmp	.arg

    .c:
    	cmp	al, 'c'
    	jne	.b
    	or	ah, ah
    	jne	near usage
    	mov	esi, connors
    	jmp	.arg

    .b:
    	cmp	al, 'b'
    	jne	.e
    	or	ah, ah
    	jne	near usage
    	mov	esi, pinhole
    	jmp	.arg

    .e:
    	cmp	al, 'e'
    	jne	near usage
    	or	ah, ah
    	jne	near usage
    	mov	al, ','
    	mov	[huhmsg], al
    	mov	[separ], al
    	mov	[sep2], al
    	mov	[sep3], al
    	mov	[sep4], al
    	jmp	.arg

    align 4
    .getenv:
    	; If ESI = 0, we did not have a -p argument,
    	; and need to check the environment for "PINHOLE="
    	or	esi, esi
    	jne	.init

    	sub	ecx, ecx

    .nextenv:
    	pop	esi
    	or	esi, esi
    	je	.default	; no PINHOLE envar found

    	; check if this envar starts with 'PINHOLE='
    	mov	edi, envar
    	mov	cl, 2		; 'PINHOLE=' is 2 dwords long
    rep	cmpsd
    	jne	.nextenv

    	; Check if it is followed by a digit
    	mov	al, [esi]
    	cmp	al, '0'
    	jl	.default
    	cmp	al, '9'
    	jbe	.init
    	; fall through

    align 4
    .default:
    	; We got here because we had no -p argument,
    	; and did not find the PINHOLE envar.
    	mov	esi, pinhole
    	; fall through

    align 4
    .init:
    	sub	eax, eax
    	sub	ebx, ebx
    	sub	ecx, ecx
    	sub	edx, edx
    	mov	edi, dbuffer+1
    	mov	byte [dbuffer], '0'

    	; Convert the pinhole constant to real
    .constloop:
    	lodsb
    	cmp	al, '9'
    	ja	.setconst
    	cmp	al, '0'
    	je	.processconst
    	jb	.setconst

    	inc	dl

    .processconst:
    	inc	cl
    	cmp	cl, 18
    	ja	near consttoobig
    	stosb
    	jmp	short .constloop

    align 4
    .setconst:
    	or	dl, dl
    	je	near perr

    	finit
    	fild	dword [tthou]

    	fld1
    	fild	dword [ten]
    	fdivp	st1, st0

    	fild	dword [thousand]
    	mov	edi, obuffer

    	mov	ebp, ecx
    	call	bcdload

    .constdiv:
    	fmul	st0, st2
    	loop	.constdiv

    	fld1
    	fadd	st0, st0
    	fadd	st0, st0
    	fld1
    	faddp	st1, st0
    	fchs

    	; If we are creating a CSV file,
    	; print header
    	cmp	byte [separ], ','
    	jne	.bigloop

    	push	dword headlen
    	push	dword header
    	push	dword [fd.out]
    	sys.write

    .bigloop:
    	call	getchar
    	jc	near done

    	; Skip to the end of the line if you got '#'
    	cmp	al, '#'
    	jne	.num
    	call	skiptoeol
    	jmp	short .bigloop

    .num:
    	; See if you got a number
    	cmp	al, '0'
    	jl	.bigloop
    	cmp	al, '9'
    	ja	.bigloop

    	; Yes, we have a number
    	sub	ebp, ebp
    	sub	edx, edx

    .number:
    	cmp	al, '0'
    	je	.number0
    	mov	dl, 1

    .number0:
    	or	dl, dl		; Skip leading 0's
    	je	.nextnumber
    	push	eax
    	call	putchar
    	pop	eax
    	inc	ebp
    	cmp	ebp, 19
    	jae	.nextnumber
    	mov	[dbuffer+ebp], al

    .nextnumber:
    	call	getchar
    	jc	.work
    	cmp	al, '#'
    	je	.ungetc
    	cmp	al, '0'
    	jl	.work
    	cmp	al, '9'
    	ja	.work
    	jmp	short .number

    .ungetc:
    	dec	esi
    	inc	ebx

    .work:
    	; Now, do all the work
    	or	dl, dl
    	je	near .work0

    	cmp	ebp, 19
    	jae	near .toobig

    	call	bcdload

    	; Calculate pinhole diameter

    	fld	st0	; save it
    	fsqrt
    	fmul	st0, st3
    	fld	st0
    	fmul	st5
    	sub	ebp, ebp

    	; Round off to 4 significant digits
    .diameter:
    	fcom	st0, st7
    	fstsw	ax
    	sahf
    	jb	.printdiameter
    	fmul	st0, st6
    	inc	ebp
    	jmp	short .diameter

    .printdiameter:
    	call	printnumber	; pinhole diameter

    	; Calculate F-number

    	fdivp	st1, st0
    	fld	st0

    	sub	ebp, ebp

    .fnumber:
    	fcom	st0, st6
    	fstsw	ax
    	sahf
    	jb	.printfnumber
    	fmul	st0, st5
    	inc	ebp
    	jmp	short .fnumber

    .printfnumber:
    	call	printnumber	; F number

    	; Calculate normalized F-number
    	fmul	st0, st0
    	fld1
    	fld	st1
    	fyl2x
    	frndint
    	fld1
    	fscale
    	fsqrt
    	fstp	st1

    	sub	ebp, ebp
    	call	printnumber

    	; Calculate time multiplier from F-5.6

    	fscale
    	fld	st0

    	; Round off to 4 significant digits
    .fmul:
    	fcom	st0, st6
    	fstsw	ax
    	sahf

    	jb	.printfmul
    	inc	ebp
    	fmul	st0, st5
    	jmp	short .fmul

    .printfmul:
    	call	printnumber	; F multiplier

    	; Calculate F-stops from 5.6

    	fld1
    	fxch	st1
    	fyl2x

    	sub	ebp, ebp
    	call	printnumber

    	mov	al, 0Ah
    	call	putchar
    	jmp	.bigloop

    .work0:
    	mov	al, '0'
    	call	putchar

    align 4
    .toobig:
    	call	huh
    	jmp	.bigloop

    align 4
    done:
    	call	write		; flush output buffer

    	; close files
    	push	dword [fd.in]
    	sys.close

    	push	dword [fd.out]
    	sys.close

    	finit

    	; return success
    	push	dword 0
    	sys.exit

    align 4
    skiptoeol:
    	; Keep reading until you come to cr, lf, or eof
    	call	getchar
    	jc	done
    	cmp	al, 0Ah
    	jne	.cr
    	ret

    .cr:
    	cmp	al, 0Dh
    	jne	skiptoeol
    	ret

    align 4
    getchar:
    	or	ebx, ebx
    	jne	.fetch

    	call	read

    .fetch:
    	lodsb
    	dec	ebx
    	clc
    	ret

    read:
    	jecxz	.read
    	call	write

    .read:
    	push	dword BUFSIZE
    	mov	esi, ibuffer
    	push	esi
    	push	dword [fd.in]
    	sys.read
    	add	esp, byte 12
    	mov	ebx, eax
    	or	eax, eax
    	je	.empty
    	sub	eax, eax
    	ret

    align 4
    .empty:
    	add	esp, byte 4
    	stc
    	ret

    align 4
    putchar:
    	stosb
    	inc	ecx
    	cmp	ecx, BUFSIZE
    	je	write
    	ret

    align 4
    write:
    	jecxz	.ret	; nothing to write
    	sub	edi, ecx	; start of buffer
    	push	ecx
    	push	edi
    	push	dword [fd.out]
    	sys.write
    	add	esp, byte 12
    	sub	eax, eax
    	sub	ecx, ecx	; buffer is empty now
    .ret:
    	ret

    align 4
    bcdload:
    	; EBP contains the number of chars in dbuffer
    	push	ecx
    	push	esi
    	push	edi

    	lea	ecx, [ebp+1]
    	lea	esi, [dbuffer+ebp-1]
    	shr	ecx, 1

    	std

    	mov	edi, bbuffer
    	sub	eax, eax
    	mov	[edi], eax
    	mov	[edi+4], eax
    	mov	[edi+2], ax

    .loop:
    	lodsw
    	sub	ax, 3030h
    	shl	al, 4
    	or	al, ah
    	mov	[edi], al
    	inc	edi
    	loop	.loop

    	fbld	[bbuffer]

    	cld
    	pop	edi
    	pop	esi
    	pop	ecx
    	sub	eax, eax
    	ret

    align 4
    printnumber:
    	push	ebp
    	mov	al, [separ]
    	call	putchar

    	; Print the integer at the TOS
    	mov	ebp, bbuffer+9
    	fbstp	[bbuffer]

    	; Check the sign
    	mov	al, [ebp]
    	dec	ebp
    	or	al, al
    	jns	.leading

    	; We got a negative number (should never happen)
    	mov	al, '-'
    	call	putchar

    .leading:
    	; Skip leading zeros
    	mov	al, [ebp]
    	dec	ebp
    	or	al, al
    	jne	.first
    	cmp	ebp, bbuffer
    	jae	.leading

    	; We are here because the result was 0.
    	; Print '0' and return
    	mov	al, '0'
    	jmp	putchar

    .first:
    	; We have found the first non-zero.
    	; But it is still packed
    	test	al, 0F0h
    	jz	.second
    	push	eax
    	shr	al, 4
    	add	al, '0'
    	call	putchar
    	pop	eax
    	and	al, 0Fh

    .second:
    	add	al, '0'
    	call	putchar

    .next:
    	cmp	ebp, bbuffer
    	jb	.done

    	mov	al, [ebp]
    	push	eax
    	shr	al, 4
    	add	al, '0'
    	call	putchar
    	pop	eax
    	and	al, 0Fh
    	add	al, '0'
    	call	putchar

    	dec	ebp
    	jmp	short .next

    .done:
    	pop	ebp
    	or	ebp, ebp
    	je	.ret

    .zeros:
    	mov	al, '0'
    	call	putchar
    	dec	ebp
    	jne	.zeros

    .ret:
    	ret

Der Code folgt demselben Aufbau wie alle anderen Filter, die wir bisher gesehen haben, bis auf eine Kleinigkeit:

> Wir nehmen nun nicht mehr an, daß das Ende der Eingabe auch das Ende der nötigen Arbeit bedeutet, etwas, das wir für zeichenbasierte Filter automatisch angenommen haben.

> Dieser Filter verarbeitet keine Zeichen. Er verarbeitet eine Sprache (obgleich eine sehr einfache, die nur aus Zahlen besteht).

> Wenn keine weiteren Eingaben vorliegen, kann das zwei Ursachen haben:

> - Wir sind fertig und können aufhören. Dies ist dasselbe wie vorher.

> - Das Zeichen, das wir eingelesen haben, war eine Zahl. Wir haben diese am Ende unseres ASCII –zu–float Kovertierungspuffers gespeichert. Wir müssen nun den gesamten Pufferinhalt in eine Zahl konvertieren, und die letzte Zeile unserer Ausgabe ausgeben.

> Aus diesem Grund haben wir unsere `getchar` - und `read`-Routinen so angepaßt, daß sie das `carry flag` clear immer dann zurückgeben, wenn wir ein weiteres Zeichen aus der Eingabe lesen, und das `carry flag` set immer dann zurückgeben, wenn es keine weiteren Eingabedaten gibt.

> Selbstverständlich verwenden wir auch hier die Magie der Assemblersprache! Schauen Sie sich `getchar` näher an. Dieses gibt immer das `carry flag` clear zurück.

> Dennoch basiert der Hauptteil unseres Programmes auf dem `carry flag`, um diesem eine Beendigung mitzuteilen—und es funktioniert.

> Die Magie passiert in `read`. Wann immer weitere Eingaben durch das System zur Verfügung stehen, ruft diese Funktion `getchar` auf, welche ein weiteres Zeichen aus dem Eingabepuffer einliest, und anschließend das `carry flag` cleart.

> Wenn aber `read` keine weiteren Eingaben von dem System bekommt, ruft dieses nicht `getchar` auf. Stattdessen addiert der op-Code `add esp, byte 4` `4` zu `ESP` hinzu, setzt das `carry flag`, und springt zurück.

> Wo springt diese Funktion hin? Wann immer ein Programm den op-Code `call` verwendet, `push`t der Mikroprozessor die Rücksprungandresse, d.h. er speichert diese ganz oben auf dem Stack (nicht auf dem Stack der FPU, sondern auf dem Systemstack, der sich im Hauptspeicher befindet). Wenn ein Programm den op-Code `ret` verwendet, `pop`t der Mikroprozessor den Rückgabewert von dem Stack, und springt zu der Adresse, die dort gespeichert wurde.

> Da wir aber `4` zu `ESP` hinzuaddiert haben (welches das Register der Stackzeiger ist), haben wir effektiv dem Mikroprzessor eine kleine Amnesie verpaßt: Dieser erinnert sich nun nicht mehr daran, daß `getchar` durch `read` aufgerufen wurde.

> Und da `getchar` nichts vor dem Aufruf von `read` auf dem Stack abgelegt hat, enthält der Anfang des Stacks nun die Rücksprungadresse von der Funktion, die `getchar` aufgerufen hat. Soweit es den Aufrufer betrifft, hat dieser `getchar` ge`call`t, welche mit einem gesetzten `carry flag` `ret`urned.

Des weiteren wird die Routine `bcdload` bei einem klitzekleinen Problem zwischen der Big–Endian- und Little–Endian-Codierung aufgerufen.

Diese konvertiert die Textrepräsentation einer Zahl in eine andere Textrepräsentation: Der Text wird in der Big–Endian-Codierung gespeichert, die packed decimal-Darstellung jedoch in der Little–Endian-Codierung.

Um dieses Problem zu lösen haben wir vorher den op-Code `std` verwendet. Wir machen diesen Aufruf später mittels `cld` wieder rückgängig: Es ist sehr wichtig, daß wir keine Funktion mittels `call` aufrufen, die von einer Standardeinstellung des Richtungsflags abhängig ist, während `std` ausgeführt wird.

Alles weitere in dem Programm sollte leicht zu verstehen sein, vorausgesetzt, daß Sie das gesamte vorherige Kapitel gelesen haben.

Es ist ein klassisches Beispiel für das Sprichwort, daß das Programmieren eine Menge Denkarbeit, und nur ein wenig Programmcode benötigt. Sobald wir uns über jedes Detail im klaren sind, steht der Code fast schon da.

## 11.13.6. Das Programm pinhole verwenden

Da wir uns bei dem Programm dafür entschieden haben, alle Eingaben, die keine Zahlen sind, zu ignorieren (selbst die in Kommentaren), können wir jegliche textbasierten Eingaben verarbeiten. Wir müssen dies nicht tun, wir könnten aber.

Meiner bescheidenen Meinung nach wird ein Programm durch die Möglichkeit, anstatt einer strikten Eingabesyntax textbasierte Anfragen stellen zu können, sehr viel benutzerfreundlicher.

Angenommen, wir wollten eine Lochkamera für einen 4x5 Zoll Film bauen. Die standardmäßige Brennweite für diesen Film ist ungefähr 150mm. Wir wollen diesen Wert optimieren, so daß der Lochblendendurchmesser eine möglichst runde Zahl ergibt. Lassen Sie uns weiter annehmen, daß wir zwar sehr gut mit Kameras umgehen können, dafür aber nicht so gut mit Computern. Anstatt das wir nun eine Reihe von Zahlen eingeben, wollen wir lieber ein paar Fragen stellen.

Unsere Sitzung könnte wie folgt aussehen:

    % pinhole

    Computer,

    Wie groß müßte meine Lochblende bei einer Brennweite
    von 150 sein?
    150	490	306	362	2930	12
    Hmmm... Und bei 160?
    160	506	316	362	3125	12
    Laß uns bitte 155 nehmen.
    155	498	311	362	3027	12
    Ah, laß uns 157 probieren...
    157	501	313	362	3066	12
    156?
    156	500	312	362	3047	12
    Das ist es! Perfekt! Vielen Dank!
    ^D

Wir haben herausgefunden, daß der Lochblendendurchmesser bei einer Brennweite von 150 mm 490 Mikrometer, oder 0.49 mm ergeben würde. Bei einer fast identischen Brennweite von 156 mm würden wir einen Durchmesser von genau einem halben Millimeter bekommen.

## 11.13.7. Skripte schreiben

Da wir uns dafür entschieden haben, das Zeichen `#` als den Anfang eines Kommentares zu interpretieren, können wir unser pinhole-Programm auch als Skriptsprache verwenden.

Sie haben vielleicht schon einmal shell-Skripte gesehen, die mit folgenden Zeichen begonnen haben:

    #! /bin/sh

...oder...

    #!/bin/sh

... da das Leerzeichen hinter dem `#!` optional ist.

Wann immer UNIX eine Datei ausführen soll, die mit einem `#!` beginnt, wird angenommen, das die Datei ein Skript ist. Es fügt den Befehl an das Ende der ersten Zeile an, und versucht dann, dieses auszuführen.

Angenommen, wir haben unser Programm pinhole unter /usr/local/bin/ installiert, dann können wir nun Skripte schreiben, um unterschiedliche Lochblendendurchmesser für mehrere Brennweiten zu berechnen, die normalerweise mit 120er Filmen verwendet werden.

Das Skript könnte wie folgt aussehen:

    #! /usr/local/bin/pinhole -b -i
    # Find the best pinhole diameter
    # for the 120 film

    ### Standard
    80

    ### Wide angle
    30, 40, 50, 60, 70

    ### Telephoto
    100, 120, 140

Da ein 120er Film ein Film mittlerer Größe ist, könnten wir die Datei medium nennen.

Wir können die Datei ausführbar machen und dann aufrufen, als wäre es ein Programm:

    % chmod 755 medium
    % ./medium

UNIX wird den letzten Befehl wie folgt interpretieren:

    % /usr/local/bin/pinhole -b -i ./medium

Es wird den Befehl ausführen und folgendes ausgeben:

    80	358	224	256	1562	11
    30	219	137	128	586	9
    40	253	158	181	781	10
    50	283	177	181	977	10
    60	310	194	181	1172	10
    70	335	209	181	1367	10
    100	400	250	256	1953	11
    120	438	274	256	2344	11
    140	473	296	256	2734	11

Lassen Sie uns nun das folgende eingeben:

    % ./medium -c

UNIX wird dieses wie folgt behandeln:

    % /usr/local/bin/pinhole -b -i ./medium -c

Dadurch erhält das Programm zwei widersprüchliche Optionen: `-b` und `-c` (Verwende Benders Konstante und verwende Connors Konstante). Wir haben unser Programm so geschrieben, daß später eingelesene Optionen die vorheringen überschreiben—unser Programm wird also Connors Konstante für die Berechnungen verwenden:

    80	331	242	256	1826	11
    30	203	148	128	685	9
    40	234	171	181	913	10
    50	262	191	181	1141	10
    60	287	209	181	1370	10
    70	310	226	256	1598	11
    100	370	270	256	2283	11
    120	405	296	256	2739	11
    140	438	320	362	3196	12

Wir entscheiden uns am Ende doch für Benders Konstante. Wir wollen die Ergebnisse im CSV-Format in einer Datei speichern:

    % ./medium -b -e > bender
    % cat bender
    focal length in millimeters,pinhole diameter in microns,F-number,normalized F-number,F-5.6 multiplier,stops from F-5.6
    80,358,224,256,1562,11
    30,219,137,128,586,9
    40,253,158,181,781,10
    50,283,177,181,977,10
    60,310,194,181,1172,10
    70,335,209,181,1367,10
    100,400,250,256,1953,11
    120,438,274,256,2344,11
    140,473,296,256,2734,11
    %

Zurück | Zum Anfang | Weiter
One-Pointed Mind | Nach oben | Vorsichtsmassnahmen

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.