... opc: RJMP Getchar High: .byte hi8 (opc) ... Das Assemblerprogramm soll das Highbyte des Labels "opc" mittels der .byte Anweisung hinter dem Label High ablegen. Der GCC-Assembler für den AVR gibt die folgenden Fehlermeldung (Zeile mit dem .byte) aus: Error: illegal relocation size: 1 Alternativ habe ich - ohne Erfolg - statt hi8(...) pm_hi8(...) verwendet. Wo liegt der Fehler?
:
Verschoben durch User
... .word und ein unnötiges Byte ertragen? ... Danke für deine Antwort, leider funktioniert der Kniff nicht.
Bei mir geht's und das Disassembly zeit die korrekte Adresse, sowohl bei Symbol als auch bei 0b etc). Dein Problem liegt also woanners.
1 | .text |
2 | |
3 | foo: |
4 | |
5 | .word foo |
6 | .word pm(foo) |
1 | avr-gcc -mmcu=... -c -x assembler-with-cpp foo.S -o foo.o |
Wenn ich .word foo .word pm(foo) assembliere bekomme ich die 4 Bytes 00 14 00 0A assembliere ich .word foo .word foo erhalte ich 00 14 00 14 ??? Was ich möchte ist: die Highbytes von Labels hintereinander Byte für Byte ablegen.
Nicht jeder Reloc ist überall erlaubt. pm teilt die Adresse durch 2. Die einzig sinnvolle Art, ein Label so zu speichern, ist ihn irgendwann als Zeiger für einen indirekten Sprung/Call zu verwenden. Weil AVR nur halbe Adressen verwendet (Code ist immer 2-Aligned), können 128kb bzw. 64kw mit einer 16-Bit Adresse erreicht werden. Die Division durch 2 macht pm() Wenn du nur das Highbyte brauchst deutet das auf ein problematisches Design hin. Was soll's denn werden?
Hallo Johann, mit dem AVR-Assembler von Atmel funktioniert es ( .DB high(label) ). Vielen Dank für deine Hinweise & Hilfe :) Martin
Martin schrieb: > mit dem AVR-Assembler von Atmel funktioniert es Das ist auch ein ziemlich primitives Teil, und insbesondere ist es kein verschieblicher Assembler, sondern ein Absolutassembler. Damit weiß er natürlich, auf welche Adresse er konkret gerade assembliert, während der GNU-Assembler alles erst einmal in Verschiebeanweisungen für den Linker umwandeln muss, der es dann später auf die eigentlichen Adressen bringt (die sogenannten relocation entries).
Es gibt zwei Arten von Assembler, die, die funktionieren und die, die nicht funktionieren. Der ATMEL-Assembler funktioniert.
Martin schrieb: > Es gibt zwei Arten von Assembler, die, die funktionieren und die, die > nicht funktionieren. Der ATMEL-Assembler funktioniert. Na, zu behaupten der GNU-Assembler funktioniere nicht... Ich schätze, wesentlich mehr Leute setzen den avr-as ein als den Atmel-Assembler, nämlich zumindest die, die AVR mir avr-gcc oder avr-g++ programmieren (und damit bei jedem Mal implitit auch den avr-as aufrufen lassen). Wie gesagt, was du da machen willst ich recht exotisch. Ich wüsste keine Anwendung, bei der man nur das High-Byte einer Adresse als Eintrag in einer Tabelle braucht.
Martin schrieb: > Der ATMEL-Assembler funktioniert. Für deine Definition von "funktioniert". Mach mal ein Projekt, was mehr als eine Quelldatei braucht... Oder einfacher: linke deinen Assemblercode mal gegen eine der Objektbibliotheken von Atmel, QTouch zum Beispiel. Spätestens dann wirst du wissen, warum ein Absolutassembler bereits 1980 als altmodisch galt.
Johann L. schrieb: > Wie gesagt, was du da machen willst ich recht exotisch. Ich wüsste keine > Anwendung, bei der man nur das High-Byte einer Adresse als Eintrag in > einer Tabelle braucht. Nicht nur du. Offenbar haben die Entwickler der AVR-ELF-Variante, von denen ich bis zum Beweis des Gegenteils erstmal ausgehe, dass es keine Vollidioten waren, ebenfalls keine Anwendung dafür gesehen, so dass es schlicht und einfach keinen dafür passenden Relokationstyp gibt. Andreas
Junge, Junge - welch eine Empfindlichkeit. Bindet eure Schlipse kürzer, damit ich nicht drauf treten kann. Selbstverständliche meine ich "funktioniert" im Kontext meiner Anwendung.
Bitte 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.