Allesquarks - Mi 30.03.05 19:01
Titel: Befehlsabarbeitung asm

---

Der Prozessor braucht ja für einige Befehle länger als 1 Clock cycle. Wenn die nächste Instruktion das ergebnis weiterverwendet sollte er also warten.

Wird dies automatisch getan oder fügt der Compiler NOP (non operation instructions) ein oder muss man dies selbst tun?
Wenn ja kennt hier jemand eine Seite, wo die alle clock cycles für alle assemblerbefehle aufgelistet sind?

Vielen Dank schon einmal!

uall@ogc - Mi 30.03.05 19:17

---

fast alle assembler befehle brauchen mehr als einne takt
z.b. braucht glaub ich nen cmp reg, reg 7 takte
aber der prozessor führ immer den gesamten befehl aus nicht immer nur einen takt

hab anenr uni nen buch gefudnen wo alle drinstehen aber im inet hab cih das noch net gesehen
aber was willst du überhaupt machen?

Allesquarks - Mi 30.03.05 19:54

---

Schreibe an einem Taschenrechner.
Plane Zahlen beliebig genau zu berechnen. Dazu muss ich aber die Verwaltung der Zahlen selbst übernehmen, da Delphi leider gerne selbst eingreift. Gibt Zahlen z.B. 43538E89 zurück. Dann sind aber 85 stellen verlorengegangen.

Deshalb müsste ich wissen, ob der Prozessor weiterrechnet wenn die FPU aktiv ist, oder anhält. Entsprechendes gilt für imul (integermultiplikation), wenn das Ergebnis noch nicht vorliegt könnte man mit der CPU ja entweder auf das Ergebnis warten oder aber andere Schritte ausführen, die das Ergebnis nicht brauchen.

Da zweiteres performancetechnisch viel sinnvoller wäre würde ich sagen, dass ich nops einfügen muss. Aber der Delphi-Compiler erkennt ja auch belanglosen Code, so dass es ja auch möglich wäre, dass er erkennt ob man das Resultat braucht und den Assemblercode entsprechend angepasst compiliert.

Im speziellen brauche ich dafür eigentlich nur die Ausführungslänge derarithmetischen Grundoperationen auf FPU, CPU sowie FPush, Fpop etc..

UC-Chewie - Mi 30.03.05 20:02

---

Abgesehen davon, dass dir mal eine intensive Auseinandersetzung mit Rechnerarchitektur allgemein guttun würde, würde es deinem Verständnis auch schon helfen, wenn du dich mal über die Darstellung von Kommazahlen in einem Rechner informierst: IEEE 754, GLEITKOMMA* ;)

Allesquarks - Mi 30.03.05 20:19

---

Nicht bös gemeint aber ich glaube du hast mich missverstnden. Ich weiß recht gut wie der Computer von innen aussieht, weiß auch wie ich das implementieren muss, weiß bloß wenig über Delphi.

Weiß nicht ob ich uall@ogc richtig verstanden hab, dass der Prozessor sowieso immer auf die Berechnungsbeendigung wartet. Dann wäre alles paletti!

Wenn es aber anders geht wäre es nur um einiges schneller und speziell bei dieser Anwendung von Vorteil. Und um dich zu beruhigen. Habe schon etliche Internetseiten über Computerarchitektur gewälzt plus Bücher. Bloß leider behal#ndeln die das Thema Befehle eigentlich immer nur qualitativ.

UC-Chewie - Mi 30.03.05 20:49

---

Nun, es macht halt den Eindruck, dass du nicht wirklich weißt, wie Gleitkommazahlen dargestellt werden.

Die Sache ist nur die, dass immer nur ein Befehl gleichzeitig abgearbeitet wird, egal, wie viele Takte der braucht, egal, ob er in der ALU, FPU oder sonstwo abgearbeitet wird. Während dieser Zeit mag die CPU zwar Sachen wie OpCode-Prefetching durchführen, darauf hast du als Programmierer aber keinen Einfluss.

Und selbst wenn es da eine Möglichkeit gäbe, wäre es äußerst unwahrscheinlich, dass du das mit einem Windows-Programm im User-Mode schaffst.

BenBE - Mi 30.03.05 21:34

---

Ja, du hast uall richtig verstanden: Die CPU wartet auf die Beendigung der vorherigen Befehle.

Allerdings gibt es dort einige Ausnahmen, die mit
1. Prefetching
2. Befehlstypen zu tun haben
3. Der verarbeitenden Einheit \ Folgebefehl zu tun haben.

Allerdings hast Du auf 1 keinen Einfluss, die BEfehle von 2 darf man im Realmode nicht ausführen und alles was in 3 rein fällt, kümmert sich die CPU drum.

Von daher kannst Du diesen ganzen Zusatz hier vergessen und dir den ersten Satz dieses Postings merken.

delfiphan - Mi 30.03.05 22:05

---

Die CPU berechnen schon mal Sachen parallel, obwohl sie seriell im Maschinencode stehen. Es gibt auch kompliziertere Sachen wie Branch Prediction: Bei einer Verzweigung im Code wählt die CPU einen der beiden Wege aus und rechnet schon mal voraus. Falls der Prozessor den falschen Weg getippt hat macht er das dann wieder rückgängig. Fast noch unglaublicher: Die CISC Befehle, also der normale Maschinencode, wird intern in RISC umgewandelt, weil dieser besser parallel ausgeführt werden kann. Der Maschinencode wird also zuerst in eine interne vereinfachte Sprache übersetzt und dann erst ausgeführt ;)
Aber das muss man alles gar nicht wissen, da man nichts davon mitbekommt. Einzig bei der FPU, da muss man vor Speicherzugriffen ein wait machen. Das liegt, wenn ich mich nicht täusche, daran, dass die FPU keinen direkten Zugriff auf die CPU hat (früher war der Co-Prozessor noch ein separater Chip).

Allesquarks hat folgendes geschrieben:

Dann sind aber 85 stellen verlorengegangen.

Äh, 85 Stellen??
Die E-Notation wird von floattostr generiert und hat mir der Floatingpointzahl an sich nicht viel zu tun. Die Floatingpointzahl hat immer eine Mantisse + Exponent. Eine 4 wird intern als 1*2^2 gespeichert, von floattostr aber als "4" dargestellt.
Man hat bei einer Floatingpointzahl immer gleich viele Nachkommastellen, deswegen auch der Name Gleitkommazahl (Man gibt die Zahl + die Position des Kommas an...)
Wenn du mit 85 Nachkommastellen rechnen willst, wirst du dein eigenes Format und eigene Rechenroutinen schreiben müssen.

Allesquarks - Mi 30.03.05 22:10

---

genau dieses eigene Zahlenformat schreibe ich ja. Dann natürlich binär direkt mit mantisse und exponent. Ist wirklich mit strtofloat. Hab das mit dem E geschrieben, weil das meinen Plotter immer zum Absturz bringt. Ändert aber nichts, dass auch bei extended die mantisse nicht die STellenanzahl hat, die der Exponent erlauben würde hab das Beispiel halt nur dezimal gemacht.

Jedenfalls danke für eure Erklärungen haben sehr geholfen.