Dazu habe ich gestern den "AvrAssembler2" von Atmel, aus dem Atmeld Studio 5 extrahiert. "Meinen Code" kann ich nun fast übersetzen, aber bei folgenden Befehlen gibt Errors, ...
1
adiw Y, 0x2
2
sbiw Y, 0x03
3
4
z.B.
5
adiw Y,0x01
6
error: syntax error, unexpected MINUSMINUS
Die obigen Befehle sind wohl 16Bit Addierbefehle für ein Registerpaar.
Da ich ein verwöhnter arduino Benutzer bin hab ich halt von avr Assembler keine Ahnung.
; adiw Y, 0x2 ; diese Syntax kennt der Assembler nicht
3
adiw YH:YL,0x02 ; so geht es
Sehr erfreulich ist, der assembler erzeugt tatsächlich ein identisches Hex-File, so wie es damals vor 10 Jahren vom Entwickler des Projektes erzeugt wurde. D.h. auf der Basis kann ich weiter arbeiten.
Achja, jetzt wo du es schreibst: das war eine der Eigenarten, die Atmel diesem Assembler beigebracht hat. Obwohl zwar sonst überall Y als Pseudonym für das Registerpaar r28/r29 benutzt wird, musste man es im Assembler als YH:YL notieren.
Nicht erst l dann h?
ist das egal?
Bei mir steht da zum Beispiel:
adiprint:
lpm ; erstes Byte des Strings nach R0 lesen
tst R0 ; R0 auf 0 testen
breq print_end ; wenn 0, dann zu print_end
mov temp, r0 ; Inhalt von R0 nach temp kopieren
rcall ausgabe
adiw ZL:ZH, 1 ; Adresse des Z-Pointers um 1 erhoehen
rjmp print ; zum Anfang springen, um naechstes
; ; Byte aus dem cseg-Label text1;zu holen
In Asselbler aus AVR Studio 4.19 reicht es, untere geradzahlige Register anzugeben.
So sind Varianten wie diese gleich:
adiw r27:r26,1 oder adiw r26,1
genauso auch movw r31:r30,r1:r0 und movw r30,r0
Danke für Euere Reaktion.
Wie gesagt, es wird identischer Code erzeugt, wie vom Entwickler damals, 2013, mit einem mir nicht bekannten Assembler. Das hätte ich nicht gedacht.
Ich wollte einfach mal naiv das alte Hex-File mit dem neu generierten vergleichen, vollständig binär kompatibel.
Achja, jetzt wo du es schreibst: das war eine der Eigenarten, die Atmel
diesem Assembler beigebracht hat. Obwohl zwar sonst überall Y als
Pseudonym für das Registerpaar r28/r29 benutzt wird, musste man es im
Assembler als YH:YL notieren.
Unsinn. Ganz sicher nicht der AvrAssembler2. Der schluckt adiw Y,<const> völlig problemlos. Es sei denn, man war so wahnsinnig, irgendwelche exotischen Optionen zu aktivieren, wie z.B. das von S.Landolt erwähnte -c.
Und die Ursache dafür ist nicht etwa der Assembler selber, sondern die Include-Files. Die deklarieren nämlich erst die Aliase für die Indexregister und sie tun das nur in einer "caseness". Und nicht einmal alle in derselben, so weit ich mich erinnere...
Stellt sich die Frage, wofür es so eine Option dann überhaupt gibt.
Ja, das habe ich mich auch schon oft gefragt. Irgendeinen Sinn würde die nur ergeben, wenn es dann zur Assemble-Zeit auch ein auswertbares Symbol geben würde, über welches der Preprozessor-Code ermitteln kann, dass halt caseness jetzt wichtig ist oder nicht. Gibt es aber entweder nicht oder der Include-Generator kann damit nicht umgehen. Die includes jedenfalls scheissen einen großen Berg darauf und deklarieren halt die Aliase einfach nur in irgendeinem case und, wie schon gesagt: nach meiner Erinnerung nicht mal alle im gleichen.
... includes ... nach meiner Erinnerung nicht mal alle im gleichen
'Memory is treacherous'!
Ja, mag sein, dass ich mich da täusche.
Naja, die älteste Include-Sammlung in meinem Backup-Bestand ist das Studio 4.18. Wenn ich am WE Langeweile habe, werde ich das mal diesbezüglich durchforsten. Ich bin mir nämlich fast sicher, dass ich mich eben nicht täusche. Mag aber sein, dass der Ursprung dieser Erinnerung noch länger her ist als Studio4.18. Das ist ja praktisch noch aktuell. ;o)
Nun ja, ich bin so ein Wahnsinniger, arbeite seit jeher mit '-c' mit einer Vielzahl von AVR8-Typen und hatte nie Probleme mit den include-Dateien.
Nur bei der Atmel-Dokumentation geht es regelmäßig durcheinander, siehe u.a. das 'Instruction Set Manual'.
Was nun aber den "Wahnsinn" betrifft: den schreiben nicht wenige C-Anhänger den Assemblerprogrammierern zu - insofern wären wir schon zu zweit.
die älteste Include-Sammlung in meinem Backup-Bestand ist das
Studio 4.18.
Studio 4.18 hat Problem: Abbruch, wenn genug Files im Projekt. Ich kann jetzt nicht erinnern, ab wieviel Files das passiert, aber bestimmt bei 30 oder 40 schon. Nur Studio 4.19 ist frei davon. Letzte aus 4-Reihe und beste überhaupt Variante aus alles "Studio"
Naja, die älteste Include-Sammlung in meinem Backup-Bestand ist das
Studio 4.18. Wenn ich am WE Langeweile habe, werde ich das mal
diesbezüglich durchforsten.
Also zumindest bei Studio4.18 sind tatsächlich alle Indexregister einheitlich uppercase deklariert.
Falls ich also mit meiner Erinnerung richtig lag, muss sie aus noch älteren Versionen der Includes stammen. Kann ich mangels Datenmaterial leider nicht mehr überprüfen.
