Meine Verständnisfrage lautet: Warum werden die Atmel MCUs (atmega) 8-bit Prozessoren genannt? Im debugger sieht es so aus, als wenn auch 16 bit pro Takt verarbeitet werden. Ich weiß, dass bei der Harvard-Architektur in die versch. Speicher parallel gelesen/geschrieben werden kann, aber dennoch: Beispiel: C012 RJMP PC+0x0013 benötigt zwei Takte. Logisch, denn es muss das erste Byte gelesen werden um den Befehl zu erkennen und das zweite um den Parameter zu lesen? und/oder den Sprung auszuführen? (bitte erklären) EC0D LDI R16,0xCD benötigt nur einen Takt. Warum? Es müssen doch zwei Byte gelesen werden und etwas in den SRAM geschrieben werden. 95C8 LPM benötigt drei Takte. Denn es muss: der zwei Byte große Befehl gelesen werden und ein Byte von Adresse r30:r31 aus dem Flash in r0 gespeichert werden. Welche Aktion davon benötigt wieviele Takte? 2000 TST R0 benötigt nur einen Takt. Dabei müssen die zwei Byte des Befehls gelesen werden, r0&r0 gerechnet werden und ggf. das Zero-Flag gesetzt werden. Warum werden dafür nicht vier, sondern nur ein Takt gebraucht? Ich hoffe jemand kann mir das erklären;)
Daniel R. schrieb: > Warum werden die Atmel MCUs (atmega) 8-bit Prozessoren genannt? Weil der Datenbus interne 8bit Breit ist.
Daniel R. schrieb: > Beispiel: C012 RJMP PC+0x0013 benötigt zwei Takte. Logisch, denn es > muss das erste Byte gelesen werden um den Befehl zu erkennen und das > zweite um den Parameter zu lesen? und/oder den Sprung auszuführen? Nein. Der erste Takt führt den Befehl aus, der zweite liest das erste Befehlswort an der Zieladresse. Bei sequentiellem Code wird während der Ausführung eines Befehls das erste Wort des Folgebefehls gelesen, weshalb die Ladezeit des Codeworts nicht separat in der Laufzeit auftaucht. Bei Sprungbefehlen sieht das natürlich anders aus. Aus dieser Überlegung heraus ergibt sich auch mühelos, weshalb nicht ausgeführte Sprungbefehle beim AVR schneller sind als ausgeführte. > EC0D LDI R16,0xCD benötigt nur einen Takt. Warum? Es müssen doch zwei > Byte gelesen werden und etwas in den SRAM geschrieben werden. Das ROM arbeitet beim AVR in Codeworten von 16 Bits Breite, die Befehlslänge geht also wortweise in die Laufzeit ein, nicht byteweise. > 95C8 LPM benötigt drei Takte. Denn es muss: der zwei Byte große Befehl > gelesen werden und ein Byte von Adresse r30:r31 aus dem Flash in r0 > gespeichert werden. Welche Aktion davon benötigt wieviele Takte? Datenbefehle über Busgrenzen sind nur wirklich verständlich, wenn man die Internstruktur des Prozessors analysiert. Dieser Befehl muss den Datenbus mit dem Befehlsbus koppeln, was den Ablauf etwas ins Stocken bringt. > 2000 TST R0 benötigt nur einen Takt. Dabei müssen die zwei Byte des > Befehls gelesen werden, r0&r0 gerechnet werden und ggf. das Zero-Flag > gesetzt werden. Warum werden dafür nicht vier, sondern nur ein Takt > gebraucht? Das Z-Flag ist ebenso das Ergebnis der ALU-Operation wie das hier verworfene Ergebnis vom AND, trägt also nicht separat zur Laufzeit bei.
:
Bearbeitet durch User
A. K. schrieb: > Aus dieser Überlegung heraus ergibt sich auch mühelos, weshalb nicht > ausgeführte Sprungbefehle beim AVR schneller sind als ausgeführte. Also, im Falle wenn der pc z.B auf F7E1 BRNE PC-0x03 steht, wäre das Byte 0xF7 schon geladen. Führt man diesen Befehl nun aus, wird: -Byte 0xE1 gelesen - -0x03 (Einerkomplement) auf den pc addiert und gleichzeitig 1 Byte des Folgebefehls gelesen -pc += 1 gerechnet -Das erste Byte des Befehls auf den pc zeigt gelesen (fällt bei nicht-ausgeführtem Sprung weg) Welche dieser vier Schritte finden im ersten und welche im zweiten Takt statt? Wird nicht gesprungen, braucht der Befehl nur einen Takt. Ich nehme an, während der pc auf das Sprungziel gesetzt wird, wird auch das erste Byte des Folgebefehls gelesen (des Befehls der direkt hinter BRNE steht). Wenn gesprungen wurde ist der nächste auszuführende Befehl dann aber der an der Sprungzieladresse, also muss dessen erstes Byte nachträglich noch geladen werden, was das zusätzliche benötigte Byte erklären könnte. > Das ROM arbeitet beim AVR in Codeworten von 16 Bits Breite, die > Befehlslänge geht also wortweise in die Laufzeit ein, nicht byteweise. Das klingt, als wenn du meintest es würde Wortweise gelesen werden. Wie ist das gemeint? > Datenbefehle über Busgrenzen sind nur wirklich verständlich, wenn man > die Internstruktur des Prozessors analysiert. Dieser Befehl muss den > Datenbus mit dem Befehlsbus koppeln, was den Ablauf etwas ins Stocken > bringt. Ja das war ein schlechtes Beispiel von mir, das war mir klar. Ich habe es nur gewählt, weil es das einzige Beispiel war, dass zu meiner Vorstellung der zu benötigenden Takte gepasst hatte. > Das Z-Flag ist ebenso das Ergebnis der ALU-Operation wie das hier > verworfene Ergebnis vom AND, trägt also nicht separat zur Laufzeit bei. Ok, das Byte 0x20 ist bereits geladen, deswegen ist schon gekannt welcher Befehl ausgeführt werden soll. Aber der kann ja nicht ausgeführt werden bevor das zweite Byte mit dem benötigten Parameter (Registernummer) geladen wurde. Dass die SREG Bits gleichzeitig mit dem Rechenergebnis von der ALU geschrieben werden leuchtet ein. Doch ist es wirklich so, dass der Befehl ausgeführt wird, während noch nicht gekannt ist mit welchem Registerinhalt gerechnet werden soll? Welche Ereignisse finden dazu parallel/sequentiell innerhalb eines Taktes statt? Wann innerhalb eines Taktes wird denn der pc hochgezählt? Zu irgendeinem Zeitpunkt muss ja anscheinend ein nebenläufiger Prozess (VHDL-Denkweise) gestartet werden, der 1)pc++ 2)lade ein Byte von (pc) ausführt. Vielen Dank für die ausführliche Antwort;)
Daniel R. schrieb: > A. K. schrieb: >> Aus dieser Überlegung heraus ergibt sich auch mühelos, weshalb nicht >> ausgeführte Sprungbefehle beim AVR schneller sind als ausgeführte. > > Also, im Falle wenn der pc z.B auf F7E1 BRNE PC-0x03 steht, wäre das > Byte 0xF7 schon geladen. Beide Bytes sind geladen. Der Code wird immer wortweise geladen. Führt man diesen Befehl nun aus, wird: > -Byte 0xE1 gelesen > - -0x03 (Einerkomplement) auf den pc addiert und gleichzeitig 1 Byte des > Folgebefehls gelesen Der Folgebefehl wird komplett gelesen, nicht nur zur Hälfte. Falls der Sprung nicht ausgefürt wird, bringt das natürlich nichts, und der gelesene Befehl muß verworfen werden. Deshalb dauert es einen Takt länger, weil nun der Befehl an der neuen Adresse erst geladen werden muß. > Welche dieser vier Schritte finden im ersten und welche im zweiten Takt > statt? Zusammengefasst: Im ersten Takt wird der Sprungbefehl ausgewertet und je nach Flags entweder gesprungen oder nicht. Gleichzeitig wird der Befehl nach dem Sprungbefehl geladen. Falls der Sprung nicht ausgeführt wurde, gibt es keinen zweiten Takt. Der nun bereits geladene nächste Befehl wird einfach ausgefürt. Falls der Sprung durchgeführt wird, wird im zweiten Takt der geladene nächste Befehl verworfen und der der Befehl an der Zieladresse geladen. >> Das ROM arbeitet beim AVR in Codeworten von 16 Bits Breite, die >> Befehlslänge geht also wortweise in die Laufzeit ein, nicht byteweise. > > Das klingt, als wenn du meintest es würde Wortweise gelesen werden. Wie > ist das gemeint? Genau so. Der Codespeicher ist 16 Bit breit. Einzelne Bytes kann man von dort gar nicht lesen.
Daniel R. schrieb: > Also, im Falle wenn der pc z.B auf F7E1 BRNE PC-0x03 steht, wäre das > Byte 0xF7 schon geladen. Nein, as ganze Befehlswort F7E1 am Stück. > nehme an, während der pc auf das Sprungziel gesetzt wird, wird auch das > erste Byte des Folgebefehls gelesen Wort, nicht Byte. > Das klingt, als wenn du meintest es würde Wortweise gelesen werden. Genau das. Das Flash ist in Nx16 Bits organisiert und der PC zählt Worte statt Bytes. Nur bei LPM gibt es Byteadressen vom Flash. Der Atmel-Assembler zählt ebenfalls Worte. Wenn das Asm-Listing von GCC Bytes anzeigt, dann aufgrund der Arbeitsweise der Binutils vom GCC. > Wann innerhalb eines Taktes wird denn der pc hochgezählt? Inwieweit sollte das relevant sein? > Zu irgendeinem > Zeitpunkt muss ja anscheinend ein nebenläufiger Prozess (VHDL-Denkweise) > gestartet werden, der 1)pc++ 2)lade ein Byte von (pc) ausführt. Das ist nicht der einzige nebenläufige Prozess.
:
Bearbeitet durch User
Schau mal hier vorbei, da wird ein Modell der Mikroarchitektur von AVR Prozessoren eingehend beschrieben: http://web.engr.oregonstate.edu/~sinky/teaching/4.AVR_Microarchitecture.pdf
Rolf Magnus schrieb: > Der Folgebefehl wird komplett gelesen, nicht nur zur Hälfte. Falls der > Sprung nicht ausgefürt wird, bringt das natürlich nichts, und der > gelesene Befehl muß verworfen werden. Andersrum: Der Folgebefehl wird komplett gelesen, nicht nur zur Hälfte. Falls der Sprung ausgeführt wird, bringt das natürlich nichts, und der gelesene Befehl muß verworfen werden.
A. K. schrieb: > Andersrum Äh, ja. Ich hätt's wohl nochmal lesen sollen vor dem Absenden. Danke für die Korrektur.
Hi @ Daniel R. (dan066) Sieh mal in einem AVR-Datenblatt deiner Wahl unter: Instruction Execution Timing nach. MfG Spess
Vielen Dank für die zahlreichen Antworten. Wenn die Instruktionen wortweise geladen werden (was mir nicht klar war), ändert das einiges. Ich dachte, dass der breiteste Datenbus bei einer 8-bit MCU eben 8-bit breit wäre (wie z.B. auf dem ersten Bild zu sehen: http://avrindia.blogspot.de/2009/02/word-about-avr-architecture.html). Das hätte bedeutet, dass eben jew. eine halbe Instruktion auf einmal aus dem Flash zum Instruction Decoder bzw. dessen Speicher transportiert werden kann. Dafür würde sprechen, dass über lpm auch "nur" ein Byte geladen werden können (und es keinen Befehl für ein ganzes Wort gibt). Dagegen würde sprechen, dass im pc auch eine Wortadresse steht. Allerdings ist hier http://web.engr.oregonstate.edu/~sinky/teaching/4.AVR_Microarchitecture.pdf (was wesentlich aufschlussreicher ist) zu sehen, dass es auch viele 16-bit Leitungen gibt (u.a. ein vom Program Memory ausgehende 16-bit Leitung). Lediglich von/zur ALU und vom Data Memory laufen nur 8-bit Leitungen. (heißt die MCU deshalb 8-bit MCU?). Steht der pc auf F7E1 BRNE PC-0x03 wurde 0xF7E1 im Fetch-Prozess des vorherigen Taktes (wenn man das so nennen darf) aus dem Program Memory ins Instruction Register geladen. Zusätzlich befindet sich das Sprungziel schon im NextProgramCounter-Register. Im folgenden BRNE_Takt1 werden (Z-Bit = 0) nebenläufig: -Im Fetch Prozess: Instruction von pc+1 ins Instruction Register geladen und pc++ gerechnet. -Im Execution Prozess: Der NPC durch den Address Adder geschleust (am Taktende in den pc geschrieben). Im darauffolgenden BRNE_Takt2 werden nebenläufig: -Im Fetch Prozess: Instruction von pc(Sprungziel) ins Instruction Register geladen und pc++ gerechnet. -Im Execution Prozess: Im letzten Takt geladene Instruction nicht ausgeführt, sondern gar nichts getan. Denn es wurde ja gesprungen und old_pc+1 soll nicht ausgeführt werden. War das Z-Bit=1, das heißt es sollte nicht gesprungen werden, werden im BRNE_Takt2 nebenläufig: -Im Fetch Prozess: Instruction von pc+1 geladen (wurde ja im BRNE_Takt1 um eins erhöht. -Im Execution Prozess: Die im BRNE_Takt1 Fetch Prozess geladene Instruction ausgeführt. Stimmt das so?
Daniel R. schrieb: > Wenn die Instruktionen wortweise geladen werden (was mir nicht klar > war), ändert das einiges. > Ich dachte, dass der breiteste Datenbus bei einer 8-bit MCU eben 8-bit > breit wäre Der Bus auf dem die Instruktionen gelesen werden, ist kein Datenbus. Zumindest nicht bei den AVR 8-Bittern. Stichword Harvard-Architektur. Siehe Prozessorarchitekturen XL
Daniel R. schrieb: > (was wesentlich aufschlussreicher ist) Zur Klarstellung: Das PDF präsentiert ein Modell für einen Teil des AVR Befehlssatzes. So lässt sich beispielsweise LDS darin nicht unverändert abbilden. > Stimmt das so? Ja.
:
Bearbeitet durch User
Daniel R. schrieb: > Ich dachte, dass der breiteste Datenbus bei einer 8-bit MCU eben 8-bit > breit wäre (wie z.B. auf dem ersten Bild zu sehen: Solche stark vereinfachten Skizzen sind nicht notwendigerweise ein Abbild der realen Implementierung. Heutige CPUs enthalten oft eine Vielzahl an Pfaden unterschiedlicher Breite, wie im PDF deutlich wird. Aber auch schon in dieser Skizze wird deutlich, dass die Befehle nicht den dort dargestellten Datenbus nutzen, sondern unabhängig vom Datenbus sind: links im Bild zu sehen.
Daniel R. schrieb: > Lediglich von/zur ALU und vom Data Memory laufen nur 8-bit > Leitungen. (heißt die MCU deshalb 8-bit MCU?). Es gibt kein narrensicheres Kriterium für eine "soundsoviel Bit MCU", weil sich für jedes Kriterium Beispiele finden lassen, die es ad absurdum führen. So müssen die Busbreite und ALU-Breite nicht mit der Breite der Datenregister übereinstimmen. Der 68008 Prozessor hatte aus Sicht des Programmierers eine 32-Bit Architektur, intern implementiert aus 16-Bit Grundelementen, und hatte einen externen 8-Bit Bus. Die ALU von Motorolas 8-Bit MCU 6804 war sogar bitseriell, also 1 Bit breit. Bei den AVRs passt aber alles zusammen, also ALU, Register und interner Datenbus.
:
Bearbeitet durch User
Daniel R. schrieb: > Dafür würde sprechen, dass über lpm auch "nur" ein Byte > geladen werden können Du solltest dich nicht ausgerechnet an dem einzigen Befehl aufhängen, der völlig quer zur internen Implementierung als Harvard-Architektur liegt. Der erste AVR (AT90S1200) hatte übrigens weder LPM noch LDS.
A. K. schrieb: > dem einzigen Befehl aufhängen, > der völlig quer zur internen Implementierung als Harvard-Architektur So ein Befehl wird benötigt, da man nach reiner Harvard-Lehre sonst keine Tabellen oder Strings im Programmspeicher lesen könnte. Man könnte argumentieren, durch so einen Befehl wird Harvard erst voll nutzbar. Dafür muss man auch in Kauf nehmen, dass je nach Befehlssatz dort keine Bytes stehen, sondern ev. auch 11 oder 12 oder 13 bit. Aber immer noch besser davon 8bit als garkeine String-Konstanten. Georg
Georg schrieb: > So ein Befehl wird benötigt, da man nach reiner Harvard-Lehre sonst > keine Tabellen oder Strings im Programmspeicher lesen könnte. Und? Ohne ist umständlich, geht aber. Hier ging es jedoch eher darum, dass der TO sich bei der Analyse des Ablaufs in einem AVR diesem Befehl eher zuletzt als zuerst widmen sollte.
:
Bearbeitet durch User
Was die Kategorisierung der Bitbreite anbelangt, würde ich es an den Rechenbefehlen fest machen: Bsp.: Die Additon kann bei den AVRs nur mit 8 Bit Operanten ausgeführt werden. Kleine Übungsfrage: Wie muss die Bitbreite bei diesem Prozessor angegeben werden? http://www.greenarraychips.com/home/documents/greg/PB001-100503-GA144-1-10.pdf
chris_ schrieb: > Bsp.: Die Additon kann bei den AVRs nur mit 8 Bit Operanten ausgeführt > werden. Nein. Es gibt die Instruktionen adiw und sbiw, die 16 Bit verarbeiten. Allerdings sind das wohl auch so ziemlich die überflüssigsten Instruktionen der AVRs, denn sie sind nicht schneller als die Ausführung derselben Sache als zwei 8 Bit-Operationen und obendrein im Unterschied zu diesen nichtmal auf alle Register der oberen Hälfte anwendbar. Der einzige Vorteil ist halt die Platzersparnis im Flash. Die so weitgehend verschwendeten Opcodes hätte Atmel besser verwenden können, um meine persönliche Hitliste der "fehlenden" Instruktionen zu verkleinern, das wären: cpsne eori lpmd cpci
>Nein. Es gibt die Instruktionen adiw und sbiw, die 16 Bit verarbeiten. Also in Wahrheit sind die AVRs ja 32 Bit-CPUs: http://hobby-roboter.de/forum/viewtopic.php?f=4&t=76
>Ich dachte, dass der breiteste Datenbus bei einer 8-bit MCU eben 8-bit >breit wäre .... >Das hätte bedeutet, dass eben jew. eine halbe Instruktion auf einmal aus >dem Flash zum Instruction Decoder bzw. dessen Speicher transportiert Instrukt-bus ist nicht Datenbus (egal ob Harvard oder sonst) >Der erste AVR (AT90S1200) hatte übrigens weder LPM noch LDS. Auch die ersten AVRs (bsp AT90S2333 oder ..8535) hatten LPM u LDS. >Die so weitgehend verschwendeten Opcodes hätte Atmel besser verwenden >können, es würde auch nichts schaden, den Bef.satz mal (um einige OP-code bits) zu erweitern. (aber Atmel klebt da ja fest)
MCUA schrieb: >>Der erste AVR (AT90S1200) hatte übrigens weder LPM noch LDS. > Auch die ersten AVRs (bsp AT90S2333 oder ..8535) hatten LPM u LDS. Der AT90S1200 hat das jedenfalls nicht. Aber mag sein, dass er nicht der erste war.
:
Bearbeitet durch User
Hi
>Der erste AVR (AT90S1200) hatte übrigens weder LPM noch LDS.
Wozu sollte ein RAMloser Controller Befehle für den RAM-Zugriff haben?
MfG Spess
Georg schrieb: > So ein Befehl wird benötigt, da man nach reiner Harvard-Lehre sonst > keine Tabellen oder Strings im Programmspeicher lesen könnte. Alte PICs (auch Harvard) hatten keinen solchen Befehl(*), Tabellen im Flash/ROM hat man über einen indirekten Sprung in eine Serie von "RETLW <DATA>"-Befehlen gemacht. Ging also auch ohne direktes "LPM"-Äquivalent. (*: Ging glaube ich sonst nur super umständlich ähnlich wie der EEPRom-Zugriff mit Register-Füllen & Wait-NOPS, dafür könnte man auch alle 14 Bits des Befehlswortes auf einmal lesen, die dann über zwei Register verteilt waren)
spess53 schrieb: > Wozu sollte ein RAMloser Controller Befehle für den RAM-Zugriff haben? Das ist natürlich ein Argument. ;-) Aber LPM hat er auch nicht. Und ROM hat er.
Εrnst B✶ schrieb: > ähnlich wie der > EEPRom-Zugriff mit Register-Füllen & Wait-NOPS Korrekt & Es ist auch ohne Wait, interruptgesteuert möglich.
:
Bearbeitet durch User
Εrnst B✶ schrieb: > Alte PICs (auch Harvard) hatten keinen solchen Befehl(*), Tabellen im > Flash/ROM hat man über einen indirekten Sprung in eine Serie von "RETLW > <DATA>"-Befehlen gemacht. Intels 8048 war auch nicht viel besser. Der konnte nur innerhalb der aktuellen 256 Byte Page aus dem ROM laden, und aus Page 3. Das machte bei grossen Tabellen ähnlich viel Spass.
Hi
>Aber LPM hat er auch nicht. Und ROM hat er.
Aber sinniger weise ld rd,z/st z,rd.
MfG Spess
spess53 schrieb: > Aber sinniger weise ld rd,z/st z,rd. Klar. Das RAM dazu hat er. 32 Bytes. Auch ohne LDS direkt adressierbar.
chris_ schrieb: > Kleine Übungsfrage: Wie muss die Bitbreite bei diesem Prozessor > angegeben werden? Nach den Angaben sind sowohl Ram als auch Rom 18 bit breit. Was immer das soll. Georg
chris_ schrieb: >>Nein. Es gibt die Instruktionen adiw und sbiw, die 16 Bit verarbeiten. > > Also in Wahrheit sind die AVRs ja 32 Bit-CPUs: > http://hobby-roboter.de/forum/viewtopic.php?f=4&t=76 Was soll uns das jetzt sagen? Daß du nicht den Hauch einer Andeutung einer Ahnung hast? OK, geschnallt! adiw und sbiw gibt's wirklich. Vergleiche "avr instruction set reference". Was ich davon halte, habe ich ja bereits zart angedeutet...
c-hater schrieb: > Was soll uns das jetzt sagen? Daß du nicht den Hauch einer Andeutung > einer Ahnung hast? OK, geschnallt! Hoffentlich hat dein Ironiedetektor noch Garantie.
>Hoffentlich hat dein Ironiedetektor noch Garantie.
Dankeschön ;-)
Und ich habe mir tatsächlich noch überlegt, ob ich die Tags dran machen
soll.
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.