Hallo ! Ich habe leider immer noch eine Verständnislücke, was den Begriff "Befehlszyklus" angeht. Ein Lade-Befehl der einen Speicherinhalt in ein Register schreibt, muss doch wesentlich länger dauern, als ein MOV Befehl von einem Register in ein anderes (Für einen langsameren RAM braucht man ja schon alleine mehr "wait states"). Brauchen jetzt die verschiedenen Maschinenbefehle unterschiedlich lange? Falls ja, wir verträgt sich dies mit einer Pipeline? Wenn der Befehl <n> gerade ausgeführt wird, wird <n-1> gerade dekodiert und <n-2> gerade geladen. Ist das Laden des Speicherinhalts (nicht des dahinterstehenden Befehls) nun Bestandteil des Execution-Zyklus oder gehört dies in den Fetch-Teil? Ich würde sagen, es ist Teil des Execution Teils. Das würde aber heißen, dass die Dauer eines Pipelineschrittes variabel wäre und sich am langsamsten Slot (in diesem Fall Execution) orientiert. Irgendwie verstehe ich dies nicht .... Ich dachte ein Pipelineschritt dauert immer gleich viele Zyklen. Kann mich hier bitte jemand aufklären? Danke!
Michael W. schrieb: > Brauchen jetzt die verschiedenen Maschinenbefehle unterschiedlich lange? Ja. > Falls ja, wir verträgt sich dies mit einer Pipeline? Load/Store brauchen oft mehr Stufen als Reg/Reg Operationen. > gerade ausgeführt wird, wird <n-1> gerade dekodiert und <n-2> gerade > geladen. Ist das Laden des Speicherinhalts (nicht des dahinterstehenden > Befehls) nun Bestandteil des Execution-Zyklus oder gehört dies in den > Fetch-Teil? Hier: Instruction Fetch. > Das würde aber heißen, dass die Dauer eines > Pipelineschrittes variabel wäre und sich am langsamsten Slot orientiert. > Irgendwie verstehe ich dies nicht .... Wenn die Pipeline schneller als der Instruction Cache ist, dann gibt es mehrere Pipeline-Stufen dafür. Heutzutage dauern Cache-Zugriffe bei schnelleren CPUs 3-4 Takte, mit entsprechend vielen Pipeline-Stufen. Bei Mikrocontrollern sieht das insofern anders aus, als die oft nicht für hohe Leistung sondern für einfachen Aufbau optimiert sind. So wird bei AVRs der maximale Takt vom Flash-Zugriff diktiert. Internes SRAM kommt bis einige hundert MHz ungebremst mit, Flash in den meisten Implementierungen jedoch nur bis 20-40MHz.
:
Bearbeitet durch User
Danke für die Antworten! Angenommen der Befehl lautet: R1 = [I0] D.h. Register 1 soll mit dem Inhalt der durch I0 indizierten RAM Zelle befüllt werden. Diese liegt nicht in einem Cache. Ich verstehe es so, dass die Anweisung "R1 = [I0]" zunächst als "nächste Instruktion" aus dem RAM bzw. Cache geladen wird. Dies geschieht über den Program Counter während eines Fetch Zyklus. In der nächsten Stufe der Pipeline wird der Befehl dann dekodiert und in der Execution Stufe schließlich ausgeführt. Die Ausführung des Befehls "R1 = [I0]" erfordert aber wiederum einen RAM Zugriff. Heißt das nun, dass dieser Datenzugriff ebenfalls in den Fetch-Zyklus fällt? Ich dachte, das wäre die Execution? Jetzt bin ich total verwirrt... Kann mir jemand den Ablauf dieses Befehls in der Pipeline darstellen? Wie sieht es darüberhinaus mit direkten Operanden aus, die nach dem Befehl stehen? z.B. R1 = 0x00110000 Dan benötigt der Operand doch einen zusätzlichen Lese-Zyklus und das vollständige Laden des Befehls + Operand muss länger dauern als ein einfaches "RETS", welches ja keinen Operanden hat.
Michael W. schrieb: > Diese liegt nicht in einem Cache. Dann darft du auf Highend-CPUs mit einer Gesamtlaufzeit von dreistelligen Takten rechnen und irgendwelche Pipelines sind weniger interessant. Warum: Bei grob gepeilten 50ns Speicherzugriffszeit und 4GHz Prozessortakt sollte das notfalls auch ohne Taschenrechner klar sein. > Ich verstehe es so, dass die Anweisung "R1 = [I0]" zunächst als "nächste > Instruktion" aus dem RAM bzw. Cache geladen wird. Dies geschieht über > den Program Counter während eines Fetch Zyklus. Im Prinzip ja, nur ob es ein Zyklus ist wäre die Frage. > Kann mir jemand den Ablauf dieses Befehls in der Pipeline darstellen? Wenn du vom dir bekannten sehr einfachen Prinzipschema weg in die Realität willst musst du erst einmal klarstellen, auf welche Klasse du dich beziehst. Im Mikrocontroller-Forum - wo du die Frage gestellt hast - gelten dabei völlig andere Regeln als bei x86/Power/Cortex-A. Dieses Prinzipschema war in den 80ern noch relativ dicht an der Realität. Heute kann man das noch auf Mikrocontroller bis ARM7 und Cortex-M ungefähr anwenden, aber die unterscheiden sich dabei auch nicht wesentlich von dem, was man in den 80ern baute, sind nur höher integriert. Die jeweiligen High-End CPUs haben sich in den 3 Jahrzehnten seither massiv weiterentwickelt und das bekannte fetch/decode/execute Schema ist kaum noch wiederzuerkennen. > Wie sieht es darüberhinaus mit direkten Operanden aus, die nach dem > Befehl stehen? Heutige x86 können pro Takt oft 3-4 Befehle dem Cache holen und dekodieren, Konstanten im Befehl inklusive, begrenzt von einem Längenlimit von z.B. 16 Bytes insgesamt (teils mehr, hab aber nicht im Kopf wieviel genau). Hat sich das damit beantwortet? ;-)
:
Bearbeitet durch User
Das heißt also, dass die Pipeline für die Dauer eines externen und langsamen Speicherzugriffs quasi "gestoppt" wird, und alles nur darauf wartet, bis die Daten aus dem RAM vorhanden sind? Kann man allgemein sagen, dass Zugriffe auf den internen RAM eines Mikro-Controllers so schnell ist, dass diese auch bei der höchsten zulässigen Taktfrequenz (z.B. 120MHz) ohne interne Wait-States in einem Takt-Zyklus funktionieren? Ansonsten habe ich es denke ich verstanden. Insbesondere der Hinweis, dass die klassische Pipeline Sicht nur wenig mit der Realität zu tun hat, war eine Hilfe. Danke ;)
Michael W. schrieb: > Das heißt also, dass die Pipeline für die Dauer eines externen und > langsamen Speicherzugriffs quasi "gestoppt" wird, und alles nur darauf > wartet, bis die Daten aus dem RAM vorhanden sind? Letztlich ja. Untere zweistellige Wartetakte lassen sich teilweise durch die effektiv wirksame Pipeline kompensieren, wodurch L2-Cache-Hits noch nicht voll durchschlagen, aber jenseits davon... Highend-CPUs sind ohne Caches nicht denkbar und irgendwelche Pipeline-Darstellungen sind stets mit Hit im L1-Cache gezeichnet. Intels Hyperthreading verwendet einen CPU-Core verzahnt für zwei parallele Threads. Wartezeiten eines Threads legen also den Core nicht lahm, solange der andere Thread noch was zu tun hat. AMD ist das etwas angegangen. > Kann man allgemein sagen, dass Zugriffe auf den internen RAM eines > Mikro-Controllers so schnell ist, dass diese auch bei der höchsten > zulässigen Taktfrequenz (z.B. 120MHz) ohne interne Wait-States in einem > Takt-Zyklus funktionieren? Bei RAM ja. Bei Flash ist bei 120MHz aber meist irgendeine Form von Caching beteiligt, da ein Flash-Zugriff dann mehrere Takte braucht. Auch wenn das nicht immer so genannt wird (z.B. flash accelerator).
:
Bearbeitet durch User
Danke ! Ich möchte bei dieser Gelegenheit einmal fragen, wie CPUs heute entworfen werden? Haben die Firmen da eigene Tools oder läuft das nach Standards wie VHDL o.ä.? Wie überschaut man derartige Komplexitäten denn überhaupt? Und wie ging das früher (70-er Jahre), als Synthesewerkzeuge noch nicht bekannt waren? Entwarfen die Entwickler damals die digitalen Komponenten einer CPU per Hand?
Michael W. schrieb: > Ich möchte bei dieser Gelegenheit einmal fragen, wie CPUs heute > entworfen werden? Haben die Firmen da eigene Tools oder läuft das nach > Standards wie VHDL o.ä.? Bei den Highends musst du die Leute in deren Entwicklungsbüros fragen. Generell ist klar, dass in hohem Mass synthetisiert wird. Aber manche Komponenten sind auch bis runter auf den Nanometer manuell optimiert, wie etwa RAM-Zellen, weils davon genug gibt. Manche ARM-Cores kann man auch in VHDL/Verilog statt fertig layoutet kaufen, wenn der Kunde das so besser in seinen Prozess integriert kriegt. Das -S in den ARM7TDMI-S steht dafür. > Und wie ging das früher (70-er Jahre), als Synthesewerkzeuge noch nicht > bekannt waren? Entwarfen die Entwickler damals die digitalen Komponenten > einer CPU per Hand? Ja.
:
Bearbeitet durch User
Michael W. schrieb: > Und wie ging das früher (70-er Jahre), als Synthesewerkzeuge noch nicht > bekannt waren? Entwarfen die Entwickler damals die digitalen Komponenten > einer CPU per Hand? Auf dem Zeichenbrett die Masken maßstabsgerecht zeichnen (mit Tusche auf Pergamentpapier), verkleinern und schon hat man die Belichtungsmasken für die CPU-Herstellung. Damals wurde allerdings noch mit 10µm Strukturgröße gearbeitet...
Wer sich für den Aufbau moderner CPUs interessiert, der kann hier was drüber lernen, Buch 3: http://agner.org/optimize/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.