In den letzten Tagen beschäftige ich mich mit AVR-Mikrocontrollern. Um
genau zu sein habe ich hier einen Atmega328p. Nun sagt dessen Datenblatt
(in 8.5, I/O Memory, S.20), dass der Zugriff auf den gesamten
I/O-Adressraum mit den Load- bzw. Store-Befehlen möglich ist. Zusätzlich
kann eine Untermenge davon mit den I/O-spezifischen Befehlen IN und OUT
angesprochen werden. Die Bit-Instruktionen lasse ich jetzt mal außen
vor.
Nun frage ich mich, wenn ich doch alles auch mit 'normalen'
Load-/Store-Befehlen machen kann, warum den Befehlssatz mit 'special
case' I/O-Befehlen verschandeln? Da ich mal davon ausgehe, dass die
Atmel-Engineers schon einen Grund dafür gehabt haben, war mein erster
Tipp, dass der I/O-Zugriff mittels Load/Store bei früheren/anderen
AVR-Prozessoren vielleicht nicht möglich war und die In-/Out-Befehle
daher im Befehlssatz vorhanden sind.
In der Tat scheint das Instruction Set Manual das zu bestätigen:
> For parts with SRAM, the data space consists of the Register File, I/O> memory and internal SRAM (and external SRAM if applicable). For parts> without SRAM, the data space consists of the Register File only.
(aus der Befehlsbeschreibung für LD, S.87)
Demnach nehme ich an, dass die I/O-Befehle auf AVR-Controllern ohne SRAM
benötigt werden. Was mich jedoch verwundert, ist die Tatsache, dass
diese Befehle auch vom Compiler (avr-gcc) generiert werden. Kein
Compilerentwickler würde sich die Unterstützung der ausgiebigen Nutzung
von irgendwelchen Spezialbefehlen antun, wenn diese keinen Vorteil
brächten.
Google ist leider nicht sonderlich hilfreich. Eine zufriedenstellende
Antwort konnte ich so nicht finden, nur tonnenweise Tutorials und
nutzlose Forenbeiträge. Vielleicht kann die Frage ja einer der
AVR-erfahrenen Leute hier beantworten.
Oh, anscheinend habe ich was eigentlich offensichtliches übersehen: die
Anzahl der zur Abarbeitung nötigen Takte. Hier unterscheiden sich die
beiden Befehlsklassen (1 vs. 2 Takte). Ok, das ist ja schonmal was.
Gibts weitere Unterschiede?
working directory schrieb:> Nun frage ich mich, wenn ich doch alles auch mit 'normalen'> Load-/Store-Befehlen machen kann, warum den Befehlssatz mit 'special> case' I/O-Befehlen verschandeln?
Weil da der seperate address-lade-befehl entfällt und es somit für
assembler-programmierer einfacher ist (AVR ist primär für Assembler
gedacht)
Nein nicht ganz, AVR ist für Hochsprachen optimiert worden, doch AVR
sollte trotzdem einfach in Assembler zu programmieren sein. 8051 wurde
für Assembler optimiert.
working directory schrieb:> Gibts weitere Unterschiede?
Die Länge der Befehle: 1 Wort vs 2 Worte. Das dürfte auch der Grund für
die unterschiedliche Laufzeit sein.
Dr. Sommer schrieb:> Weil da der seperate address-lade-befehl entfällt und es somit für> assembler-programmierer einfacher ist (AVR ist primär für Assembler> gedacht)
Hmm, gibt's dafür nicht den STS-Befehl der Form 'sts Konstante,
Register'? Analog mit LDS. Aber ok, hier weist das ISM gleich daraufhin,
dass die nicht auf allen MCUs existieren. Ich seh gerade, dass es sogar
eine 16-Bit-Form von LDS/STS gibt, die eine 7-Bit-Adresse enthält und
somit wie die I/O-Befehle auch nur einen Takt benötigt.
Hi
>Weil da der seperate address-lade-befehl entfällt und es somit für>assembler-programmierer einfacher ist ...
Welcher 'seperate address-lade-befehl'?
>(AVR ist primär für Assembler gedacht)
Das sieht Atmel aber anders:
http://www.atmel.com/Images/doc1497.pdf
MfG Spess
working directory schrieb:> Ich seh gerade, dass es sogar> eine 16-Bit-Form von LDS/STS gibt, die eine 7-Bit-Adresse enthält und> somit wie die I/O-Befehle auch nur einen Takt benötigt.
Auf den Zwerg-AVRs mit erheblich reduziertem Befehls- und Registersatz
und entsprechend kleinem Adressraum. ATtiny4 oder so.
Ok STS/LDS hab ich vergessen.
spess53 schrieb:>>(AVR ist primär für Assembler gedacht)>> Das sieht Atmel aber anders:
Jaa. Deswegen hat AVR auch so tolle Offset-Adressierungen,
Barrel-Shifter, einheitlichen Adressraum (für einfache Pointer), einen
Adressraum dessen Pointer in ein Register passen, etc... Die behaupten
ja auch:
> Optimized to speed time-to-market, they [AVR] are based on the industry's> most code-efficient architecture for C and assembly programming. No other> microcontrollers deliver more computing performance with better power> efficiency.
Dr. Sommer schrieb:> Jaa. Deswegen hat AVR auch so tolle Offset-Adressierungen,> Barrel-Shifter, einheitlichen Adressraum (für einfache Pointer), einen> Adressraum dessen Pointer in ein Register passen, etc...
Nu bleibt auf dem Teppich. AVR stammt aus den 90ern. Nenn ein paar
Architekturen dieser Zeit, die deinen Wünschen entsprach, und die in der
Chipfläche vergleichbar zu AVR war. Heute zieht dieses Argument nicht
mehr so recht, aber damals waren die Chipstrukturen etwas grösser als
heute.
A. K. schrieb:> Nu bleibt auf dem Teppich. AVR stammt aus den 90ern.
Ist ja schön, aber Atmel behauptet das jetzt, und jetzt gibt es da
schon andere Kandidaten...
Dr. Sommer schrieb:> Ist ja schön, aber Atmel behauptet das jetzt, und jetzt gibt es da> schon andere Kandidaten...
Na was sollen die denn sagen? Leute kauft nicht bei uns, kauft bei der
Konkurrenz? Sowas wie "most code-efficient architecture for C" ist
natürlich Quark, aber so redet man im Marketing eben.
