Rechengeschwindigkeit µC

Auch in Assembler brauchen Befehle i.A. unterschiedliche Zeiten zur 
Ausführung.

Die "Befehle" wie "lade Akku mit dem Inhalt der Speicherzelle 0x1234" 
werden meist intern noch in Mikrooperationen zerlegt. Um bei dem 
Beispiel zu bleiben:
Erster Schritt = lege die Adresse für den nächsten Befehl auf den 
Adressbus des Programmspeichers.
Zweiter Schritt = lesen das erste Byte des Befehls
Dritter Schritt = dekodiere den Befehl, um zu sehen, wie es weiter geht
Vierter Schritt = lese den Rest des Befehls
Fünfter Schritt = lege die Adresse 0x1234 auf den Adressbus des 
Datenspeichers
Sechster Schritt = lese das Byte aus dem Datenspeicher und packe es in 
den Akku.

Das Ganze kann bei unterschiedlichen Prozessorarchitekturen anders 
ablaufen, es werden u.U. einige Schritte zusammengefasst.

Und leider ist das ganze dann noch viel komplizierter. Denn ein moderner 
uC kann viele dieser oben genannten Schritte parallel ausführen, das 
nennt man dann pipelining. Zum Beispiel sind dann immer die nächsten 
fünf Befehle in der Pipeline. Während er das Resultat eines Befehls in 
den Speicher zurückschreibt, berechnet er schon das Resultat des 
nächsten und holt sich die Parameter des übernächsten vom Speicher 
etcetc.

Was aber, wenn ein (bedingter) Sprung vorkommt? Dann muss er für einige 
Befehle, die er schon vorbereitet hat, die (teil-)Resultate wieder 
wegwerfen. Nun gibt noch so schlaue Kerlchen, die versuchen, 
herauszufinden, ob der bedingte Sprung ausgeführt wird oder nicht, oder 
aber er rechnet einfach beide Varianten,..... etcetc.

Dann ist da manchmal noch der Cache. Der macht es nochmls 
komplizierter....

Du siehst, so einfach ist das nicht. Darum gibt es Benchmarks. :-)

Gruäss
Simon

Harald schrieb:
> Ein Schritt in Deinem BSP. würde aber 10ns (bei 100 MHz) brauchen oder?

Jein... speziell bei den Prozessoren der heutigen PCs ist der Speicher 
drastisch langsamer als der Prozessor. Es müssen also Warteschritte 
eingelegt werden. Moderne Prozessoren nutzen die Wartezeit für andere 
Tätigkeiten oder laden auf Verdacht schon mal mehrere Bytes am Stück 
(weil das schneller geht als sie einzeln anzufordern).

Generell gilt nur, dass keine Operation schneller ablaufen kann als "1 
Schritt", wohl aber langsamer.

Zwei Beispiele aus der Steinzeit, als alles noch einfacher war:
 - Die MCS51 Familie brauchte immer 12 Takte für eine Operation. Jeder 
Befehl wurde in maximal 2 Operationen abgearbeitet.

 - Der Z80 brauchte 4 bis 23 Takte für einen Befehl

Aber wie oben schon geschrieben: Heute ist es deutlich komplexer. Und 
Antworten auf die einfachen Fragen sind die schwersten.

und dann kommts noch drauf an welche Operation durchgeführt wird, ein 
shift geht flott, ne Fließkommadivision dauert fast endlos.

Bei den AVR's gehts am einfachsten. Die meisten Befehle benötigen einen 
oder zwei Takte. (siehe Befehlsliste im Datenblatt) Deshalb auch die 
Einschränkung auf "nur" 132 Befehle. (RISC-Befehlssatz, reduced 
instruction set).

Bei Programmierung in C oder höher wird der Befehlssatz bis ins 
Unendliche aufgebläht. Schon bei den einfachsten Befehlen wird die 
Ausführungszeit unübersichtlich, weil gleich eine komplette Bibliothek 
mit ins Programm eingebunden wird.

Ein Beispiel: Was in Assembler nur etwa 20Byte Speicher beansprucht (1ms 
Verzögerung+Ausgabe auf eine LED) wird bei Arduino-C gleich ca. 1600 
byte belegen.

Mik schrieb:
> Was natürlich falsch ist, sie brauchten mindestens 1 Taktzyklus. Warum
> soll z.B. ein NOP Befehl mehr brauchen als 1 Taktzykus? Nur die 80x86
> Schiene brauchte immer jede Menge Taktzyklen.

Die Ausführungszeit der Befehle ist bei PC-Prozessoren eine 
Definitionssache. Zählst du die Zeit zwischen fetch und retirement, oder 
nur die Zeit in execution units. Im ersten Fall kriegst du eine völlig 
vom Kontext abhängige zweistellige Anzahl Takte raus, im zweiten Fall 
kann es auch 0 sein (z.B. besagter NOP).

> so schnell wie z.B: der 6502 mit 1 MHz, der z.B für viele Befehle nur 1
> Taktzyklus braucht.

Kein einziger Befehl des 6502 war in 1 Takt fertig. Ausserdem ist das 
eine Milchmädchenrechnung, denn die Kehrseite davon war eine gegenüber 
beispielsweise Z80 viel niedrigere Taktfrequenz.

> .. eigentlich geht es hier um uC und nicht um Desktop Prozessoren

Eben. Die hier betrachtete Frage ist bei einfachen µCs noch recht 
einfach zu beantworten, aber bei PC-Prozessoren ist das eine 
hochkomplexe Angelegenheit.

Peter R. schrieb:

> Ein Beispiel: Was in Assembler nur etwa 20Byte Speicher beansprucht (1ms
> Verzögerung+Ausgabe auf eine LED)

... belegt in vernünftig geschriebenem C auch nicht wesentlich mehr.

> wird bei Arduino-C gleich ca. 1600
> byte belegen.

Das ist aber ein Problem des Komforts, der mit den Arduino-Bibliotheken 
mitkommt.
Man kann mit einem Gleitschirm die Alpen von Nord nach Süd überqueren. 
Kann man. Aber an Bord einer 737 ist der Flug von München nach Mailand 
dann doch um einiges bequemer. Das ist alles nur eine Frage der 
persönlichen Vorlieben. Der eine sieht es als sportliche 
Herausforderung, der andere will einfach nur nach Mailand und 
zwischendurch mal was Warmes essen.

123 schrieb:
> Und in welche Klasse gehört ein Cortex A8  A9  A15?

Das beantwortet schon der Name, das "A" für Application. 
Anwendungsprozessoren für Handy, Tablets etc. Als Mikrocontroller sind 
sie eher selten. Embedded Linux-Systeme solchen Kalibers betrachte ich 
auch dann nicht als Mikrocontroller, wenn man einem RPI eine LED blinken 
lässt.

123 schrieb:
> Nu ja MCUs mit ARM7 und CortexM3 / M4 erreichen mitlerweile auch schon
> fast geschwindigkeiten wo der Flash nicht mehr hinterher kommt, und SRAM
> entweder extrem teuer wird oder mit Waitstates betrieben wird.

Welcher davon betreibt sein internes SRAM mit Waitstates?

Daumenregel: Je schneller ein Prozessor ist, ob µC oder nicht, desto 
komplexer ist das Laufzeitverhalten, wenn man es auch einzelne Befehle 
und Takte runterbricht.

Mik schrieb:
> Es ist auch eine sehr negative Eigenschaft wenn man eine 8 fach
> langsamen Takt braucht um das gleiche zu erreichen. Ja sehr schlimm, Ein
> viel höherer Takt um das gleiche zu erreichen ist ja auch viiiiel
> besser. Wow hast du da jetzt eine pöse pöse  Kehrseite vom 6502
> aufgedeckt Du bist der Held des Tages.

Hab ich deinen Liebling beleidigt? ;-)

Es ist weder negativ noch positiv. Letztlich zählt, was hinten 
rauskommt.

Erreichbare Taktfrequenzen sind eine Frage der Gattertiefe pro Takt. 
Wenn zwischen zwei Takten 10 Gatterlaufzeiten liegen, dann kann man 
schneller takten, als wenn dazwischen 20 Gatterlaufzeiten liegen. Je 
mehr man in einen Takt quetscht, desto langsamer wird der Takt. Daher 
kann bei gleicher Herstellungtechnik der eine Chip bei 1 MHz am Ende 
sein, während der andere Chip 2,5 MHz schafft, aber dafür pro Takt 
weniger leistet.

War der AMD K5 überlegen, weil sein Cache nur einen Takt benötigte und 
er in der Lage war, 4 Befehle pro Takt auszuführen, während die 
Konkurrenz 2 Takte für den Cache benötigte und nur 2 Befehle pro Takt 
erledigte? Nein, das war er nicht, weil Intel zwar weniger pro Takt 
erledigte, aber wesentlich schneller taktete. Umgekehrt taktete Intels 
Pentium 4 zwar schneller als AMDs K8, erledigte (bei gegebener 
thermischer Grenze) aber oft weniger Arbeit.

Wie die Bilanz "hoher Takt mit wenig Arbeit pro Takt" (speed deamon) vs 
"niedriger Takt mit viel Arbeit pro Takt" (brainiac) ausfällt, das weiss 
man nicht immer im Vorhinein. Mal geht es so aus, mal so. Was heute so 
in schnelleren PCs so rumläuft ist ein Kompromiss aus beidem.

>> aber bei PC-Prozessoren ist das eine  hochkomplexe Angelegenheit.
>  Das es da komplexer ist ist ja auch keine Frage. Klar wir könnten auch
> noch über Herzopersatonen reden, ist auch keine einfach Sache, aber um
> das geht es hier genausowenig.

Ich war es nicht, der die x86 in die Diskussion einbrachte. Aber die 
Frage der Bilanz Takt vs Komplexität ist im µC-Umfeld ebenso zu finden. 
Die 8051 brauchten früher 12 Takte pro Operation, takteten aber auch 
viel schneller.

W.S. schrieb:
> und auch ein sauschneller interner
> Flashrom kommt selten unter die 45 ns-Marke.

Hm.

Renesas Monos Flash -- z.B. im RX-Controller -- läuft bis 100 MHz ohne 
Waitstates.

So long,
Tillomar