Sehr komisches AVR Assembler Problem. Nur drei Anweisungen!

[ASM Typ (Gast)]

Hallo,

ich habe grad ein Projekt mit einem xmega E und habe einen komischen 
Fehler gesucht. Nach ewigem Runterbrechen und Wegkürzen blieb folgender 
Codeblock übrig:

2:
rjmp 1f
nop
1:
rjmp 2b

1:
rcall blink
rjmp 1b

Natürlich macht dieser Codeblock allein keinen Sinn, er ist halt 
runtergekürzt. Was erwartet man? Natürlich eine Endlosschleife. Was 
passiert? Der rjmp 2b Befehl wird einfach nicht ausgeführt. Er springt 
direkt in die nächste Anweisung. In diesem Fall fängt er an zu blinken.

Habe ich irgendwo einen Denkfehler? So schwer ist der Code nämlich 
nicht!

Ein work-around ist folgender:

2:
rjmp 1f
nop
1:
nop
rjmp 2b

[Grobi (Gast)]

ASM Typ schrieb:
> 2:
> rjmp 1f
> nop
> 1:
> rjmp 2b
>
> 1:
> rcall blink
> rjmp 1b

ähh also assembler ist jetzt schon ein wenig was her, aber du siehst 
schon das du das label "1" hier mehrfach definiert hast? Schätze mal der 
compiler / assembler wird dir das "erste" label 1 "wegoptimieren".

[avr (Gast)]

Grobi schrieb:
> Schätze mal der
> compiler / assembler wird dir das "erste" label 1 "wegoptimieren".

Nein das ist erlaubt. Mit f_orward und b_ackward wird die Sprungrichtung 
zum nächsten Label angegeben.

Was sagt denn das Disassembly?

[Grobi (Gast)]

avr schrieb:
> Nein das ist erlaubt. Mit f_orward und b_ackward wird die Sprungrichtung
> zum nächsten Label angegeben.

... hmmm also grad mal probiert avr studio 4 ein asm test project:

two:
rjmp onef
nop
one:
rjmp twob

one:
rcall blink
rjmp oneb

blink:
nop
ret

->C:\mc\TestProjectASM001\main.asm(54): error: Duplicate label: 'one'
C:\mc\TestProjectASM001\main.asm(51): info: previous definition of 'one'

und nur die Zahl 1 oder 2 -> unexpected integer!

kann doch was nicht so wirklich richtig sein

[ASM Typ (Gast)]

Disassembler:

  94:       01 c0           rjmp    .+2
  96:       00 00           nop
  98:       fd cf           rjmp    .-6

[ASM Typ (Gast)]

das mit 1b und 1f ist legitim. kann sein, dass es ein reines gnu 
assembler ding ist.

[ASM Typ (Gast)]

Ohne diese Funktion sollte folgender Code identisch sein:

start:
rjmp bla
nop
bla:
rjmp start

blubb:
rcall blink
rjmp blubb

[Theor (Gast)]

@ ASM Typ

Hm. Laut der GNU Assemblerbeschreibung sollte der Code so ablaufen, wie 
Du es im ersten Post beschrieben hast.

Du könntest Dir ja mal den Assembleroutput (also das Listing) anschauen, 
ob der GNU AS das auch wie beschreiben in nicht-lokale Labels umsetzt. 
Vielleicht ist das ja nur ein Bug in einer bestimmten Version.


P.S. Es juckt mich, noch ein persönliche Wertung dieses "Features" 
hinzuzufügen. Aber die Anführungszeichen sollen hier mal reichen. :-)

[Grobi (Gast)]

start:
rjmp bla
nop
bla:
rjmp start

blubb:
rcall blink
rjmp blubb

blink:
nop
ret

->

---- main.asm 
------------------------------------------------------------------------ 
-------------

44:       rjmp bla
+00000020:   C001        RJMP      PC+0x0002      Relative jump
45:       nop
+00000021:   0000        NOP                      No operation
@00000022: bla
47:       rjmp start
+00000022:   CFFD        RJMP      PC-0x0002      Relative jump
@00000023: blubb
50:       rcall blink
+00000023:   D001        RCALL     PC+0x0002      Relative call subroutine
51:       rjmp blubb
+00000024:   CFFE        RJMP      PC-0x0001      Relative jump
@00000025: blink
54:       nop
+00000025:   0000        NOP                      No operation
55:       ret
+00000026:   9508        RET                      Subroutine return

[fop (Gast)]

hm, was kommt vor dem ausgelassenen Jump ?
Es gibt nämlich so was wie 'skip if' in AVR Assembler. Das bewirkt, dass 
unter festgelegten Umständen der folgende Befehl nicht ausgeführt wird.
Möglicherweise steht auch direkt vor dem Jump ein halber 2-Byte-Befehl, 
so dass der Jump nicht als solcher, sondern als 2. Hälfte des 
vorhergehenden Befehls interpretiert wird.

[Axel S. (a-za-z0-9)]

Grobi schrieb:
> kann doch was nicht so wirklich richtig sein

Ja. Der Fehler ist, daß du einen anderen Assembler verwendest.

Siehe 
https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names 
unter "Local Labels"

[M. Н. (Gast)]

ASM Typ schrieb:
> Natürlich macht dieser Codeblock allein keinen Sinn, er ist halt
> runtergekürzt. Was erwartet man? Natürlich eine Endlosschleife.

Ich kann dieses Verhalten mit deinem geposteten Code nicht 
nachproduzieren. Kann allerdings auch daran liegen, dass ich die 
Label-Namen geändert habe, da ich nicht den GNU-Assembler verwende. Bei 
mir sieht der produzierte Binärcode genau so aus wie bei "Grobi (Gast)" 
und funktioniert auch.

Hast du es mal mit anderen Labels probiert?
Es gibt zwei Möglichkeiten:
1) Du hast einen Assemberlfehler entdeckt.
2) Dein Code ist anders als dargestellt.

Das dekompilierte Assembler-Listing in Kombination mit dem verwendeten 
Source-Code würde, wie bereits gesagt, helfen.

[ASM Typ (Gast)]

Ich habe es bereits mit festen Labels versucht. Der Codeblock wird 
zuverlässig immer übersprungen. Getestet habe ich es aber nur auf dem 
xmega E.

[ASM Typ (Gast)]

Ich habe auch ein neues Projekt gemacht, nur mit diesem Code. Nach dem 
Code dann ein sbi als Kontrollfunktion. Auch hier wird der Codeblock 
immer übersprungen...

[Axel S. (a-za-z0-9)]

Da ergibt alles keinen Sinn. Der gezeigte Code

2:
    rjmp 1f
    nop
1:
    rjmp 2b

ergibt - mit dem GNU Assembler für AVR assembliert - zweifellos eine 
Endlosschleife. Mit einen anderen Assembler dürfte er gar nicht 
assemblierbar sein.

So sieht es bei mir aus:

/tmp $cat test.S
        .section .text
        .org 0
2: 
        rjmp 1f
        nop
1: 
        rjmp 2b
/tmp $avr-gcc -o test.elf test.S
/tmp $avr-objdump -d test.elf 

test.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__ctors_end>:
   0:   01 c0           rjmp    .+2             ; 0x4 <__ctors_end+0x4>
   2:   00 00           nop
   4:   fd cf           rjmp    .-6             ; 0x0 <__ctors_end>

Ganz klar eine Endlosschleife. Das erste rjmp springt zu Adresse 4, das 
zweite zurück zu Adresse 0.

Also: wo kommt der gezeigte Code her? Wie hast du die Funktion getestet?