“Speicherorganisation”
RISC die Dritte..
Das dritte Kapitel beschaeftigt sich mit der Speicherorganisation
Die RISC Prozessoren werden immer schneller,die Speicher zwar auch,aber nicht in dem Tempo…muessen die RISC CPU’s deshalb verhungern? Sogar CISC Prozessoren wie der 80386 lassen sich oberhalb 20 MHz nicht mehr mit vertretbaren Aufwand “ausfahren” (Brummmm..). Wird also pures RISC an der Busbreite von Speichersystemen mit dynamischen RAMs scheitern, wie man in letzter Zeit immer wieder in der Diskussion pro CISC hoeren kann? Die Antwort ist nein (Wie kanns anders sein bei einer rethorischen Frage!), denn die Rechnerarchitektur hat sich eine Vielzahl von Organisa- tionsformen einfallen lassen, die dieses Problem weitgehend loesen. Erster Schritt ist die Bereitstellung genuegend Register fuer Daten auf dem Prozessorchip, so dass die Zugriffe auf den Hauptspeicher drastisch reduziert werden. Eine Vielzahl unterschiedlicher Techniken wurden hier vorgeschlagen und inzwischen auch realisiert. Die einfachste Variante stellt eine grosse Registerdatei mit beispielsweise 32 Registern zur Verfuegung. Beim Aufruf einer neuen Prozedur muessen fuer diese neue Register bereitgestellt werden, was Speicherzugriffe nach sich zieht. Aus diesem Grund haben andere Entwickler Mehrfach-Registerdateien imple- mentiert, d.h.,pro Prozessor existieren beispielsweise acht Registerda- teien a 32 Registern. Beim Prozeduraufruf schaltet der Prozessor nun nur noch von einer Registerdatei zu anderen um. Die Idee der Mehrfach- Registerdateien laesst sich sogar noch weiter treiben: Ausgabeparameter der aufrufenden Prozedur sind Eingabeparameter der aufgerufenen. Um das Kopieren dieser Daten zwischen den Dateien einsparen zu koennen laesst man sie sich ueberlappen. Bei gleicher Anzahl von Registerdateien kostet dies dann auch weniger Register.Schliesslich benoetigt nicht jede Prozedur eine gleich Anzahl von lokalen Variablen. Man kann die Registerdateien also auch als Dateien versch. Groesse ansehen und orga- nisiert sie dann stapelartig (zu.Dt:Stack orientiert), auf eine physikalische Datei abgebildet. Damit ist der Gedanke des Register-Stapel- Caches geboren. Der normalerweise im Hauptspeicher untergebrachte Lauf- zeitstack zu einem Programm befindet sich bezuglich seines obersten Ab- schnittes physikalisch jeweils in der Registerdatei. Die Register sind zusaetzlich zu ihrer Organisation als Register noch wie ein Stack orga- niesiert und realisieren auf derselben physikalischen Registermenge diese beiden Funktionen. Ein nachziehen von Informationen aus dem Speicher ist also deutlich seltener notwendig. Der dem gegenueberstehende Aufwand fuer die Hardware zur Registeradressberechnung ist vergleichsweise gering. Heutige RISC Prozessoren wie der AMD 29000 stellen fuer diese Funktionen einige hundert (100) Register zur Verfuegung. Die Lokalitaet von Daten und Programmen wird auf jeden Fall durch Cache-Speichertechniken ausge- nutzt. In neusten RISC Prozessoren findet sich der Cachespeicher bereits auf dem Chip,andere Prozessoren sehen dafuer spezielle Bausteine vor (wie der M88000 mit seinen zwei 88100ern).
Der geniale Rechnerarchitekturgedanke des Von-Neumann-Rechners (ein gemeinsamer Hauptspeicher fuer Programme und Daten) wird zugunsten der Harvard-Architektur aufgegeben. D.h, Programme und Daten werden aus ge- trennten Caches bzw. Hauptspeichern uebernommen,womit sie natuerlich auch gleichzeitig zugreifbar sind.Das erfordert am RISC Prozessor getrennte Instruktions und Datenbusse, ggf. sieht man auch getrennte Adressbusse vor. Pufferspeicher wie Cachespeicher verwnden beim Nachladen in der Regel Block- und nicht Einzelwortzugriffe. Entsprechend sind auch die Busse fuer RISC Prozessoren organisiert. In vielen Faellen ist der Blockzugriff auf die Eigenschaften von der dynamischen Speichern zugeschnitten. Durch Verbreiterung der Busse ausserhalb (von 32 auf 64 Bit) und innerhalb der Chips (auf bis zu 128 Bit, INTEL 860) wird die Zugriffsgeschwindigkeit weiter gesteigert. Ferner finden auf Busebene transaktionsorientierte oder Paketbus-Strategien Anwendung. Der Prozessor vergibt sozusagen Speicherzugriffsauftraege, um deren Abwicklung sich eigenstaendige Logik kuemmern muss. Auch fuer die Maschienenbefehle,die dem Leitwerk der Pro- zessoren zugefuegt werden muessen,sieht man weitere Speicherhirachien vor. Jeder Prozessor verfuegt ueber einen Befehlspufferbereich (Look Ahead), in dem die naechsten sequentiell auszufuehrenden Maschienenbefehle stehen. Die nachteilige Wirkung von Verzweigungen beim Pipelining dem Maschienen- befehlszyklus durch Verzoegerung des angesprungenen Maschienenbefehls aus dem Hauptspeicher wird durch spezielle Sprungziehcaches (Branch Target Caches) verringert. Einmal angesprungene Sprungziele und einige darauf- folgende Befehle werden in diesen Caches abgespeichert. Insbesondere bei den haeufig auftretenden Schleifenkonstruktionen, wo immer wieder an den Anfang der Programmschleife gesprungen wird, eruebrigt sich dann das Nachholen der nicht sequentiell ausgefuehrten Befehle. Die vielen im Prozessorbereich abgespeichererten Informationen sind beim Taskswitch andererseits kontraproduktiv: Die gesamte Information zum deaktivierten Prozess muss in den Hauptspeicher gerettet, die Information fuer den aufgerufenen Prozess aus dem Speicher aufgebaut werden. Um diesen Effekt zumindest bei einem Kontextswitch fuer die haeufig zu erwartende Unter- brechungsbehandlungen zu minimieren, friert man den Prozessorzustand in vielen Faellen ein, bietet spezielle Zwischenspeicherbereiche fuer Unterbrechungsbehandlungsroutinen an. Der AMD 29000 z.B. kennt drei Varianten der Interruptbehandlung: Fuer besonders schnelle Anforderungen gibt es einen Modus,in dem keinerlei Sicherung des Prozess-Kontextes er- folgt, wobei aber der Befehlssatz stark eingeschraenkt und kein Zugriff auf Register erlaubt ist. Eine zweite Betriebsart sichert teilweise den Kontext und laesst dementsprechend mehr Befehle zu, erst die dritte Variante stellt einen volstaendigen Kontextswitch dar. Offentsichtlichwird die Programmierung von RISC Architekturen wegen der hohen Komplexitaet der Basishardware nicht einfacher, aber das macht auch nichts: Niemand soll auf maschienenebene Programmieren (da geht zwar ganz- schoen was an Feeling verlohren,aber was tut man nicht alles…), die Programmerstellung erfolgt in Hochsprache, und “the Compiler will know”. Dennoch entstehen natuerlich neue Probleme. Die vom Compiler generierte optimierte Maschienensequenz ist bei der Fehlersuche kaum mehr fuer den Programmierer verstaendlich. Meist wird daher das Programm zunaechst in nicht optimierter Form ausgetestet, erst dann eine optimierte Version erstellt (was die abschaltbare Optimierung erklaehrt,die eigentl. wenig einleutet,ne!). Langfristig wird man aber auch um quellbezogene Debugger fuer optimierende Compiler nicht herumkommen. Wie Du siehst nichts geht zu Ende…alles bewegt sich! (Mein Gott,jetzt werde ich auch noch philosophisch…Zeit zum Aufhoeren.) Also dies ist das Ende des Speicherverwaltungkapitels. Fortsetzung demnaechst auf diesem Bildschirm…
mfg AXEL