Assembler bei interlocked Pipeline

[Thomas (Gast)]

Hallo zusammen,

nur mal eine kurze Frage zu interlocked und non-interlocked Pipelines.

Wenn ich einen Maschinencode ausführe der einen Wert aus dem Speicher 
holt, und sofort prüft was dort steht - sollte ich da nicht Probleme mit 
der Pipeline bekommen ?

Der Fetch aus dem Memory ist doch eventuell noch nicht komplett 
abgeschlossen wenn ich meinen compare durchführe, oder ?

Also meiner Meinung nach passiert also bei diesen Befehlen:
(ebx beinhaltet eine Addresse im Speicher)

mov eax, [ebx]
cmp eax, 0x00000000

a) Bei x86 Architekture wären hier wohl Wait-States nötig, oder ?
Verwunderlich ist das nur weil diese Befehle werden ja ständig in quasi 
jedem Programm durchgeführt. Muss da wirklich gewartet werden, oder 
gibts da nen Trick ?

b) Bei MIPS (without interlocked pipeline) sollte so eine 
Befehlsreihenfolge ja dann garnicht gehen, oder ?

Vielen Dank für ein paar Schubser in die richtige Richtung. Und bitte 
nicht sagen ich soll das Intel x86 Architecture Manual durchlesen. Das 
liegt schon unter dem Kopfkissen :-)

Thomas

[Christian B. (casandro)]

Das müsstest Du im Datenblatt der CPU nachschauen. Es gibt durchaus 
einige Prozessoren die in solchen Fällen einfach Mist machen, weil sie 
davon ausgehen, dass das der Compiler richtig macht.

[(prx) A. K. (prx)]

Thomas schrieb:
> a) Bei x86 Architekture wären hier wohl Wait-States nötig, oder ?
> Verwunderlich ist das nur weil diese Befehle werden ja ständig in quasi
> jedem Programm durchgeführt. Muss da wirklich gewartet werden, oder
> gibts da nen Trick ?

Es muss gewartet werden. Aber Tricks gibts es schon. Dazu gehören 
out-or-order processing und symmetric multithreading aka hyperthreading. 
Es dauert mittlerweile bis zu 4 Takte, bis die Daten aus dem L1 Cache da 
sind. Also führt man zwischendrin auch andere Befehle aus, aus dem 
gleichen Thread oder auch aus anderen.

> b) Bei MIPS (without interlocked pipeline) sollte so eine
> Befehlsreihenfolge ja dann garnicht gehen, oder ?

Richtig. Ist da nicht zulässig, zumindest nicht im ursprünglichen 
Design. Heute wird das je nach Implementierung vermutlich anders 
aussehen, weil solche Fisematentchen bei Caches mit mehr als 2 Takten 
Zugriffszeit sonst existierende Programme obsolet machen und bei 
superskalaren Implementierungen absurd werden.

Die exakte Implementierung einer Pipeline für den Programmierer sichtbar 
zu machen ist eine Idee, die stets neue Architekturen voraussetzt, weil 
sich die Programmierung der jeweiligen Hardware anpassen muss. Lies: 
Entweder überleben bestehende Programme einen Wechsel der Hardware 
nicht, oder die neue Hardware tut absurderweise so als wäre sie die 
alte. Das hat MIPS feststellen und sich eigentlich umbenennen müssen. 
Intels i860 war ein recht krasses Beispiel für diesen Irrweg.

> Vielen Dank für ein paar Schubser in die richtige Richtung. Und bitte
> nicht sagen ich soll das Intel x86 Architecture Manual durchlesen. Das
> liegt schon unter dem Kopfkissen :-)

Das steht da eher nicht drin.

Interessanter sind Buch 3 und 4 von http://www.agner.org/optimize, 
jedenfalls wenn es darum geht, was in realen x86ern intern abläuft. Die 
Grundprinzipien findet man auch in Lehrmaterial im Web und natürlich auf 
abgeholzten Wäldern.

[(prx) A. K. (prx)]

A. K. schrieb:
> out-or-order processing

Tippfehler: out of order processing, oder auch out of order execution.

[(prx) A. K. (prx)]

Christian Berger schrieb:
> Das müsstest Du im Datenblatt der CPU nachschauen.

Da steht heutzutage nur noch Pinout und Stromversorgung drin. So man es 
überhaupt öffentlich kriegt. Über die implementation architecture 
erfährt man vom Hersteller selbst am ehesten noch im optimization guide, 
aber grad Intel hält sich bei diesem Thema ziemlich bedeckt.

[Thomas (Gast)]

Hallo zusammen,

http://www.agner.org/optimize ist ja ne super Seite. Da les ich mich mal 
ausführlich ein, vielen, vielen Dank !

Thomas