Ich glaube das war die erste Mail ins frisch geründete Brett. Heute würde man das wohl als “newsgroup-FAQ” bezeichnen. Datum des Textes war irgendwann 1989…

Hallo Ihr, die Ihr neugierig seid, was hier abgeht

Also wie der Name schon sagt, das ist das Prozessorbrett. Noch so n’
unnötiges Brett? Keineswegs! Erstens gehört dieses Brett schon in die
Zeit der 7*up von der man nur noch aus Sagen und Legenden weis und
zweitens lässt sich sowieso über alles streiten.
Es geht wie gesagt um Prozessoren und all den Kram außenrum. Es wird
meinerseits DREI Kategorien von Mails geben:

* Der Bericht
————-
Meißt über einen Prozessor oder seine Famile im Speziellen oder über einen
neuen Denkansatz (CISC,RISC,FUZZY,etc…). Der Bericht hat keinen
praktischen Nutzen außer Deiner weiterbildung…

* Der Praxistest
—————-
Da steht drin, was alle irgendwie nachvollziehen können. Wie man den
besten Co-Proz. wählt, welcher Chipssatz der momentan Beste ist,etc.

* Splitter
———-
Was gerade so reinkommt und nicht in die beiden anderen Kathegorieen
passt oder vom Umfang zu gering ist. NEWS z.B.

Ich versuche mir Mühe zu geben dieses Prinzip durchzuhalten (zwecks
besserer Übersicht) und setzte in der Betreffzeile immer “B.” für
Bericht, “P.” für Praxis und “S.” für Splitter vornean.

Nichtsdestotroz ist JEDER aufgefordert seinen Senf dazuzugeben. Für
die Phantasielosen unter Euch wäre da z.B. die KRITIK oder der BEIFALL
als Möglichkeiten zu nennen. Evtl. lässt sich der ein oder andere
inhaltliche Beitrag blicken???

Das war’s…jetzt gehts los. Neue Texte erscheinen in loser Folge, also
nicht meckern wenn mal ne’ Woche nix passiert!

mfg AXEL

Grundsatztext über Benchmarks und CPU-Vergleiche. Dieses Thema wird wohl immer aktuell bleiben. “MIPS” als Größe ist heute allerdings nicht mehr aktuell.[27.05.1990]

New Year, new Band, new Company….

MIPS, VUPS, KWIPS und MFLOPS…

Was sich anhoert wie “ein Kilo Schronz mit Ranz und Blonk” ist, wie wir alle wissen die km/h Angabe der “Gombutawelt”. Spass beiseite! Wie ihr auch schon hier im Proz.Brett gemerkt habt, dreht sich eine Menge um die magischen Begriffe “MIPS” etc.. Jeder weiss, dass das Million Instructions Per Second heisst, kann aber im Prinzip nicht mehr damit anfangen als Quartett spielen (“Erster im Stechen, ohne Streit!”). Also eigentlich gibts da ja nicht soviel zu berichten, MIPS ist MIPS, is’ doch klar.
Kilometer ist ja auch Kilometer. Denk’sch! MIPS ist eben nicht MIPS!! Es gibt in wirklichkeit drei Arten von MIPS (laut Muhr).

Zum einen die beruechtigten Prospekt-MIPS, die noch unterschieden werden muessen zwischen CPU-Prospekt-MIPS und Computer-Prospekt-MIPS. Erstere sind meist masslos uebertrieben oder sonstwie getuerkt. So wird dem i860 120 MIPS angedichtet…die rekrutieren sich in Wahrheit aus 40 MIPS und 80 MFLOPS,
was nach Eva Zwerg eben 120 macht. Begruendet wird diese atemberaubende Arithmetik durch die parallelisierungs Möglichkeit des i860.
Das sind aber keine MIPS, eher MIPS’n’MFLOPS oder MIPMFLOPS oder doch Schronz mit Ranz und Blonk?
Dann sind da noch die Computer-Prospekt-MIPS, eh, erstunken und erlogen sind, da sie nur als Absatzsteigerer eingesetzt werden.
Meist ist es so, dass die Computer zwar die echten MIPS-Werte angeben, doch die sind 100%ige Hardware Werte, d.h. das sind die Werte die MOTOROLA, INTEL oder SUN gemessen hat, als der Kaefer noch auf dem Silizium-OP-Tisch lag. So ist es z.B. durchaus wahr, dass ein 80386 4,5 MIPS macht…aber nur ohne MS/KOTZ, langsamen Plunder wie Buskontoller und Speicher, der mit 70ns “daherschleicht”.
Mit all dem Kram mach er evtl. grade noch seine 3 MIPS. Genauso SUNs SPARC mit 12,5 MIPS. In einem Vergleich der TU-Muenchen schnitt die SPARC Station1 gegen einen 386 und Interactive UNIX (16MB) deutlich schlechter ab. Es ist es auch kein Wunder, dass der Archimedes den NeXT locker im Apfelmaennchen-Pixeln abhaengt, obwohl dieser angeblich (nein, es stimmt schon) 1 MIPS mehr hat.

Die zweite Art von MIPS ist die Mess-MIPS Art. Diese entsteht aus obskuren Messprogrammen, die es auf jedem Rechner gibt. Naja, ich glaube darueber muss ich nicht viel sagen…ich schreib’ mir mein Testprogramm und mein VC20 geht mit 10000 MIPS ab wie d’zau.

Die dritte Art sind die schon oben erwaehnten Roh-MIPS, also die, die der Prozessor machen wuerde, wenn er so koennte, wie er wollte. Diese MIPS-Angaben sind nur fuer Computer-Bauer (keine Schraubenzieher-Firmen!) oder die Irren aus der 7*up im Prozessorbrett interessant.

Was nun in einer Welt voller Lug und Trug? Im Workstationbereich hat man das MIPS Manko schon lange satt, und ist deswegen auf die Dhrystones/s umgestiegen. Dies ist ein Testprogramm, das genaustens definiert und in C verfasst ist, sodass es ohne viel Aufwand auf jeden Rechner portiert werden kann. Das Dhrystone-Programm hat seinen Ursprung in dem Whetstone-Benchmark, der fuer die KWIPS (Kilo Whetstones Per Second) zustaendig ist.
Seine Autoren, H.J.Curnow und B.A.Wichmann von National Physical Laboratory, schrieben das Programm zum ersten Mal 1976 in ALGOL 60. Die heutigen Whetstones beruhen ausschliesslich auf der FORTRAN Version.
Seinen komischen Namen verdankt der Whetstone-Benchmark dem Whetstone-ALGOL Compiler. Diesen Compiler benutzten die Programmierer auch dazu, statistische Daten ueber das dynamische Verhalten von Programmen zu gewinnen. Fuer eine grosse Zahl numerischer Anwendungen sammelten die Programmierer Daten ueber die Haeufigkeit von sog. “Whetstone Instructions”, Befehlen in der vom Compiler benutzten Zwischensprache. Mit diesen Daten als Basis konstruierten sie ein synthetisches Programm, den “Whetstone Benchmark”.
Ein weiterer Benchmark, dessen Werte “Qualitaet” versprechen, ist der Linpack-Benchmark. Hier werden die Ergebnisse in MFLOPS angegeben.
Der Linpack war urspruenglich nicht als Benchmark gedacht, sondern war viel eher eine Sammlung von oft benutzten Unterprogrammen aus dem Bereich der linearen Algebra (daher der Name). Jack Dongarra hat dann daraus eine Standardfassung konstruiert, die in aller Welt grossen Anklang fand. So liegen fuer fast alle Rechner Linpack-Ergebnisse vor.
Auch Whetstone, Dhrystone und Linpack haben ihre Schwaechen, doch sind ihre Werte bei Weitem verlaesslicher, als irgendwelche MIPS oder noch besser Norton Faktor und Landmark (aber das ist ein Kapitel fuer sich).

Ein weiterer Befgriff, den man dann und wann antrifft ist “Performance”. Diese berechnet sich aus den ausgefuehrten Benchmarkbefehlen durch die benoetigten Sekunden geteilt. Um einen Festwert zu haben hat man diese Rechnung um VUPs erweitwert. VUP heisst Vax Units of Performance). Also teilt man die Performance durch die Performance einer VAX 11/780 (das sind 1757).

Naja, ob man sie wirklich braucht, die Benchmarks, MIPS, MFLOPS, VUPs und Konsorten, sei dahingestellt, aber wenn ich die Werte angebe, sollte auch klar sein was ich meine, gell?!

mfg AXEL

P.S.: Wenn ich MIPS angebe sind es meist real Werte, also die MIPS die ein Proz. im harten Alltag hergibt.

1. Teil der großen Lobhudelei auf den 68040. Eine kurze Vorstellung der neuen CPU von Motorola. Ja ich war Feuer & Flamme…[27.05.1990]

Wieder einmal Hallo!

Ich muss gestehen, wie man wohl auch vielleicht gemerkt hat,dass ich ein sehr grosser Fan MOTOROLAS bin. Meine Erste begegnun mit dieser “Welt” war wohl vor 4 Jahren als ich auf den Kleinen 6809 stoss. Naja und seitdem wandle ich auf dem leuchtenden Pfad des 68000-68030. Um nun einmal der doch ziehmlichen Kopflastigkeit der Intel Prozessoren in dieser Box entgegenzuwirken widme ich diese Mail ganz und gar dem:

* 68040’er
Der 68040 (ab jetzt nur noch 040 genannt) ist der logische Nachfolger des 68030, der wiederum seine Vorgaenger im 68020,68012,68010 und 68000 hatte. Der 030 war ja schon (zumindest bei seiner Ankuendigung) der Hammer schlecht hin…doch leider erwies sich das Teil als ziehmlich ueberladen,bzw. zu ueberladen fuer ein CISC Proz. (ich hoffe das nicht noch erklaehren zu muessen). Nun ja, man nahm also hin was da so aus dem Hause Motorola kam (SONY,SUN,NeXT,APPLE und schliesslich auch ATARI und COMMODORE) aber das Murren aus den Hardwarelaboren war nicht zu ueberhoeren (abgesehen von ATARI und COMMODORE, die den 030 ja erst jetzt entdeckt haben).
Also setzte man sich zusammen und beschloss den 040, kuendigte ihn an und beliess es dabei. Intel brachte dann auch den 486 waehrend Motorola es immer noch beim Ankuendigen beliess. Naja…kommt Zeit kommt 040.
Eines Tages war er da (faelschlicher Weise als “Antwort auf den 486” bezeichnet) und alle machten AH und OH. Warum denn? Die Zeitungen konnten gar nicht Ah und OH machen denn es gab ja erst 3 oder 4 von den Dingern. Aber Spass bei Seite, jetzt (seit 5.90) ist er wirklich da und in Stueckzahlen lieferbar!
Was hat sich denn eigentlich getan? Wollen wir ein wenig mit Daten klotzen? Jawoll!

* Volle kompatibilitaet zur gesamten 68000 Familie
* Uberarbeiteter 68882 on Chip
* mit Floating-Point-Software-Paket vollstaendiger 68882 Umfang
* 3,6 Fache integer Leistung vergl. mit 020 bei gleichem Takt
* 30 Fache floating Point (FP) Leistung gegenueber 68882
* FP Hardware multiplizierer
* Aufteilung in 7 unabhaengige Bloecke,die parallel arbeiten
* zusaetzliche Pipelines in den verarbeitungs Einheiten
* zwei getrennte,physikalische Caches je 4K
* zwei PMMU fuer gleichzeitigen Zugriff auf die Caches
* Multiprozessor untestuetzung durch Snooplogik
* 20 MIPS (Sparc 18, 486'er 15)
* 3,5 MFLOPS (Sparc 2,6, 486'er 1,0)
* Preis $800 (Sparc $1735, 486'er $950)
* Pro 1,3 Taktzyklen ein Befehl

So hier mache ich jetzt Schluss mit dem allgemeinen Dingen. Wer mehr wissen will fuer den habe ich die Mail “68040 spezial” geschrieben.
(Dieser Text ist fuer diejenigen gedacht,die es vielleicht nicht so genau wissen wollten)

mfg AXEL

2. Teil. “68040 Spezial”. Sehr ins Detail gegangen… [28.05.1990]

Aha! Du willst also mehr wissen…schoen! (Nebenbei: Du darfst ruhig auch mal was hier loswerden)

Der MC 68040 (so heisst er richtig) besteht aus fuenf Bloecken,die weitgehend unabhaengig voneineander arbeiten koennen. Die Integer und FP einheit sind die eigentl. Arbeitsbereiche. Sie enthalten eigene Pipe- lines fuer maximale Leistung. Die Befehlseinheit enthaelt Befehls-MMU mit Uebersetzungscache, Befehlscache und Snooplogik; Sie versorgt die beiden Uberstezungseinheiten (UeE) mit den Befehlen und entlastet somit den Bus. Die Dateneinheit enhaelt Daten-MMU mit Ue-cache, Datencache und Snoop- logik. Sie dient dazu die beiden Verarbeitungseiheiten mit Operanden zu versorgen und dabei den Bus moeglichst wenig in Ansruch zu nehmen. Der Buscontroller stellt dann die Schnittstelle zu externen Bus dar. Durch mehrere 128 Bit Register und eine 3 stufige Pipeline wird der externe Bus so optimal genutzt. Fuer schnellstmoeglichen Datentransport ist der interne Bus teilweise 128 Bit breit. Das zur “Geographie”. Die 68000’er Familie ist microprogrammiert. Das erlaubt leistungs- fahigere Befehle und Adressierungsarten sowie zugleich einen Ueber- sichtlichen,modularen Aufbau des Bausteins. Die RISC Familie (z.B.: 88000’er, SPARC oder ARM) geht da einen anderen Weg: Direkte ausfuehrung der Befehle in Hardware. Das steigert zwar die Anzahl der Befehle pro Zeiteinheit, beschraenkt aber gleichzeitig Umfang und Leistungsfaehigkeit der einzellen Befehle. Der 68040 versucht die Vorteile beider Verfahren zu verbinden. Er ist zwar mircoprogrammiert, aber einzellne Schritte innerhalb vieler Befehele wurden vom Microprogramm in die Hardware verlegt. Ein Bsp. hiefuer sind vor allem die Adressierungsarten. Die 68000 Familie verfuegt uber eine grosse Anzahl solcher Befehle. Man hat nun Untersuchungen ueber die Nutzung dieser angestellt. Jetzt verarbeitet ein speziell fuer den 040 entwickelter Hardwaredekoder diese Adressierungen in Hardware. Auch die Arbeit der beiden MMU, beim 030 ebenfalls in Mircocode erledigt, wird beim 040 in der Hardware durchgefuehrt, was die Adressierungszeiten drastisch steigerte.

DIE INTEGEREINHEIT ist funktions und objektkompatibel zu der des 020/030. Viele Optimierungen sorgen aber dafur, dass deren Leistung im Schnitt 3,6 mal hoeher ist als die eines 020 bei gleichem Takt (=BCLOCK). Dies resultiert aus verschiedenen Dingen: Hauptsaechlich aber da die Integer- einheit mit doppeltem Takt (=PCLOCK) arbeitet (Wie alle anderen Teile auch) Verglichen mit 020/030 sind somit alle Operationen von vorneherein doppelt so schnell. Durch viele weitere Optimierungen (Hardwareverlagerung, grosse Pipeline etc) wurde erreicht,dass die Anzahl der Takte pro Befehl um den Faktor 1,8 reduziert werden konnte. Dazu existiert in der Int-Einheit eine 6 Stufige Pipeline (Die nicht nur als prefetch Queue benutzt wird sondern auch pro Stufe je einen Befehl ausfuehren kann). Die Stufen sind:

* Prefetch des Befehls
* Befehl dekodieren
* Die effektive Adresse der benoetigten Daten berechnen
* Die Daten holen
* Die Berechnung durchfuehren
* Das Ergebnis zurueckschreiben

Damit kann diese Pipeline der Int.-Einheit schon 6 Befehle gleichzeitig abarbeiten. Eine derartig lange Pipeline hat normalerweise aber auch Nachteile. So muss sie bei jedem ausgefuehrten Sprung geleert werden und wieder neu geladen werden. Da Spruenge recht haeufing sind(alle 5-8 Befehle ein Sprung), wuerde ohne Vorkehrung die Leistung sehr schnell in die Kniee gehen. Der 040 vermeidet dieses Pipeline-Sprung Probelm indem die ersten beiden Stufen doppelt vorhanden sind. Wird in der 2. Stufe erkannt, dass ein bedingter Sprung vorliegt, so ist zu diesem Zeitpunkt noch nicht bekannt,ob der Sprung ausgefuehrt wird oder nicht (die Bedingung ist noch nicht ausgewertet). Der 040 liest dann beide Programmzweige aus dem Cache und dekodiert bereits die beiden moeglichen Befehle nach dem Sprung (den Befehl an der Stelle des Sprungziels, fuer den Fall, dass der bedingte Sprung ausgefuehrt werden soll und den Befehl unmittelbar nach dem Sprungbefehl, falls der Sprung nicht ausgefuehrt wird) Sobald bekannt ist ob der Sprung ausgefuehrt wird ist der erste Befehl aus jedem Zweig bereits geholt und dekodiert. Wird der Sprung aus- gefuehrt, so kann direkt weitergearbeitet werden. Wird der Sprung NICHT ausgefuehrt,brauch nur auf die andere Pipeline umgeschaltet werden und der Befehlsfluss wird dadurch nicht gestoert. (IST DAS NICHT GEIL!?) Die Pipeline ist fuer “ausgefuehrte bedingte Spruenge” optimiert, denn Untersuchungen haben ergeben, dass fast 70% aller bedingten Sprunenge ausgefuehrt werden.

DIE FOATINGPOINTEINHEIT ist voll kompatibel zum IEEE-754-1988 Standart und arbeitet PARALLEL zur Integereinheit. Sie hat eine 3 Stufige Pipe- line und einen eigenen Registersatz mit 8 FP-Registern,die 80Bit breit sind (komp. zu 68881/2). Die Pipeline ist folgendermasse aufgebaut:

* Konvertieren der Operanden in das interne 80Bit Format
* Ausfuehrung des Befehls
* Zuruekschreiben des Ergebnisses

Die FP-EInheit wurde fuer Befehle optimiert,die am Meisten genutzt werden. Fuer maximale Leistung wurde eine FP-Hardware-Multiplizierer eingebaut. Fuer bessere Optimierung wurden nur die FP-Grundbefehle im 040 implementiert und fuer die restlichen Befehle (Trigonometrie etc.) steht ein Software- paket zur verfuegung. Dieses Paket kann ueber einen sog. F-LINE-TRAP implementiert werden. CACHES sind ja anscheinend momentan das Nonplusultra wenn es um Vergleiche bei Prozessoren geht. Naja. Also die dinger sind ja dazu da,um moeglichst unabhangig von der Geschwindigkeit des Speichers zu sein. So besass der 68020 schon einen 256Byte grossen Befehlscache, der im 030 noch einen ebenso grossen Datencache zur Seite gestellt bekam. Beide wurden als logische Caches (sie befinden sich am logischen Adressbus zwischen CPU und MMU) mit einer groesse von 256 Bytes ausgefuehrt. Beim 68040 dient der groesste Teil der 1,2 Millionen Transistoren den Caches und deren Verwaltung. Es gibt wieder getrennte Befehls/Datencaches mit eigenen Bussen,sodass auf beide gleichzeitig zugegriffen werden kann. Hier wurden PHYSIKALISCHE Caches implementiert,die sich am physikalischen Adressbus der MMU befinden. Das bietet gewisse Vorteile: Im Multitaskingbetrieb ueberschneiden sich meist die logischen Adress- bereiche der verschiedenen Tasks, falls eine MMU verwendet wird. Ein logisches Cache kann nicht zwischen Speicherbereichen versch. Tasks unterscheiden, wenn sie gleiche (logische) Adressen haben. Das hat zur Folge,dass nach jedem Taskswitch ein logischer Cache von der Software geloescht werden muss. Bei einem Copy-Back-Cache muessten alle ver- aenderten Daten in den Speicher zurueckgeschrieben werden,was bei einem grossen Cache viel Zeit kostet. Damit erhoehen sich bei einem Taskswitch notwendige Zeiten drastisch, was einen Echtzeitbetrieb unmoeglich macht. Der 040 Cache kennt solche Nachteile nicht (der Glueckliche!). Da sich die physikalischen Adressen der versch. Tasks immer unterscheiden koennen Speicherausschnitte beliebig vieler Tasks gleichzeitig im Cache gehalten werden. Bei einem Taskswitch muss der Cache also nicht ge- loescht werden, und veraenderte Daten brauchen nicht zurueckgeschrieben werden. Ausserdem steigt dabei die Trefferwahrscheinlichkeit des Caches. Beide Caches haben eine grosse von 4K. Die Caches sind fuer den Burstmode optimiert,d.h. fuer die Aufnahme des Datentyps “Cachezeile” (16Byte) vor- gesehen. So das soll erstmal langen. Falls noch weiteres Interesse nach z.B. Datenkosistenz bei mehreren Busmastern, Memory managment oder Businterface/controller besteht bitte melden,gell.
Ach ja bevor ich es vergesse: Ich liebe diesen Prozessor! 🙂

mfg AXEL

1.Teil der großen RISC Serie. “Die Geschichte”  – man beachte die Rücksicht auf user ohne Packer und das Aufteilen in 10kb Häppchen. Ich sag’ nur 1200baud Modem!

Hallo!  

Gleich zu Anfang eine Warnung: DIESES WIRD EINE LANGE MAIL! Also Zeit zum Kaffekochen! (Ich packe nicht, da sich dann weniger Leser an diesem Brett erfreuen koennen.) Zur Uebersichtlichkeit teile ich aber in Kapitel, die je eine eigene Mail darstellen und durchlaufend nummeriert sind.  

Also RISC 1 - die GESCHICHTE:  

Heute gehts mal ganz allgemein um RISC-PROZESSOREN bzw. Rechner. Fur "Neue": RISC ist kein Praedikat fuer einen Prozessor der nach ablauf seiner Garantie das Leben seines Umfeldes riskiert, sonder ist eher eine Abkuerzung fuer: Reduced Instuction Set Computer (z.Dt. Prozessor mit eingeschraenktem Befehlssatz). (An dieser Stelle weise ich darauf hin, dass eingeschraenkt nicht beschraenkt heisst) Nach der Vokabelklaehrung zum Rest: (Ich hole "etwas" aus!) Mit der einfuehrung der Universalrechner Familie /360 von IBM wurde in den 60'er Jahren der Schritt zur modernen Rechnerarchitektur vollzogen. Man reagierte auf diese Tatsache,dass die Software immer teurer als die Hardware wurde, indem man innerhalb einer Rechnerfamilie verschiedene Rechner unterschiedlicher Leitung und Preise schuf,die aber aufwaerts- kompatibel waren. Bei einem Aufstieg in hoehere Klassen konnte die Software "mitgenommen" werden, das war revolutionaer. Das Familienkonzept stellte aber eine Herausforderung an die Rechnerarchitektur dar: Es musste eine Architektur geschaffen werden, die ermoeglicht ein und denselben Maschienenbefehlssatz in Modellen unterschiedlicher Leistung auszufuehren. In den Systemen /360 und /370 trieb man das so weit, dass Unterschiede zwischen dem Kleinsten und dem Groessten Modell um den Faktor 1000 ent- standen. Verglichen mit einem PKW muesste, wenn das kleinste Modell gerade 100km/h faehrt, das Spitzenmodell so um die 100000 Sachen machen. Nicht schlecht. Der Trik bestand darin, eine strikte Trennung duchzu- fuehren zwischen Maschienenbefehls-Schnittstelle (Laut IBM "architek- tur"), der logischen Organisation des Rechners ("Implementierung") und den physikalischen Bausteinen,aus denen er aufgebaut wird ("Realisierung"). Wichtigste Implemetierungs-Vorraussetzung fuer diese Organisation von Rechnern war die Technik der Mikroprogrammierung. Schon 1951 wurde eine Technik zur strukturierten von Maschienenbefehls- saetzen eingefuehrt, wurde sie eigentl. erst 1960 so richtig gewuerdigt. Die Idee ist sehr einfach: Jeder Maschienenbefehl wird durch ein Mikroprogramm implementiert. Das Mikroprogramm besteht aus Mikroin- struktionen, wobei jede die gesamte Steuerungsinformation fuer alle Hardwareelemente fuer einen Grundtakt der Maschiene beinhaltet. Die Methode der Mikroprogrammierung hat ihre Vor- und Nachteile: Sie ist wegen des Auslesens der Steuerinformationen aus dem Mikro- programmspeicher langsamer, sie bietet aber die Vorteile der Erweiter- barkeit, besserer Lesbarkeit und Aenderungsfreundlichkeit etc.. Die Mikroprogrammierung ist fuer den Normalbenutzer des Rechners meist nicht sichtbar, sie wird deshalb oft zur Systemhardware gezaehlt, obwohl sie eine Softwareloesung darstellt. Sie ermoeglichte nun, ein und den selben Maschienenbefehl auf unteschiedlicher Hardware laufen zu lassen. Die Mikroprogrammierung hatte natuerlich auch ihre Tech- nischen Vorraussetzungen: Anfang der 60'er war die Halbleitertechnik naemlich so weit, dass sie schnelle integrierte Speicherchips her- stellen konnte, die sich durch ihre geringe Kapazitaet geradezu an- boten Mikrocode aufzunehmen (Der Hauptspeicher war aber immernoch ein Magnetkernspeicher, der aus technischen Grunden eine Zugriffs- zeit von einer ms erlaubte.). Der Mikrocodespeicher war ungefaehr um den Faktor 10 schneller. Damit war das Verhaeltnis zwischen Haupt- speicher und Mikrocode etwa ausgeglichen, da auf einen Maschienen- befehl etwa 5-10 Mikroinstruktionen entfielen. Die Mikroprogrammierung bot den Herstellern also kompatible Rechnerfamilien herzustellen, wobei das einfachste Modell den Befehlssatz definierte und die naechst hoeheren diesen ebenfalls beherrschten und evtl. erweiterten. Die Tendenz ist zu erkennen: Sobald eine Rechnerfamilie in die Jahre kommt geraten die Maschienenbefeflssaetze immer groesser und bekommt hier und da noch ein Gimmick verpasst. Eine neue Maschiene schleppt also immer die "alten" Gimmicks mit sich herum wobei immer neue hinzu- kommen. Mit den Fortschritten in der Halsleitertechnik gelang die Entwicklung immer schnellerer Speicherchips fuer den Mikrocode, ganz anders bei den Hauptspeichern in Magnetkernspeichertechnologie. Es lohnte sich also noch mehr, eine Sequenz von Maschienenbefehlen zu genau einem Maschienenbefehl zusammenzufassen,um die Anzahl der Haupt- speicherzugriffe fuer Befehlsholphasen zu reduzieren. Im endeffekt wurde genau dies zu dem Kriterium bei der Entwicklung einer CPU. All dies zusammen fuerhte dazu, dass Maschienen mit an die 500 Maschienen- befehlen keine Seltenheit waren. Der Aufwand fuer die Entwicklung des Steuerwerkes von Rechnern explodierte: man sprach zu Recht von Complex Instruction Set Computern (CISC). Ich moechte wagen diese Zeit als die "barockzeit der Computer" zu bezeichnen, wobei man den barocken Bau- werken insofern unrecht tut, als hier nicht die funktionalitaet, sondern die Schoenheit der ueberladenen Struktur im Vordergrund stand. Bei Rechnern als Werkzeuge kommt es auf schoenheit nicht an, die Funktionalitaet der CISC wurde aber anfang der 70'er mehr und mehr in Frage gestellt. Denn genau Anfang der 70'er konnten die Halbleiterhersteller ploetzlich Speicherbausteine von genuegender Kapazitaet herstellen. Der prinzipielle Geschwindigkeitsvorteil der Mikroprogrammspeicher gegenueber den Haupt- speichern war damit verlohren. Einen weiteren Schlag versetzte der Technik der Mikroprogrammierung eine neue Speicherorganisationsform. Man erkannte, dass es sinnvoll war zwischen Hauptspeichern und Registern eine weitere Stufe in die Speicherhirachie einzubauen: den sog. Cachespeicher. Diese relativ kleinen aber schnellen Speicher enthalten gerade den Ausschnitt des Programms und der Daten die die aktuelle Nachbarschaft des aktiven Programmteils darstellen. Durch diese Caches wurden die Hauptspeicher- zugriffe scheinbar (im Mittel auch real) noch schneller. Doch den entscheidenden Hieb versetzten der Mikroprogrammierung die Statistiker unter den Rechnerarchitekten. Inzwischen war es mehr und mehr ueblich geworden in Hochsprachen wie FORTRAN,Algol,Pascal oder C zu programmieren. Es wurden also nicht mehr die Befehle aus dem Maschienensprachenvokabular genutzt, die ein geschickter menschlicher Programmierer gewaehlt haette, sondern nur die,die der Codegenerator eines Compilers anspricht. Diese Codegeneratoren wissen mit komplexen Maschienenbefehlssaetzen nichts anzufangen. Analysen von durch Compiler erzeugten Code foerderte die sog. 90:10 Regel zutage: d.h.,dass 90% der ausgefuehrten Befehle sich nur auf 10% des Maschienenbefehlsumfangs der CISC Architektur beziehen. Ergo: Der riesige Entwurfsaufwand fuer die CISC Maschienenbefehlssaetze ging zu 90% ins Leere. Um noch eins draufzusetzen: Jeder Ingeneur weiss, dass durch Hinzufuegen von Funktionen an ein technisches Geraet nicht nur zusaetzlicher Entwurfsaufwand entsteht,sondern auch eine Verlangsamung der restlichen Funktionen. Auf einen Rechner bezogen heisst das, jede zusaetzliche Verzweigung in Datenpfaden kostet Gatterlaufzeiten fuer Multiplexer/Demultiplexer. So war es also kein Wunder,dass mitte der 70'er fast gleichzeitig aus dem Walde IBM und Berkley University der Ruf "zu- ruek zur Natur" laut wurde. Die Ergebnisse dieser Entruepelung der Maschienenbefehlssaetze waren die IBM 801 sowie die Ein-Chip-Prozessoren MIPS und RISC. Neue Technologien erwarten also eine neue Rechnerarchi- tektur. Man sollte also erwarten,dass es heute nur noch RISC Rechner gibt...doch da hat man leider den Anfags erwaehnten Aspekt der Software vergessen. Es existieren immer noch Softwarepakete (wirklich grosse welche!) die zu 90% in Maschienensprache geschrieben sind. Eine por- tierung auf einen RISC Rechner wuerde sich finanziell nicht lohnen. Ein weiteres Argument ist, das manche Prozesse ohne einen Gewissen Maschienen- befehl nicht so schnell waeren wie sie sind. Damit sind eigentlich schon alle Gruende genannt, die die Daseinsberechtigung fuer so erfolgreiche Prozessoren wie die INTEL 80x86 oder Motorola 680x0 Familie darstellen. Somit ist die heutige Rechnerwelt in 124 Zeilen erklaehrt: Einerseits diktieren die nicht uebertragbaren investierten Milliarden in Rechnersoft- ware die Aufrechterhaltung von zumindest teilweise ueberholten Rechner- architekturen. Andererseits sind Architekturen bekannt,die bei weniger Investition hoehere Leitung bieten. So ergibt sich,dass diese Architektur bei Anwendungen mit grossen Rechenanspruechen und die nicht auf exsitiernenden Anwendungen aufgebaut sind bevorzugt verwendet wird. Um die geht es in Zukunft (dieser Mail) und somit ist das Kapitel CISC ad acta gelegt, genauso wie dieses Kapitel ueber die Entstehung der RISC Architektur.  

mfg AXEL

“Die Technik”. Vergleich AMD 29k, Inmos T800, i860/960, Intergraph Clipper, R3000 und M88k.

Willkommen zu Teil 2 der “RISC Saga”!

Weiter geht's mit der Technik,let's go...

Die RISC Rechner suchen also die Synergie, also das organische Zusammenspiel von Rechnerarchitektur und Compilerbau. Die Maschienenbefehls-saetze sollen nur Befehle anbieten, die der Compiler auch tatsaechlich nutzt. Eigenheiten der Maschienenbefehlssaetze sollten die optimierungsgaenge des Compiler unterstuetzen und umgekehrt sollten die Compiler "unangenehme Eigenschaften" der Basishardware verdecken. Zu letzteren zaehlen z.B. recht komplizierte Codeoptimierungen, mit denen gleichzeitige Nutzung von mehreren Rechenwerken auf einer CPU moeglich wird (dazu
spaeter mehr). Entsprechend der Vielfalt von Rechneranwendungen existiert heute nicht DIE RISC Architektur, vielmehr gibt es eine Vielzahl von Entwurfsmerkmalen, die bei konkreten RISC Architekturen mehr oder weniger eingehalten werden:

* Einzyklus-Maschienbefehle
Ein Pipelining des Maschienenbefehlszyklus soll dafuer sorgen, dass nach aufgefuellter Pipeline moeglichst mit jedem Grundtakt der Maschiene auch ein vollstaendiger Maschienenbefehl beendet wird.

* Load/Store Architektur
Durch Bereitstellung von hinreichend vielen Registern sollen Maschienen- befehlte moeglichst nur auf den prozessorlokalen (und damit schnell zugreifbaren) Registern arbeiten. Nur die expliziten Load- und Storebefehle koennen diese Register aus dem Speicher nachladen. Diese Massnahme fuehrt im wesentlichen zu einer Vereinheitlichung und Vereinfachung des Zeit-
verhaltens der Operandenholphasen im Maschienenbefehlszyklus und unterstuetzt damit ueberlappte Ausfuehrungen von Befehlsfolgen (Pipelining).

* Festverdrahtetes Leitwerk
Wegen der vewrbundenen Redunanz wird auf Mikroprogrammierung verzichtet.
Die Steuersignalgenerierung fuer die Hardware erfolgt massgeschneidert und fest verdrahtet.

* Wenige Maschienenbefehle & Adressierungsarten
Eine RISC Architektur soll nur die Befehle bereithalten, die auch von dem Codegenerator des Compilers benutzt werden. Das sind in der Regel weniger als 100. Komplexere Operationen sollen auf die angebotenen Elementaroperationen durch Zusammensetzung zurueckfuehrbar sein.

* Horizontales Maschienenbefehlsformat
Um die festverdrahtete Steuersignalgenerierung zu vereinfachen, sollen Maschienenbefehle ein einheitliches Format,auch bezueglich der Wortbreite, besitzen. Letzteres erfordert zwar mehr Speicherplatz fuer den Code, denn einige Befehle lassen sich in der Regel kuerzer implementieren, diese Redundanz ermoeglicht aber insgesamt einen effizienteren Entwurf.

* Verlagerung moeglichst vieler Aufgaben in die Uebersetzungszeit Ausgefuchste Strtegieen der Optimierung in den Compilern sollen die Architekturmerkmale moeglichst optimal ausnutzen.
Die Ergebnisse dieser Architektur-Ueberlegungen sind erstaunlich:
waehrend 32 Bit CISC Prozessoren heute ca. 300000 Transitorfunktionen und mehr umfassen, kann der Kern einens 32 Bit RISC Prozessors schon mit 50000 Transistorfunktionen komfortabel ausgestattet sein. Fuer die Ausfuehrung seiner Maschienenbefehle benoetigt er nur wenig mehr als einen Grundtakt gegenueber 5 oder mehr bei den mikroprogrammierten CISC CPU's.
Die Halbleitertechnologie ist heute so weit bis zu 1 Million Transistor funktionen auf einen Halbleiterchip unterzubringen. So heisst die neue Devise "RISC +": Die freigewordene Flaeche soll natuerlich genutzt werden. So finden FPU's und vor allem Cachespeicher incl. Controller ihr Heim auf dem Chip. Nun eine kleine Liste der bekanntesten RISC CPU's mit einer kleinen Beschreibung (fuer genauere Info's sollte man sich die speziellen Mail durchlesen,gelle!):

   Name      I Registerzahl I Transistoren I max Mhz I Pipel. I Zusaetze
   ----------+--------------+--------------+---------+--------+---------------
   AMD 29000 I 344          I 210 000      I 30      I 4      I FPU,ICU,DTC
   ----------+--------------+--------------+---------+--------+---------------
   Inmos T800I 6 + 4K Ram   I 238 000      I 25      I unbek. I FPU, Transputer
   ----------+--------------+--------------+---------+--------+---------------
   i80860    I 32           I 1 000 000    I 50      I 4(+1)  I ICU,FPU,GrafU
   ----------+--------------+--------------+---------+--------+---------------
   i80960    I 80           I 375 000      I 20      I 4      I FPU,Bausteinfam
   ----------+--------------+--------------+---------+--------+---------------
   Clipper   I 48 + 8 (FPU) I 800000/3ChipsI 50      I 3      I Drei Chips
   ----------+--------------+--------------+---------+--------+---------------
   MIPS R3000I 32 + 16(FPU) I 110 000      I 30      I 5      I --
   ----------+--------------+--------------+---------+--------+---------------
   M88000    I 32           I 175 000      I 20      I 6      I MOTOROLA!
   ----------+--------------+--------------+---------+--------+---------------
   Sun SPARC I 192          I unbek.       I 30      I 4      I FPU,ICU,DTC

Das war’s zur Technik.

mfg AXEL

“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

“Die Zukunft”. Immer amüsant zu sehen, was eintraf und was total daneben ging 😉

Ente gut,alles gut! Oder: Der letzte Teil (4).

Als eifriger Leser dieser Serie hast Du es geschafft. Dieses letzte Kapitel beschaeftigt sich mit der Zukunft der RISC Prozessoren. Nun denn…

Mit zunehmender Integrationsfaehigkeit der Halbleitertechnologie ist zu- naechst ein Uebergang zu 64 Bit Prozessoren zu erwarten. Erste Schritte in dieser Richtung sind schon gemacht (Intel 860). Fuer superschnelle An- wendungen wird man auf weniger hochintegrierbare Technologien uebergehen: ECL- und Gallium-Arsenid-Varianten mit Taktfrequenzen von 100 MHz und mehr sind bereits in der Ankuendigung (Motorola (Jaaaaa) und TI). Die Individualisierung der Rechnerhardware wird ebenfalls weiter anhalten: RISC Prozessorkerne eignen sich als Standartbausteine fuer Kundenspezifische Schalskreise (ASICs). Der Kunde kann um diese Kerne herum dann eine mass- geschneiderte Rechnerarchitektur entwerfen. Die waere ein Beitrag zur offenen RISC Architektur. Natuerlich werden auch zusaetzliche Funktionen auf dem Chip notwendig, vor allem solche, die das Testen der Bausteine und der auf ihnen laufenden Programme unterstuetzen sollen. In Zukunft werden sicher Trace Moeglichkeiten und Einsteigpunkte fuer Debuggig-Werk- zeuge und Monitore angeboten. Vom Standpunkt der Rechnerarchitektur am interessantesten ist sicher der Weg zu den Parallelrechnerstrukturen: Hier bieten sich verschiedenste Varianten an, drei davon erscheinen be- sonders erfolgreich. Die erste Variante bietet auf dem RISC Prozessorchip Kommunikationskanaele zu anderen Prozessoren. Diese vor allem von Trans- putern (Inmos) verwendete Strktur erlaubt ueber bitserielle Kanaele den Aufbau beliebig vernetzter Multiprozessorstrukturen, wobei die einzellnen Prozessoren ausschliesslich mit lokalen Hauptspeicher ausgestattet und damit relativ lose gekoppelt sind. In einem Feld von Tranputern werden gleichzeitig mehrere Befehlsstroemeausgefuehrt, die Parallelitaet erfolgt auf Prozessebene. Eine Parallelisierung ebenfalls auf Prozessebene, aller- dings bei anderer Kommmunikationsstruktur, wird von Multi-RISC-Prozessor- architekturen unterstuetzt, die ueber gemeinsame Speicher gekoppelt sind. Wegen der bei RISC Prozessoren allgemein benutzten Cachespeichern ent- steht dabei aber das Cache-Konsitenzproblem: mehrere Prozessoren arbeiten auf unterschiedlichen Kopien der (urspruenglich identischen) Information aus dem gemeinsamen Speicher. Dieser Fall tritt solange nicht ein, wie die Information nur gelesen wird. Schreibt jedoch nur ein Prozessor in seinen Cache und wird dieser Schreibvorgang an den gemeinsamen Hauptspeicher durchgereicht, so arbeiten zunaechst alle anderen Prozessoren mit einer abweichenden Version des gemeinsamen Speichers: es bestehen Inkonsis- tenzen. Wenn alle anderen Prozessoren diese Aenderungen rechtzeitig er- fahren, koennen sie sich darauf einstellen und etwa ihren Cache neu fuellen. Aus der Literatur sind eine vielzahl unterschiedlicher Cache- Konsistenz Protokolle bekannt, alle mit dem Ziel, das Entstehen inkon- sistenter Versionen von Informationen zu unterdruecken. Hersteller von RISC Arichitekturen bieten heute bereits Cache Bausteine mit Controller Funktionen an, die diese Cache-Konsistenz Protokollle realisieren. Neben Rechnerarchitekturen mit einer geringen Anzahl von Prozessoren, die alle auf einen gemeinsamen Speicher zugreifen, lassen sich so auch massiv parallele Strukturen aufbauen, die auf dem Konzept des verteilten gemeinsamen Speichers beruhen, der aber bemeinsame Speichermodule jeweils nur fuer bestimmte Prozessornachbarschaften vorsieht. Der wesentliche Unterschied zum Transputermodell besteht darin, dass der Zugriffspfad fuer die Kommunikation in voller Datenbusbreite anstatt nur bitseriell besteht und damit wesentlich schneller, aber natuerlich auch aufwendiger ist. Je nach Kommunikationsgrad der Anwendung wird man vermutlich beide Typen von Parallelrechnerstrukturen nutzbringend einbringen koennen. Die dritte Variante sieht Parallelitaet auf niedriger Ebene vor, naemlich im Prozessor selbst. Sie ist zudem mit den oben genannten Konzepten kombinierbar, bietet also unabhaengig vom beschriebenen Parallel-Processing eine eigenstaendige Dimension der Leistungssteigerung. Der Gedanke beruht letztendlich auf der Nachbildung von Rechnerstrukturen, wie sie mit dem ersten Numbercruncher- Superrechner CDC6000 vom genialen Entwurfsingeneur Seymour Cray vorgeschla- gen wurden und bis heute in diskreter Form auch im Superrechner CRAY vor- liegen. Pro Prozessor vervielfacht man die Anzahl der Rechenwerke und versucht, die verschiedenen Maschienenbefehle aus einem Befehlsstrom gegeneinander ueberlappt parallel in den Rechenwerken auszufuehren. Es handelt sich also um das Pipelining eines Maschienenbefehlsstroms auf hoher Ebene im Gegensatz etwa zum reinen Dekodierungs-Pipelining, wo nur die Instruktionen sozusagen stueckweise (im Maschienentakt) entschluesselt und ausgefuehrt werden. Zwei Verfahren zur Parallelisierung der Maschienen- befehle sind moeglich. Zum einen kann sie durch einen optimierenden Com- piler erfolgen, der Befehlswoerter neuer Art generiert: Jeder Maschienen- befehl erhaelt jeweils die Befehlanteile fuer jedes Rechenwerk. Man spricht dann von VLIW-Architekturen (Very Long Instruction Word). Die zweite Moeglichkeit besteht darin, die Maschienenbefehle durch geeignete Leitwerks- hardware zu parallelisieren. Eine solche Hardware muss wie der optimierende Compiler parallelitaetshindernde Merkmale erkennen. Das sind:

* Datenabhaengigkeiten

Berechnungs-Sequnzen beispielsweise, deren Ergebnisse aufeinander aufbauen, duerfen sich nur soweit ueberlappen, dass die Zwischenergebnisse noch weitergereicht werden koennen.

* Ressoucenkonflikte

Der Befehlsstrom darf z.B. nicht laengere Befehlssequenzen nur fuer ein Teil- oder Rechenwerk enthalten, wenn eine gleichzeitige Abarbeitung an- gestrebt wird.

* Komplexe Zeitbedingungen

Verschiedene Rechenwerke sind in der Regel auch unterschiedlich schnell. Wenn Resultate aus verschiedenen Rechenwerken voneinander abhaengen, muss die weitere Verarbeitung darauf abgestimmt (syncronisiert) werden.

Tatsaechlich kannte schon die CDC6000 solche Hardware, die damals “Score board” genannt wurde. Und auch neue RISC Architekturen bieten tatsaechlich auf einem Prozessorchip mehrere Rechenwerke zu einem Leitwerk an: neben einem Festkomma-Rechenwerk ein Gleitkomma-Rechenwerk, ein Adress-Rechen- werk usw.. Es koennen aber auch universell nutzbare Rechenwerke sein. Im Sinne der RISC Architekturstrategie (man verlagere soviel wie moeglich in die Compilezeit) ist sicher sie Optimierung durch entsprechende Compiler vernuenftiger. Sie hat allerdings den Nachteil, dass sehr grosse Instruk- tionswoerter in den Prozessor gebracht werden muessen. Ausserhalb des Prozessors, also im Hauptspeicher wird man diese daher wieder serialisieren und erst innerhalb der Prozessors entsprechend breite Datenpfade vorsehen. Auch sind die optimiernenden Compilertechniken, vor allem die sog. pfad- orientierte Kompaktifizierung (der Umbau der Codereihenfolge, um Ressourcenkonflikte und Datenabhaengigkeiten zu beruecksichtigen), noch nicht ohne Probleme. Erstaunlicherweise hat man uebrigens diese Opti- mierungsstrategie aus der Optimierung von Mikroprogrammen abgeleitet.

FAZIT:

Der Entwurf von Maschienenbefehlssaetzen, der durch den Zwang zur Kompa- tibilitaet lange Zeit sehr konservativ blieb, ist durch den Gedanken zu RISC Architekturen wieder interessant geworden. Wegen der Uebertragbarkeit alter Programme werden die CISC Architekturen allerdings weiterhin wichtig bleiben. Innovative parallele und Hoechstleistungssysteme jedoch werden vermehr auf RISC Prozessoren zurueckgreifen. Die Geschwindigkeitsschere zwischen Prozessortakt und Speichertakt hat dabei fuer die Rechnerarchi- tektur eine Fuelle von neuen Strukturen notwendig gemacht. Ob die Anzahl der heute angebotenen RISC Prozessoren allerdings auch kommerziell ueber- lebensfaehig ist, steht auf einem anderen Blatt.

Ich hoffe diese etwas ausfuehrlichere Mail ueber eine Prozessoridee hat Anklang gefunden. Leider bietet das Medium Mailbox keine Kontrolle wie gut etwas beim Leser ankommt (denn es gibt ja keine Verkaufzahlen). Doch wuerde es mich schon interessieren was ihr von dieser oder anderen Mails haltet…nicht um mich in Lobes oder Schmaehungshymnen zu aalen, sondern in Zukunft nicht Dinge zu veroeffentlichen, die eh kein Schwein liest. Also bitte, ein paar Zeilen des Kommentars! Danke!

mfg AXEL

Die erste “Massenmarkt CPU” von MIPS… und damit auch die erste in größeren Stückzahlen verkaufte RISC CPU.

Hallo ihr silizium Juenger!

Die Welt aus der ich komme faengt mit U an. U wie Unix. In dieser Welt zaehlt nichts mehr als Performance, Geschwindigkeit, Speed (und nichts weniger als Geld). Gerade dieser Welt hat es der Rest der Computer zu verdanken,dass es RISC CPUs gibt. Eine Zeitlang vergessen sind sie jetzt wieder voll da…sehr voll! Ein Unix-Rechner,der etwas auf sich haelt, und nicht von den anderen Rechnern per Ethernet ausgelacht werden will, hat einen RISC Proz. in sich (oder natuerlich einen MOTOROLA 🙂 ! ). Einer der am weitesten verbreiteten RISC Prozessoren ist der LR3000 (Oft auch als MIPS 3000 oder R3000 bezeichnet). Der R3000 ist so ziehmlich der modernste RISCer auf dem Markt. Ein Rechner mit diesem “Herz” braucht meisst weniger als ein DIN A4 Blatt fuer sein Motherboard. Das Geheimniss seiner Geschwindigkeit (42300 Dhrystones,25Mhz) liegt in seiner Architektur. Der R3000 benutzt drei Coprozessoren. Der erste (CP0 genannt) befindet sich auf dem Chip selbst und unterstuetzt die adressierung des sog. virtuellen Speichers und die Ausnahmenverarbeitung (aeh…zu deutsch: Exception handling) des R3000. Fuer die Uebersetzung einer virtuellen Adresse in eine entsprechende physikalische verwendet der CP0 eine TLB (Translation Lookaside Buffer) der 64 Eintraege speichert. Als weiterer Coproz. tummelt sich der R3010,seines Zeichens FPU, auf dem Board (der ist uebrigens OBLIGATORISCH…nix leerer Sockel).Der vierte Coproz. heisst R3020 und ist eigentl. nur ein Schreibpuffer..aber eben ein sehr schneller (Dieser Coproz. ist NICHT obligatorisch..aber gut). Ueberaus trickreich arbeiten die Coprozessoren zusammen. Sie ueberwachen naemlich selbststaendig wenn die Daten ueber den Bus flitzen und picken sich dann “ihre” Befehle raus (Snooplogik). Das spart natuerlich enorm Zeit,da die CPU nicht damit beschaeftigt ist die Aufgaben zu verteilen. Doch LSI-Logic, der Hersteller des LR3000, setzt weiter Meilensteine in der RISC Geschichte. Sowohl ueber den Cache (den hat er auch) als auch direkt laesst sich der R3000 mit dem Hauptspeicher verbinden. Der Cache ist,wie bei den Motorolas auch, in einen Befehls und einen Daten Cache geteilt wobei dieser 4-265KB (KB!) gross sein kann. Jeden Zu- griff auf den Cache wickelt der R3000 mit einem Zyklus ab. Bis zu 4GB kann der R3000 adressieren, wobei folgende “Regel” gilt: 2GB als Userbereich und 2GB als Kernelbereich. Arbeitet der R3000 im Usermode so wird der Speicher als ein 2GB grosser betrachtet. Jede virtuelle Adresse erweitert der Prozessor mit einem 6Bit Wort, der sog. Prozess ID. Fuer Parallelverarbeitung tun sich da neue Moeglich- keiten auf: Jeder laufende Prozess erhaelt so automatisch eine einzig- artige nur ihm zugeteilte virtuelle Adresse. Bis zu 64 Prozesse kann der R3000 verarbeiten. Befindet sich der Proz. im Kernelmode so wird der 4GB grosse Adressraum in 4 Segmente geteilt. Die ersten 2GB sind identisch mit dem Usermode. Hinter dem Useradressraum folgt ein 512MB Speicherbereich,der zwar ueber den Cache mit der CPU verbunden ist, jedoch nicht auf die TLB abgebildet wird. Dieser Speicherbereich heisst “kseg0” und liegt immer im ersten halben GByte des physikalischen Speichers. Dem kseg0 folgt ein weiterer 512MB Block, genannt “kseg1”. Beide Speicherbereiche bildet die Hardware des Prozessors auf die gleiche Adresse ab.Der einzige Unterschied beider Segmente besteht darin, dass der kseg1 weder ueber die TLB noch ueber den Cache geschleust wird. Diese Tatsache erweisst sich beim Debuggen als sehr nuetzlich. Der noch uebrige 1GB Bereich im Kernelmode verhaelt sich aehnlich dem Arbeits- speicher des Usermodes. Jetzt zum Technischen. Der R3000 hat 32 32Bit Register, einen Barrelshifter und eine 5 Stufige Pipeline die folgender- massen arbeitet: Fetch (hol das Stoeckchen), Read (Operanden lesen), Ausfueren (do it!), Speicherzugriff bei lade/speicherbefehlen und Ergebniss ausspucken. Jede Stufe erfordert einen Taktzyklus, d.h. pro Zyklus ein kompletter Befehl.

Eine kleine Anekdote zum Schluss: Ein Rechner der (fuer mich) die Bruecke zu diesem Prozessor schlaegt ist der SONY NeWS 3860. Alle SONY Workstations vorher arbeiteten traditionell mit Motorolas. Man steigerte sich bis hin zum Rechner mit zwei 68030ern. Einer als CPU, Einer fuer IO. Als auch diese Maschiene zu lahm war packte man kurzerhand einen R3000 als CPU rein. Jetzt werkeln beide gemeinsam und beim Plattenzugriff bleibt nix stehen… dank Motorola ,und alles geht schneller…dank LSI. Gott sei dank! 🙂

mfg AXEL

Die Geschichte Intels. Damals bestimmt die kompletteste Aufzählung. Heute ein alter Hut.

Hallo…

Der Trend ist eindeutig: INTEL Rechner werden in Europa immer mehr die Stellung einnehmen, die sie in Amiland schon seit 4 Jahren haben. Jeder hat einen, jeder will einen. (Es ist echt peinlich in Amiland in ein Comp-shop zu gehen, MSDOSE so weit das Auge reicht..wenn’s hoch kommt ein einsamer MAC Plus/SE in der dunkelsten Ecke, das war’s).

Sieht man sich mal so in seiner Stadt um, wie das Angebot der Computerläden aussieht (ich denke hier an HD), denke ich schon in den USA zu sein. Außer den Massenverramschern PHORA,PROMARKT,KAUFHOF etc.. handelt keiner mehr mit nicht-MSDOSEN. Rühmliche ausnahme sind natürlich die APPLE Händler in Deutschland, bei denen man denkt man kaufe einen Mercedes, statt eines Computers. Naja, so ist es eben, da kann man nichts ändern. Doch viele wissen ja nicht einmal was da jetzt in ihrem guten Stück drin ist (haupt- sache “INDUTRIE STANDARD”). Und wenn sie es wissen (“Da ist ein achzig- tausenddreihundertsechsundachzig drin und das bedeutet, daß er 80386 Rechenoperationen in der Sekunde machen kann, toll was! So schnell kannst Du nich’ mal den Taschenrechner bedienen!” und dergleichen) dann ist ihnen zumindest der Name INTEL “schon mal irgendwie auf der IAA unterge- kommen”. Die höchste Stufe ist dann das runterrasseln von Landmarkwerten und Nortonfaktoren der einzellnen Prozessoren von 8088-80486 (Die man sogar in chronologischer Reihenfolge hinkriegt (boar!)). Ok. Genug der bösen Worte: Jetzt gehts los mit der INTEL GESCHICHTSSTUNDE!

Ich beginne bei den Dingen, die sich in der INTEL Geschichte nie geändert haben: Die Bücher zu den Prozessoren. (Fast) immer gleich dick und immer gleich schwarz. Das erste ist sich übergetitelt: “4 Bit Microprozessor- systeme 4004 und 4040 – Intel Coperation, Santa Clara; 1971-1974” und weiter im Text “Im Zentrum dieses Systems steht der weltweit erste Mikro- prozessor 4004”, den Marcian E. Hoff entwickelt hatte. Da ist er nun, der Urvater aller Intel, den INTEL immer noch in einem Atemzug mit dem Rad und der Dampfmaschiene nennt (So wie wir Kohl und Adenauer 🙂 ). Nun sei’s drum, Intel begann irgendwie zu wachsen. Wie begann das alles? Die Japaner sind schuld (wie immer!)! 1969 wandte sich der- heute nicht mehr existierende – japanische Büromaschienen hersteller Busicom an Intel, um für eine Familie neuer Tischrechner einen Satz kundenspezifischer Chips entwickeln zu lassen. Intel war zwar erst ein Jahr alt, hatte sich aber bereits durch Halbleiterspeicher einen Namen ge- macht (Das DRAM 1103 mit 1024 Bit Kapazität = 0,001 Megabit – Das war der erste Speicherchip, der in den Kosten mit dem billigen aber voluminösen Magnetkernspeicher mithalten konnte). Intels Gründer, Bob Noyce und Gordon Moore, waren bereits “damals” Veteranen in der Elektronikbranche. Einst Mitarbeiter von William Shockley, der 1948 den Transistor erfunden hatte, hoben sie auch Fairchild Semiconductor, die Keimzelle der gesamten Chipindustrie, mit aus der Taufe (Haben also mords was drauf die Knaben). Bob Noyce ist (nebenbei) – zusammen mit Jack Kilby von TI – der Erfinder der monolithische integrierten Schaltung, des ICs oder eben “CHIPS”. Die Busicom Leute wussten also genau an wen sie sich zu wenden hatten. Marcian E. “Ted” Hoff, von Intel mit der Projektleitung beauftragt, kam rundschlägig auf ein rundes Dutzend kundenspezifischer Chips für die geplante Tischrechner serie – und somit (logischerweise) auf eine Idee. Man könnte doch statt einer festverdrahteten Logikschaltung eine pro- grammierbare herstellen, die sich dann in vielen anderen Anwendungen ein- setzen lässt. Hoffs Vision wurde innerhalb von nur neun Monaten (eine durchschnittliche Schwangerschaft also) von einem Entwicklerteam unter der Leitung von Frederico Faggin in Silizium gegossen. Das 4-Bit System 4004 bestand aus vier Chips: Dem Programmspeicher (4001), dem Datenspeicher (4002), einem Satz von Registern für die Datenein- und Ausgabe (4003) und dem Prozessor 4004. Letzterer hatte auf einer Fläche von 4,2 x 3,2mm 2300 MOS-Transistoren und schaffte 60 000 Instruktionen pro Sekunde – seinerzeit ein technologischer Durchbruch! Eben genau zu dieser Zeit kam Busicom finanzmäßig irgendwie ins Schlingern (hätten nicht so viel Sake trinken sollen) und Intel be- schloß ihren Auftraggebern die Rechte am 4004 Design für $60 000 – genau die Summe die jene Japaner investiert hatten – abzukaufen, wohl eher in der Hoffnung über das Vehikel Prozessor mehr 1103’er zu ver- kaufen (vergleichbar mit: Ölscheich (ver)kauft VW). 1971 war es soweit: Der 4004 wurde auf dem Markt angeboten. Zu seinen ersten Einsatzgebieten gehörten (grins) Verkehrsampeln, Waagen und Taxa- meter. Weniger als ein Jahr später erschien bereits der Intel 8008 mit acht Bit Wortlänge; er war praltisch parallel zum 4004 entwickelt worden und zeigte bereits einen gangbaren Weg zur Leistungssteigerung von Prozessoren (Der zweite ist, der in der MSDOSE welt weithin bekannte, die Taktfrequenz zu steigern). Kein langes leben war dem 4040 beschieden, der die Funktionen des 4002 und 4003 mit auf einen Chip integrierte. (an dieser Stelle ein Gedenk-Stop-Bit für den 80186)……………….. Den 4040 lasse ich nur deshalb hier mitspielen, da er eine weitere Ten- denz aufzeigt: Die Integration. Damit wurde auch der Grundstein gelegt zu den “Computern auf einem Chip” – den einchip Micros mit integrierten Programm- und Datenspeichern sowie Peripheriefunktionen. Während der 4004 auf arithmetische Funktionen optimiert war, bot der 8008 schon einiges an zeichenmanipulations Funktionen und erschloss damit ein ganz neuen Interessentenkreis. Er war aber vergleichsweise langsam und benötigte ca. 20 Peripheriebausteine zu seiner Unterstützung. Es dauerte 2 Jahre, bis ein Technologiesprung – ein anderer Fertigugspro- zeß – den 8080 ermöglichte, einen 8 Bit Microprozessor, den man heute mit Fug und Recht als ersten universell einsetzbaren Prozessor bezeichnet. Er leistete stolze 290000 Instruktionen/s, also 0,29 MIPS, und benötigte “nur” 6 support Chips. Mit seinen 16 Adreßbits konnte er 64K Haupt- speicher direkt ansprechen – uuuuunerschöpfliche Weiten taten sich da auf (mindestens 2,5 Prärien aber sicher 1 Tundra!). Im April 1974 kam der 8080 zu einem Listenpreis von $360 auf den Markt. Von Digital Equipment und anderen namhaften OEMs eingesetzt, wurde er von der Industrie schnell akzeptiert, setzte einen Industriestandart und spiele – so wird getuschelt – innerhalb 5 Monaten seine Entwicklungskosten ein. Es war das goldene Zeitalter der Chipbranche. Alle wollten Chips, keiner verstand sie (außer eben den 2-3 Herstellern). 1974 begann Intel mit einem anspruchsvollen Projekt: Einer komplexen 16/32 Bit Multiprozessor-Architektur. Der drei-Chipsatz namens iAPX 432, offiziell 1981 vorgestellt, war seiner Zeit einfach zu weit vorraus und erhielt – mit Ausnahme einiger von Intel gesponserter Uniprojekte – keine Chance, sich in der Proxis zu bewähren (also da könnt’ ich mich jetzt noch drüber aufregen, aber was hilft’s?). Viel von dem, was heute state- of-the-art ist – Multitasking, Multiprocessing, vernetzte Systeme mit verteilter Rechenleitung, optimale Unterstützung höherer Programmier- sprachen (LISP) – wurde damals vorweggenommen. Das ist für mich das beste Beispiel dafür, wie lange es dauern kann, bis Ideen den Weg zum Anwender gefunden haben. In der Zwischenzeit wuchs aber auch die Konkurrenz: Zilogs Z80, die Motorolas vom 6800-68000 (der anfangs auch verkannt wurde (wenn ich die erwische!!!)) und der 6502 von MOS Tech- nology – Herz des 64’ers und der ersten Apples (er ist einfach Toll!) verbuchten mehr als nur Achtungserfolge. Intel antwortete zunächst mit dem 8085, einer hochintegrierten 8080 Architektur, die nur mehr eine Versorgungsspannung benötigte. Doch man merkte, daß was besseres her musste: Eine 16 Bit Architektur. Zumindest sollte das Ding solange halten bis der 432 endlich fertig war. Das daraus resultierende Produkt war der 8086 (wer ist das?), eine Erweiterung der 8080 Architektur mit der etwa 10-Fachen Leistung. Er kam im Juni 1978 auf den Markt (wo war ich denn da, verdammt noch mal?!) und bildete den Grundstock der noch heute erfolgreichen 80×86 Familie…ja,ja gut Ding will Keile haben! 🙂

mfg AXEL