mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Pipelining - Wozu braucht man unterschiedliche Anzahl von Stufen?


Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an Alle,

ich mache gerade eine Ausarbeitung zum Thema Pipelining in 
Mikroprozessor-Systemen. Dabei stellt sich mir gerade folgende Frage:
Aus welchem Grund gibt es eigentlich unterschiedliche Anzahl von Stufen 
bei Pipeline-Prozessoren?
Eine Vermutung dazu habe ich, aber ganz klar ist es mir noch nicht. Es 
muss davon abhängig sein, wie viele Teilschritte ein Befehl auf einem 
Mikroprozessor benötigt.
- Benötigt ein Mikroprozessor nur zwei Teilschritte, also Fetch und 
Execute, so ist eine zwei-stufige Pipeline das idealste.
- Bei drei Teilschritten, also Fetch, Decode, Execute ist eine 
dreistufige Pipeline das idealste.
- Bei fünf Teilschritten, also Fetch, Decode, Execute, Memory Acess, 
Write Back, wäre eine fünf-stufige Pipeline das beste und
- Bei sechs Teilschritten, also Fetch, Decode, Calculate Operands, Fetch 
Operands, Execute, Write back, wäre eine sechs-stufige Pipeline am 
besten.

Weitere Fragen dazu sind:
- An welchen Eigenschaften lässt sich erkennen, wieviele Teilschritte 
ein Befehl bei einem Mikroprozessor benötigt, bzw. in welche Kategorien 
werden die Prozessoren unterteilt? Kann man beispielsweise sagen, dass 
die Teilschritte von der komplexität des Befehlssatzes abhängig ist?
Dann würde dies bedeuten, dass RISC-Prozessoren eine Pipeline mit 
relativ wenig Stufen benötigen, CISC dagegen mehr stufige Pipelines. 
Dies wiederspricht sich jedoch irgendwie damit, dass man 
RISC-Prozessoren Pipelining ermöglicht, da bei diesen die Befehle in 
etwa gleich lang sind.

- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei 
denen eine Pipeline garkeinen Sinn macht?

- Gibt es Prozessoren mit vier Teilschritten?

- Gibt es Prozessoren mit mehr als sechs Teilschritten?

- Kann mir vielleicht jemand zu jedem der oben aufgezählten ein Beispiel 
Prozessor nennen?

Ich weiss, dass sind ne Menge Fragen, leider konnte ich mir diese durch 
längere Recherche nicht beantworten.

Vielen Dank schonmal im Voraus für eure Antworten!

Gruß,

Christoph

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei
> denen eine Pipeline garkeinen Sinn macht?"

AVR, soweit ich weiß.

> "- Gibt es Prozessoren mit mehr als sechs Teilschritten?"

http://de.wikipedia.org/wiki/NetBurst
Pentium 4 - 20 Stufen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Bechtel schrieb:

> - Gibt es Prozessoren mit vier Teilschritten?

Die erste Generation von TriCore (32-Bit µC) hatte ne 4-stufige 
Pipeline. Beim TriCore 2 sind's inzwischen 6.

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schonmal für eure Antworten.
Aber ist denn meine Vermutung richtig, dass die Anzahl der Stufen einer 
Pipeline genauso groß ist wie die Anzahl der Teilschritte der Befehle?
Wie kategorisiert man Prozessoren mit zwei, drei vier, fünf und sechs 
und mehr Teilschritten?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Stufen einer Pipeline hängen doch nicht mit der Anzahl Teilschritten 
eines Befehls zusammen sondern umgekehrt... Der Befehl hat (zwangsweise 
im notfall durch einfügen von no ops) soviele Teilschritte wie die 
Pipeline lang ist.
Klar gibt es immer so "typische" Pipelinestrukturen aber prinzipiell 
kann ich mir ne Pipelein von 2 ... bis X Stufen bauen, z.B. 
GPUs/Vektorrechner haben typischerweise ne Sehr lange Pipeline CPUs für 
Controll Aufgaben eher im Bereich 5 - 9 Stufen. Auch bei einem AVR 
"KÖNNTE" ne Pipeline Sinn machen (vieliecht ist sogar eine drinn...)

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verwendet man eigentlich nicht auch Pipelines wegen der Signallaufzeiten 
usw in einem Chip bei einigen MHz muss man da schon aufpassen.

MFG Patrick

Autor: Marc S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> >"- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei
>> denen eine Pipeline garkeinen Sinn macht?"
>
>AVR, soweit ich weiß.

der AVR hat 3 Pipelinestufen ;)

Register Operands Fetch
ALU Operation Execute
Result Write Back

Sie werden aber hintereinander in einem Takt ausgeführt. Zu finden unter 
"AVR CPU Core" in den AVR-Datenblättern

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc S. schrieb:
>> >"- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei
>>> denen eine Pipeline garkeinen Sinn macht?"
>>
>>AVR, soweit ich weiß.
>
> der AVR hat 3 Pipelinestufen ;)
>
> Register Operands Fetch
> ALU Operation Execute
> Result Write Back
>
> Sie werden aber hintereinander in einem Takt ausgeführt. Zu finden unter
> "AVR CPU Core" in den AVR-Datenblättern

Da steht bei einem ATmega16 bei mir:

---
Instructions in the program
memory are executed with a single level pipelining. While one 
instruction is being exe-
cuted, the next instruction is pre-fetched from the program memory. This 
concept
enables instructions to be executed in every clock cycle.
---

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Bechtel schrieb:

> - Benötigt ein Mikroprozessor nur zwei Teilschritte, also Fetch und
> Execute, so ist eine zwei-stufige Pipeline das idealste.

Dieses Schema ist ziemlich sinnfrei weil fast schon eine Tautologie.

Die Implementierung einer konkreten Architektur bestimmt das Pipelining, 
nicht die Befehlssatz-Architektur selbst. Verschiedene Implementierungen 
der gleichen Architektur haben oft unterschiedliche Pipeline-Tiefen.

Immerhin implementierten Intels 386 und der Pentium 4 die fast gleiche 
Architektur, aber die Pipeline-Tiefe unterscheidet sich um eine 
Grössenordnung. Auch innerhalb ungefähr gleichzeitiger Implementierungen 
können die Unterschiede sehr gross sein (AMD K5 vs Intel Pentium Pro).

> - An welchen Eigenschaften lässt sich erkennen, wieviele Teilschritte
> ein Befehl bei einem Mikroprozessor benötigt,

Das läuft oft genug andersrum. Design-Parameter der Implementierung 
(z.B. die maximale Anzahl sequentieller Gatterstufen innerhalb eines 
Taktes) bestimmen die maximal mögliche Komplexität der einzelnen 
Pipelinestufen und daraus ergibt sich, wie fein die Befehle in 
(Unter-)Schritte aufgeteilt werden müssen um damit implementiert zu 
werden.

> Kann man beispielsweise sagen, dass
> die Teilschritte von der komplexität des Befehlssatzes abhängig ist?

Auch.

> Dann würde dies bedeuten, dass RISC-Prozessoren eine Pipeline mit
> relativ wenig Stufen benötigen, CISC dagegen mehr stufige Pipelines.

Zwangsläufig aufgrund der komplexeren Dekodierung.

Dazu kommt die Frage, ob Befehle in Programmreihenfolge ausgeführt 
werden oder in Abhängigkeit voneinander auch anders, und ob mehr als ein 
Befehl parallel ausgeführt werden soll.

> Dies wiederspricht sich jedoch irgendwie damit, dass man
> RISC-Prozessoren Pipelining ermöglicht, da bei diesen die Befehle in
> etwa gleich lang sind.

Wenn du mit der Länge die Codierung meinst: Die Dekodierung kompliziert 
die Pipeline, aber auch bei einfacher Codierung bleibt genug zu tun 
übrig.

Das die Pipeline angeht sind RISCs nicht uniform. Man kann mindestens 
zwischen ALU-Ops, Load/Store-Ops und FPU-Ops unterscheiden, die jeweils 
völlig unterschiedliche Pipelinetiefen haben können.

> - Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei
> denen eine Pipeline garkeinen Sinn macht?

Je Pipeline desto Transistor. Willst du Transistoren sparen, spare an 
Pipelines. Ganz am Anfang waren Pipelines folglich unüblich.

> - Kann mir vielleicht jemand zu jedem der oben aufgezählten ein Beispiel
> Prozessor nennen?

Bischen Arbeit solltest du schon selber machen. Zumal du wie schon 
skizziert für unterschiedliche Befehle beim gleichen Prozessor 
unterschiedliche Tiefen kriegst.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Bechtel schrieb:

> Aber ist denn meine Vermutung richtig, dass die Anzahl der Stufen einer
> Pipeline genauso groß ist wie die Anzahl der Teilschritte der Befehle?

Einerseits nein. Allein schon weil die x86 Architektur Befehle kennt, 
die auch in aktuellen Implementierungen in Hunderten von Teilschritten 
ausgeführt werden. Als Mikroprogramm.

Andererseits ja. Denn wenn man Mikroprogrammierung mal draussen lässt, 
entspricht bei heutigen auf Performance optimierten Prozessoren eine 
Pipeline-Stufe fast per Definition einem Teilschritt. Die schon erwähnte 
Tautologie. Wenn's nicht so ist, dann ist man bei der Optimierung noch 
nicht ganz im Ziel angekommen und dreht in mancher Stufe Ehrenrunden, 
was das Pipelining ins stocken bringt (vgl. die sehr ähnlichen Intel 
Pentium Classic [mit Ehrenrunde] und Cyrix M1 [ohne]).

Ist nicht Performance normaler Standard-Operationen das Hauptkriterium, 
dann kann alles rauskommen. Die dsPIC30 beispielsweise haben trotz 
teilweise komplexer mem=>mem Befehle eine sehr kurze Pipeline mit vielen 
Teilschritten in einem einzigen Takt.

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohh... hier hat sich ja einiges getan.
Vielen Dank für eure Posts.
Nur dass ich das richtig verstanden habe, möchte ich das noch einmal 
zusammenfassen:

Grundsätzlich bestimmt also die Architektur des Mikroprozessors, 
insbesondere die daraus resultierenden Teilschritte (Mikrobefehle), die 
Tiefe einer Pipeline. Je mehr Mikrobefehle ein Befehl enthält, desto 
tiefer sollte die Pipeline sein, um möglich viel Performance aus dem 
Mikroprozessor rauszuholen.
Des Weiteren ist es sinnvoller einen RISC-Prozessor mit einer Pipeline 
auszustatten als einen CISC-Prozessor, da der RISC-Prozessor kleine 
Befehle hat, die schneller ausgeführt werden können und somit auch die 
Taktrate erhöht werden kann. Die Verarbeitung der RISC-Befehle durch die 
Pipeline ist einfacher als CISC-Befehle.
Ich hoffe das ist soweit richtig.

Jetzt muss ich doch noch mal ein paar weitere Fragen stellen:

- Die von mir genannten "Teilschritte" eines Befehls sind Mikrobefehle, 
aus denen der Befehl besteht oder?
- Werden jetzt die einzelnen Mikrobefehle auf die verschiedenen Stufen 
einer Pipeline aufgeteilt, oder enthält jede Stufe einen eigenen 
kompletten Befehl?
- Wie kann man sich eine Pipeline hardwaretechnisch vorstellen? Ist dies 
einfach nur ein "Bus" zwischen den verschiedenen Einheiten eines 
Mikroprozessors und dem Speicher oder gehört auch ein 
Pipeline-Controller dazu? Irgendwie muss das ganze ja kontrolliert 
werden.

Vielleicht hat jemand ne gute Seite die beschreibt, wo eine Pipeline in 
ein Mikroprozessor eingebettet ist.

Schönes Wochenende!

Gruß,

Christoph

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Bechtel schrieb:

> Nur dass ich das richtig verstanden habe

Hast du nicht.

> Grundsätzlich bestimmt also die Architektur des Mikroprozessors,
> insbesondere die daraus resultierenden Teilschritte (Mikrobefehle), die
> Tiefe einer Pipeline.

Nein.

> Je mehr Mikrobefehle ein Befehl enthält, desto
> tiefer sollte die Pipeline sein, um möglich viel Performance aus dem
> Mikroprozessor rauszuholen.

Nein.

> Des Weiteren ist es sinnvoller einen RISC-Prozessor mit einer Pipeline
> auszustatten als einen CISC-Prozessor,

Nein. Nur etwas einfacher.

> - Die von mir genannten "Teilschritte" eines Befehls sind Mikrobefehle,
> aus denen der Befehl besteht oder?

Mikrobefehle sind etwas gänzlich anderes.

Siehe beispielsweise
http://en.wikipedia.org/wiki/Instruction_pipeline
http://en.wikipedia.org/wiki/Pipeline_(computing)
http://en.wikipedia.org/wiki/Microcode

Generell ist die Wikipedia eine ganz passable Informationsquelle dafür.

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm.. okay, dass die Bezeichnung der Mikrobefehle in diesem Zusamenhang 
falsch ist sehe ich inzwischen ein.

Aber ich bin der Meinung, dass auf jeden Fall von der Performance her 
sinnvoller ist einen RISC-Prozessor mit einer Pipeline "auszustatten" 
als einen CISC-Prozessor. Das hat einfach den Grund, dass die 
RISC-Befehle kleiner sind und sich von ihrer Ausführungszeit mehr ähneln 
als die Befehle der CISC-Prozessoren. Die Befehle der CISC-Prozessoren 
können ja theoretisch beliebig lang und kurz sein, also werden dort 
viele Lücken in der Pipeline entstehen, oder liege ich auch damit 
falsch?

Bezüglich der Tiefe der Pipeline meinte ich nicht die Architektur des 
Mikroprozessors, sondern wie du oben schon gesagt hattest die 
Implementierung des Mikropozessors.

>> Je mehr Mikrobefehle ein Befehl enthält, desto
>> tiefer sollte die Pipeline sein, um möglich viel Performance aus dem
>> Mikroprozessor rauszuholen.
>
>Nein.

Wenn wir mal das Wort "Mikrobefehle" durch "Teilschritte eines Befehls" 
ersetzen, dann stimmt das aber doch? Eine geringere Tiefe würde 
bedeuten, dass der Prozessor nicht mehr bestmöglich ausgenutzt wird und 
eine größere Tiefe wäre nutzlos bzw. steht bei einem unvorhersehbarem 
Sprung sogar im Weg, da mehr Daten aus dem Speicher nachgeladen werden 
muss.
Bitte korrigier mich, wenn ich damit falsch liege.

Gruß,

Christoph

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Bechtel schrieb:

> Aber ich bin der Meinung, dass auf jeden Fall von der Performance her
> sinnvoller ist einen RISC-Prozessor mit einer Pipeline "auszustatten"
> als einen CISC-Prozessor.

Wäre Intel dieser These gefolgt, der Welt wäre der Siegeszug der 
x86-Prozessoren erspart geblieben.

> als die Befehle der CISC-Prozessoren. Die Befehle der CISC-Prozessoren
> können ja theoretisch beliebig lang und kurz sein, also werden dort
> viele Lücken in der Pipeline entstehen, oder liege ich auch damit
> falsch?

Nein, das ist korrekt. Und der Versuch, effektive Pipelines 
einzubringen, hat DEC soviel Geld gekostet, dass das Ende der Super-CISC 
VAX besiegelt war.

Aber bezogen auf x86er: Die weitaus meisten Befehle (entsprechend 
Laufzeitstatistik) passen in der Ausführungsphase in ein recht simples 
Schema:
 - Adresse berechnen
 - Operand laden
 - Rechnen
 - Operand speichern
wobei mancher Schritt entfallen kann. Die Pipeline liegt auf der Hand 
und wurde von Cyrix auch exakt so umgesetzt. Intel hatte in der 
486/Pentium Pipeline Load und Execute zusammengelegt und damit für 
häufige Ehrenrunden gesorgt.

> Wenn wir mal das Wort "Mikrobefehle" durch "Teilschritte eines Befehls"
> ersetzen, dann stimmt das aber doch?

Dann stimmt das. Ungefähr.

Es gibt aber noch andere Aspekte. Nichtsequentieller Befehlsfluss 
beispielsweise. Je tiefer die Pipeline, desto grösser der Schock wenn 
sie unterbrochen wird. Da man gemeinhin davon ausgeht, dass einer von 
grob 5 Befehlen ein Sprungbefehl ist, sollte man das im Auge behalten.

Eine Zeitlang hatte IBM seine RS/6000 Schiene gleichzeitig in 2 
Richtungen entwickelt. die Power3/4/5... für eher datenorientierte 
technisch/wissenschaftliche Aufgaben mit tendentiell guter Planbarkeit 
der Befehle und die RS64 für stark entscheidungsorientierte schlecht 
vorhersagbare kaufmännische Aufgaben. Dementsprechend hatten die PowerX 
eine tiefe Pipeline mit hohem Takt, die RS64 eine extrem kurze Pipeline 
mit niedrigem Takt.

Eine sehr tiefe Pipeline kann dazu führen, dass voneinander abhängige 
Befehle langsamer werden und auch die Planung der Befehlsausführung 
immer mehr in Raterei ausartet. Historischer Spitzenreiter in dieser 
Problematik war der Pentium 4, bei dem der Planungszeitpunkt in der 
Pipeline so weit vor der Ausführung lag, dass er nur raten aber nicht 
wissen konnte was wann zu starten war. Und wenn er damit falsch lag, war 
er langsamer als die Konkurrenz.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie reihen sich den superskalare Architekturen darin ein?
   http://en.wikipedia.org/wiki/Superscalar_architecture

Hier muss es je mehrere Pipelines geben, und Fetches durfen sich nicht 
quer kommen. Braucht's dazu mehrere Bussysteme (eines für jede 
Pipeline)? Wie wird erkannt, daß zwei Befehle innerhalb der gleichen 
"Issue Group" ausgeführt werden können? Dazu müssen ihre Operanden ja 
unabhängig sein, weil ein Befehl nicht auf das Ergebnis eines anderen, 
sich ebenfalls gerade in der Pipeline befindlichen Befehls, verwenden 
kann.

A. K. schrieb:
> Es gibt aber noch andere Aspekte. Nichtsequentieller Befehlsfluss
> beispielsweise. Je tiefer die Pipeline, desto grösser der Schock wenn
> sie unterbrochen wird. Da man gemeinhin davon ausgeht, dass einer von
> grob 5 Befehlen ein Sprungbefehl ist, sollte man das im Auge behalten.

Moderne CPUs machen da nen "Inject" in die Pipeline, AFAIK. D.h. es wird 
nachträglich in die Pileline was reingefummelt, so daß bei einem Sprung 
nicht so viel verloren ist.

Johann

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Hier muss es je mehrere Pipelines geben,

Korrekt. Die gab es allerdings schon vorher und superskalare Ausführung 
sollte die existierenden nebenläufigen Pipelines besser nutzen.

> und Fetches durfen sich nicht quer kommen.

???

> Wie wird erkannt, daß zwei Befehle innerhalb der gleichen
> "Issue Group" ausgeführt werden können? Dazu müssen ihre Operanden ja
> unabhängig sein, weil ein Befehl nicht auf das Ergebnis eines anderen,
> sich ebenfalls gerade in der Pipeline befindlichen Befehls, verwenden
> kann.

Was vielleicht helfen mag: "The Anatomy of a High Performance 
Microprocessor" von Shriver/Smith, ISBN 0818684003. Beschreibt ziemlich 
detailliert den inneren Aufbau des AMD K6, und damit einer 
Lösungsvariante dieser Problematik.

Auch sehr informativ: http://www.agner.org/optimize Punkt 3, sowie
http://www.azillionmonkeys.com/qed/cpuwar.html und manches 
Grundlagenmaterial von Hannibal auf arstechnica.com.

Das lässt sich hier wirklich nicht gut in wenigen Worten erklären, dazu 
ist es in all seinen Varianten viel zu komplex.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Auch sehr informativ: http://www.agner.org/optimize Punkt 3, sowie

Typisch... nicht nur für Intel und AMD, daß die Informationen nicht vom 
Hersteller kommen, sondern per reverse Engineering beschafft wurden bzw. 
werden mussten...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch nicht übel: 
http://www.chip-architect.com/news/2003_09_21_Deta...

Der Autor neigt allerdings zu wilden Spekulationen, insbesondere in 
seinen anderen Texten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Typisch... nicht nur für Intel und AMD, daß die Informationen nicht vom
> Hersteller kommen, sondern per reverse Engineering beschafft wurden bzw.
> werden mussten...

Sachte, optimzation guides gibt es von Intel wie von AMD. In der 
Qualität wie von Agner jedoch nicht. Andererseits sind solche Analysen 
manchmal auch nicht ganz korrekt. Bei AMD K7 aufwärts war Agner anfangs 
ziemlich auf dem Holzweg, er hatte dessen Pipelining nicht verstanden, 
ist aber (mit etwas Hilfe von mir) besser geworden.

Allerdings sind die Herstellerdokus nicht so tiefschürfend und werden 
vor der Veröffentlichung gründlich zensiert, um nicht zu viel über die 
interne Struktur zu verraten. Wobei auch manche wichtigen Aspekte unter 
die Räder kommen, die Schwachpunkte verraten. Mit NDA gibt's da 
teilweise mehr Info.

Etwas detailfreudiger sind manche Herstellerinfos an unerwarteter 
Stelle: in Patenten. Grosse Teile vom K6 kann man dort wiederfinden und 
das war wohl auch eine wesentliche Quelle des obigen Buches. Und dort 
findet man  in geradezu epischer Breite auch eine Architektur die als 
"missing link" exakt zwischen K5 und K7 liegt und nie implementiert 
wurde (der K6 ist kein Design von AMD, sondern von Nexgen).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Mit NDA gibt's da teilweise mehr Info.

Die Frage ist dann, ob ein NDA der Beschreibung der Architektur 
(Scheduling, Pipelines, ...) innerhalb eines Open Source Compilers 
widerspricht. Immerhin stellt die Compiler-Quelle die Informationen, die 
in den Dokumenten enthalten sind, offen lesbar dar -- eben in einer 
etwas anderen Form.

Ich würd da eher raten, daß die Hersteller ihre Hausaufgaben nicht 
machen und NDAs eigentlich nicht nötig wären. Es muss doch möglich sein, 
die Hardware für Compilerbauer et al. hinreichend darzulegen, ohne daß 
daraus tiefgreifende Rückschlüsse (solche, die die Konkurrenz nicht eh 
schon hat) auf die Architektur möglich sind; ebenso wie aus dem 
Befehlssatz nicht auf die Architektur geschlossen werden kann.

Einige Hardwarehersteller wissen allerdings gar nicht mehr, was sie da 
bauen und produzieren. Namentlich Infineon: Teilmodule wurden zugekauft 
und aufs Silizium gepappt, aber keiner weiß, wie's geht. Dokumentation 
gibt's keine. Irgendwo gibt's Treiber, die das Wissen implizit 
enthalten, aber in München ist keiner mehr, der weiß, was da abgeht. Und 
in Indien... naja, lassen wir das Thema. :-/

Johann

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Die Frage ist dann, ob ein NDA der Beschreibung der Architektur
> (Scheduling, Pipelines, ...) innerhalb eines Open Source Compilers
> widerspricht.

AMD hatte die erste Version des Optimization Guide vom K7 rausgelassen 
ohne sie zu redigieren. Mitsamt NDA-Formular vorne drauf. 2 Tage drauf 
war's wieder weg und kam später zensiert wieder raus. Fehlten 
insbesondere ein paar Schwachpunkte beim branch predictor.

Sowas aus dem Compiler rauszulesen ähnelt dem Versuch, aus einer 
Frikadelle wieder das Schwein zu machen.

> Ich würd da eher raten, daß die Hersteller ihre Hausaufgaben nicht
> machen

Die Autoren dieser Dinger sind natürlich nicht die hochbezahlen 
Architekten selbst, insofern stochern die u.U. selber etwas im Nebel.

Autor: A. K. (prx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zum Zusammenspiel der Pipelines im K7/K8 hatte ich für Agner mal 2 
Bildchen fabriziert. Sind zwar vermutlich nur in Verbindung mit der 
Gesamtstruktur verständlich, ich hänge sie aber trotzdem mal ran.

Autor: A. K. (prx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier der Ablauf von typischen x86 load-execute und 
load-execute-store Operationen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Sowas aus dem Compiler rauszulesen ähnelt dem Versuch, aus einer
> Frikadelle wieder das Schwein zu machen.

Seh ich auch so. Um so mehr verwundern mich die NDAs.

Autor: Fuzzy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wunder mich manchmal, wie die Leute das heutztage noch schaffen, 
Teile einer CPU Architektur zu reversen. In den 70er Jahren war das noch 
ziemich einfach, mit Lichtmikroskop Bild machen und nachverfolgen was 
abgeht, wie hier: http://www.flylogic.net/blog/?p=63

Aber heute? Um allein 1mm² aussagekräftig abzubilden, braucht man 
1000um*20=20000 Pixel pro Achse (50nm pro pixel) 200000²=400M, Ein 
zusammengesetztes REM Bild, auf dem man die Strukturen von 1mm² sehen 
kann, hat somit 400M Speicherbedarf. Und das multipliziert mit allen 
Layern eines Chips. (Die daraus folgende Auflösung der Masken zur 
Fertigung ist auch sehr beachtlich)

Meiner Meinung nach fast unmöglich, somit braucht mal wohl irgendwie sie 
Infomationen des Herstellers.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Seh ich auch so. Um so mehr verwundern mich die NDAs.

Wer bindet den Kunden, Journalisten und Konkurrenten schon gerne seine 
Schwachpunkte direkt unter die Nase? Erst recht nicht am Anfang, wenn 
alle drüber schreiben. Später sind Teile der bei AMD kastrierten Info 
auch wieder offiziell aufgetaucht.

Dass beispielsweise eine Konstruktion wie der Trace Cache vom P4 in 
Verbindung mit just-in-time Compilern eine recht üble Sache sein kann, 
das hat Intel im Guide nur sehr sehr verschlüsselt formuliert. M.E. nur 
jenen Leuten verständlich, die wissen wie sowas funktioniert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuzzy schrieb:

> Meiner Meinung nach fast unmöglich, somit braucht mal wohl irgendwie sie
> Infomationen des Herstellers.

Korrekt. Man sammelt alles an Info-Schnipseln was da ist. Die erwähnten 
Guides, Artikel, Präsentationen evtl. mitsamt Ton-Aufzeichnung usw.

Dann gibt es gelegentlich Detail-Info in Patenten. Nur muss man peilen 
können, ob das was mit der Realität zu tun hat oder nicht. Oft nicht, 
manchmal schon. In diese Falle ist Hans de Vries mal reingetappt und hat 
so beispielsweise eine wunderschön illustrierte Beschreibung eines K8 
abgeliefert, die von A bis Z komplett falsch ist weil sie auf einem nie 
realisierten Projekt aus diversen Patenten basiert: 
http://www.chip-architect.com/news/2001_10_02_Hamm....

Testprogramme. Das Verhalten von verschiedensten Codeschnipseln messen.

Die Performance Counter der Prozessoren. Die zählen allerlei Statistiken 
und Events mit, und damit lässt sich was anfangen. Vor allem in 
Verbindung mit Testprogrammen. Anfangs (P5) hatte Intel diese Details 
nur gegen NDA raugerückt.

AMD wiederum stellt mit dem Codeanalyst ein Tool zur Verfügung, das auf 
einem Programm zur Software-Simulation der Pipeline aus der Designphase 
basiert, und daraus Optimierungs-Tips ableitet.

Vor allem aber braucht man eine solide Vorstellung davon, wie 
Rechnerarchitekturen funktionieren. Um diese ganzen Schnipsel in 
Beziehung zu setzen. Ist ein recht interessantes Puzzle-Spiel.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.