5. Weitere Konzepte. Ganz grob sieht das Innenleben des INTEL 8086 so aus:

Transkript

1 5. Weitere Konzepte Fast alles, was am Beispiel des LC1 erklärbar ist, haben wir auch am Beispiel des LC1 kennengelernt. Reale Rechner "können" eine ganze Menge mehr. Davon werde ich heute einiges behandeln. Ich lehne mich zunächst an den Mikroprozessor INTEL 8086 an, einen Mikroprozessor, der als "Urvater" der PCs gelten kann. Ganz grob sieht das Innenleben des INTEL 8086 so aus: 76

2 Im Vergleich zum LC1 finden wir zunächst keinen Speicher - er befindet sich außerhalb des Prozessors. Dann finden wir einiges, was uns bekannt vorkommt: Ein Rechenwerk (Execution Unit, 16 Bit Verarbeitungsbreite) mit einer ALU, einer Reihe von Flags und (allerdings sehr viel mehr) Registern, darunter ein Akkumulator (AX, AH, AL) und ein Stack Pointer SP (beim LC1 im Steuerwerk). Es gibt ein Steuerwerk (Control & Timing). Den Programm Counter (hier: Instruction Pointer IP) finden wir in der sog. Bus Interface Unit, die uns nicht weiter interessieren soll. Für das vorbereitende Befehlslesen finden wir außerdem noch eine sog. Prefetch Queue. Die Register sind eine genauere Betrachtung wert. (Arithmetische, logische und sonstige) Operationen mit Registern sind deutlich schneller als Speicheroperationen. Ein Assemblerprogrammierer wird deshalb bestrebt sein, soviel wie möglich mit den Registern zu erledigen. Dafür sind die allgemeinen Register vorgesehen. Die Bezeichnung läßt vermuten, daß die Register für den Programmierer stets frei verfügbar sind. Über weite Strecken ist das tatsächlich so. Es zeigt sich aber, daß einige Maschinenbefehle bestimmte dieser Register in einer ausgezeichneten Weise nutzen. Details würden zu weit führen. Angemerkt muß aber 77

3 werden, daß ein Assemblerprogrammierer sehr sorgfältig mit diesen Registern umgehen muß. Die anderen Register sind für spezielle Aufgaben reserviert. Wir wollen uns nur das Flagregister etwas genauer ansehen: Neben den uns bereits bekannten Flags CF, OF und SF finden wir weitere Flags (ZF, AF,...) Zum Abschluß noch ein Blick auf die Anschlüsse des INTEL

4 5.1. Adressierungsmodi Unter einem Adressierungsmodus wollen wir die Art und Weise der Angabe einer (Operanden-)Adresse in einem Maschinenbefehl verstehen. Beim LC1 haben wir einen speziellen Adressierungsmodus kennengelernt. Dort wird in den Maschinenbefehlen die Adresse der Speicherzelle, von welcher der Operand gelesen werden soll (LDA, LDB) bzw. in welche der Operand geschrieben werden soll (MOV), direkt angegeben. Man spricht deshalb von direkter Adressierung BR opc opdadr MEMORY Wir haben aber auch kennengelernt, daß die direkte Adressierung bereits bei der Verarbeitung eines eindimensionalen Arrays unangenehme "Klimmzüge" verlangt. Wir haben dafür die Befehlsmodifikation gebraucht. Es ist gut vorstellbar, daß die Programmierung umso umständlicher wird, je komplexer die zu behandelnden Datenstrukturen sind (z. B. ein mehrdimensionales Array aus Records). Höhere Programmiersprachen erlauben die Verwendung sehr komplexer Datenstrukturen. Die sog. CISC-Prozessoren (CISC = complex instruction set computer, der INTEL 8086 ist ein solcher) wollen die Verarbeitung komplexer Datenstrukturen so gut wie möglich hardwaremäßig unterstützen. Die semantische Lücke zwischen dem, was der Prozessor "versteht", und dem, was die höhere Programmiersprache zu formulieren erlaubt, wird damit verringert. Schließen muß die Lücke ein Compiler, der aus der höheren Programmiersprache in die Maschinensprache des Prozessors übersetzt. Anm.: RISC-Prozessoren (RISC = reduced instruction set computer) gehen einen anderen Weg. Die hardwaremäßige Unterstützung komplexer Datenstrukturen ist dort sehr be- 79

5 scheiden. Die Hauptlast trägt der Compiler, da die durch ihn zu überbrückende semantische Lücke sehr viel größer ist. Mit RISC-Prozessoren befassen wir uns hier nicht. Am Beispiel des LC1 und des INTEL 8086 wollen wir versuchen, die verschiedenen Adressierungsmodi zu ordnen und einige von ihnen kennenzulernen: 1. In welcher Ressource liegt der Operand? Registeradressierung Speicheradressierung 2. Ist die Operandenadresse im Maschinenbefehl explizit anzugeben (und ist damit variabel!) oder folgt die Operandenadresse implizit aus dem Operationscode (und ist damit fest!)? explizite Adressierung implizite Adressierung Der LC1 hat zwei Adressierungsmodi implizite Registeradressierung Bei keinem der LC1-Befehle wird im Feld opdadr explizit angegeben, in welchem Register der Operand liegt. Falls der Operand in einem der beiden Register liegt, folgt das unveränderbar aus dem Operationscode des Befehls (LDA, LDB, MOV, ADD, SUB,...) explizite Speicheradressierung Falls ein Operand im Speicher liegt, muß die Adresse der betreffenden Speicherzelle explizit im Feld opdadr angeben werden. Von den beiden fehlenden Kombinationen ist die explizite Registeradressierung immer dann nötig, wenn - wie beim INTEL mehrere Register zur Wahl stehen. Eine Variante der impliziten Speicheradressierung kennen wir bereits vom LC1: Die Befehle CAL und RET greifen auf den Speicher zu, ohne daß die Adresse im Befehl explizit angegeben werden muß! 3. Adressierungsmodi im engeren Sinne sind die Varianten der expliziten Speicheradressierung (s. INTEL 8086) opc = Operationscode adr = Speicheradresse (Angabe im Befehl) madr = Speicheradresse (physisch) reg = Register breg = Basisregister ireg = Indexregister displ = Displacement (Offset, Verschiebung) 80

6 direkte Adressierung: madr = adr adr Speicher madr opc (register-)indirekte Adressierung: madr = <reg reg Register Speicher madr opc Basisadressierung: madr = <breg+displ breg displ opc madr Register Speicher Indexadressierung: madr = <ireg+displ ireg displ opc madr Register Speicher basisindizierte Adressierung: madr = <breg+<ireg+displ opc breg ireg displ Register madr Speicher Wozu ist denn das nun alles gut? Überlegen Sie selbst, welchen Vorteil die "neuen" Adressierungsmodi für die Verarbeitung von Arrays, Records und Arrays von Records bringen! Beziehen Sie in Ihre Überlegungen ein, daß Registerbefehle deutlich schneller sind als Speicherbefehle. 4. Bei Sprungbefehlen unterscheidet man zwischen absoluter und relativer Adressierung absolute Adressierung: <PC := adr, madr := <PC adr PC Speicher madr opc 81

7 relative Adresssierung: <PC := <PC + adr, madr := <PC adr opc PC Speicher madr O Warum? 5.2. Interruptsystem Das Interruptsystem des INTEL 8086 verfügt über Möglichkeiten, deren Fehlen wir beim LC1 bereits beklagt haben, und über weitere Eigenschaften, die wir an einer sehr vereinfachten, schematischen Darstellung diskutieren wollen. NMI = non maskable interrupt weitere (interne) INTR = interrupt request Interruptquellen NMI O S FF Q RESET oder O R Int.-Behandlg. OR AND INTR O AND Auslösen S FF Q AND des Interrupts O R Probleme STI S FF Q (Befehl!) IF weitere OR R (Flag!) interne CLI Int.- (Befehl!) Quellen O letzter Taktzyklus des aktuellen Maschinenbefehls Wir betrachten im weiteren nur den maskierbaren Interrupt. Da nur eine Interruptleitung (INTR) vorhanden ist, bestehen für den Fall, daß mehr als eine Interruptquelle vorhanden ist (das ist der Regelfall!), zwei Probleme: 1. Die Interruptbehandlung ist abhängig von der Art der Interruptquelle. Der Prozessor muß also erfahren, welche Interruptquelle ihn unterbrochen hat, die Interruptquelle muß sich identifizieren. 2. Wenn mehr als eine Interruptquelle gleichzeitig eine Interruptanforderung stellen, muß eine Prioritätsregel gelten. 82

8 Diese beiden Aufgaben, die Identifizierung und die Priorisierung, übernimmt beim INTEL 8086 ein sog. Interruptcontroller (I8259). Ich kann aus Zeitgründen wieder nur eine sehr vereinfachte, schematische Darstellung geben: 8 externe INTR = interrupt request Interrupt- INTA = interrupt acknowledge quellen Quelle 0 IRQ0 I8259 INTR INTR INTEL 8086 Quelle 1 IRQ1 INTA < INTA Quelle 2 IRQ2 Quelle 3 IRQ3 Quelle 4 IRQ4 8 Quelle 5 IRQ5 D7..0 / AD7..0 Quelle 6 IRQ6 Quelle 7 IRQ7 Interruptcontroller Prozessor Die acht (durch Kaskadierung max. 64) voneinander unabhängigen externen Interruptquellen (Quelle 0 bis Quelle 7; irgendwelche peripheren Geräte) melden ihre Interruptanforderungen beim Interruptcontroller an (IRQi = 1). Der Interruptcontroller meldet die Interruptanforderung(en) beim Prozessor an (INTR = IRQ0 v IRQ1 v..., d.h. sobald eine oder mehrere Interruptquellen eine Interruptanforderung stellen, wird der Prozessor davon informiert. Dem Prozessor ist zu diesem Zeitpunkt noch nicht bekannt, wieviele und welche Interruptquellen eine Interruptanforderung stellen). Der Prozessor nimmt die Interruptanforderung nur an, wenn das Interruptflag gesetzt ist (IF = 1, s. o.). Falls er sie annimmt, teilt er das dem Interruptcontroller mit INTA = 1 mit. Der Interruptcontroller legt daraufhin einen sog. Interruptvektor (ein 8-Bit-Vektor, der die Interruptquelle eindeutig identifiziert) auf den Datenbus D Diesen Interruptvektor liest der Prozessor ein und interpretiert ihn als Zeiger auf den Anfang der interruptquellenspezifischen Interruptbehandlungsroutine (ISR), genauer s. u. Der Interruptcontroller ist programmierbar. Jeder Interruptquelle wird ein spezifischer Interruptvektor zugeordnet. Zwischen den Interruptquellen sind verschieden Vorrangregeln wählbar (Priorisierung!). In jedem Falle ist gesichert, daß unabhängig davon, ob nur eine oder mehrere Interruptquellen eine Interruptanforderung stellen, nur die (gerade) höchstpriorisierte Interruptquelle ausgewählt und über den ausgesendeten Interruptvektor dem Prozessor bekannt gemacht wird. Interruptvektortabelle Der 8-Bit-Interruptvektor kann Werte zwischen 0 und 255 annehmen. Der Prozessor multipliziert den vom Datenbus empfangenen Interruptvektor mit dem Wert 4 (d. h. er hängt rechts zwei Nullen an!) und interpretiert diesen Wert als Zeiger in die sog. Interruptvektortabelle (am unteren Ende des Speichers) und findet dort einen Zeiger auf den Anfang der zugehörigen ISR. 83

9 D Interruptvektor * 4 V V V V O O O O "far pointer" Ablauf V V V V ISR0 ISR1 ISR254 ISR255 Um das Verfahren noch etwas deutlicher zu machen, gebe ich wieder eine sehr vereinfachte, schematische Darstellung des Ablaufs einer Interruptbehandlung an: < letzter Taktzyklus n des aktuellen Befehls? j (nur bei STI, Nesting) j j INTR-FF gesetzt? IF = 1? n n Interruptvektor lesen < PUSHF (Flags) < IF := 0 nächsten Befehl holen PUSH CS vgl. und ausführen PUSH IP CALL PUSH Register (ggf. STI) eigentliche ISR POP Register IRET POP IP POP CS POPF (Flags) 5.3. Ein-/Ausgabe Einführung Bisher haben wir uns auf die Prozessor"innereien" konzentriert. Nur bei den Ausführungen zum Unterbrechungssystem klang durch, daß da irgendwie eine Kommunikation zwischen Prozessor und Aussenwelt stattfinden muß. Daten, die ein Prozessor verarbeiten soll, müssen in den Prozessor eingegeben werden, und die Verarbeitungsergebnisse müssen vom Prozessor ausgegeben werden. Für die Eingabe- und die Ausgabe von Daten sind eine Vielzahl unterschiedlichster Geräte entwickelt worden, die eine optimale Anpassung zwischen Prozessor und Außenwelt gewährleisten: 84

10 Eingabegeräte: - Tastatur, Maus, Trackball, Joystick - Lochkartenleser, Lochbandleser - Scanner - CD-Laufwerk - (grafisches) Tablett - Meßgeräte, Mikrofon, Kamera, Sensoren Ausgabegeräte: - Lochkartenstanzer, Lochbandstanzer - Drucker, Monitor - Lautsprecher - Beamer - Werkzeugmaschinen (NC) - Aktoren ((Schritt-)Motor, Relais,...) Ein-/Ausgabegeräte: - Magnetbandspeicher (z. B. Streamer) - Floppy Disk - Hard Disk (früher: Magnetplattenspeicher) - Telefon u.s.w. Ihnen fallen sicher weitere Beispiele ein. Um mit der Außenwelt kommunizieren zu können, müssen alle diese - höchst unterschiedlichen - Geräte (auch: periphere Geräte) an den Prozessor angeschlossen werden können. Eingabegerät < Prozessor Ausgabegerät < Ein-/Ausgabegerät Von Ausnahmen abgesehen, werden Prozessoren und periphere Geräte von unterschiedlichen Produzenten geliefert. Das ruft nach Standardisierung der Schnittstellen. Von solchen Schnittstellen (auch: Interfaces oder Standard-Interfaces) gibt es aber mittlerweile eine kaum überschaubare Anzahl. Def.: Ein Standard-Interface ist die Gesamtheit elektrischer, konstruktiver, logischer und zeitlicher Bedingungen ("Protokoll"), die die Koppelbarkeit zweier Einheiten (z. B. eines Prozessors und eines peripheren Geräts) gewährleisten. Um zu verhindern, daß die Dynamik des Marktes der peripheren Geräte auf den Markt der Prozessoren durchschlägt, und um zu gewährleisten, daß ein und dasselbe periphere Gerät an unterschiedliche Prozessoren anschließbar ist, hat man E/A-Einheiten (früher auch: "Kanäle") entwickelt, die die Schnittstellen der peripheren Geräte auf die Schnittstelle des Prozessors, d. h. den Prozessorbus, umsetzt. 85

11 Prozessorbus < E/A-Einheit < Eingabegerät Prozessor < E/A-Einheit Ausgabegerät < E/A-Einheit < Ein-/Ausgabegerät Diese E/A-Einheiten werden in der Regel als Ergänzungskomponenten der Prozessoren angeboten oder sind bereits Bestandteil des Prozessors ("on chip"). Prozessorseitig bedienen sie das Busprotokoll, peripherieseitig sind sie meist programmierbar und damit an verschiedene Interfaces bzw. Protokolle anpaßbar E/A-Einheiten Da die Verhältnisse beim INTEL 8086 doch recht kompliziert werden, wähle ich hier einen einfacheren Mikrorechner, den MARK2. Der MARK2 hat drei E/A-Einheiten und vier E/A-Schnittstellen: - zwei Register I8212, die die zwei byteparallelen Schnittstelle SYSIN (byteparallele Eingabe) und SYSOUT (byteparallele Ausgabe) bedienen. - einen UART (Universal Asynchronous Receiver/Transmitter), der zwei bitserielle Schnittstellen SERIN (bitserielle Eingabe) und SEROUT (bitserielle Ausgabe) bedient 86

12 < SERIN UART SEROUT 8 MARK2 I8212 < / SYSIN I / SYSOUT Aus Zeitgründen gehe ich hier nur auf die byteparallele Ein- /Ausgabe ein. Um uns an die Denkweise zu gewöhnen, gehen wir vom Einfachen zum Komplizierten und beginnen mit der Byteparallelen Ausgabe Byteparallele Ausgabe Der Schaltkreis I8212 ist ein universeller 8-Bit-Bustreiber, der so in den meisten gängigen 8-Bit-Mikroprozessorsystemen (I8080, Z80,...) zum Einsatz kam. Je nach Beschaltung dient er als Eingabe"tor" oder als Ausgabe"puffer", bei der byteparallelen Ausgabe ist er Ausgabepuffer Byteparallele Eingabe Für die byteparallele Eingabe kommt wieder ein I8212 zum Einsatz, der hier jedoch als Eingabetor dient. Hardware und Ablauf sind nicht mehr ganz so einfach wie bei der byteparallelen Ausgabe. 87

13 88