avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Puzzling behaviour of rjmp in assembler


From: Theodore A. Roth
Subject: RE: [avr-gcc-list] Puzzling behaviour of rjmp in assembler
Date: Mon, 16 Dec 2002 15:22:02 -0800 (PST)

On Tue, 17 Dec 2002, Tom Harris wrote:

:) On 6 Dec 2002 at 8:48, Tom Harris wrote:
:)
:) > Greetings,
:) >
:) > Using avr-gcc 20021111, I assembled the following:
:) >
:) >  .section .text
:) >  .func i2c_delay_T2
:) > i2c_delay_T2:
:) >  rjmp +2
:) >  rjmp +2
:) >  rjmp +2
:) >  rjmp +2
:) >  ret
:) >  .endfunc
:) >
:) > using options `-c -x assembler-with-cpp -mmcu=at90s2313`.
:) >
:) > On dumping the output with avr-objdump , the generated code has
:) > incorrect offsets. `rjmp -2' looks like an infinite loop. This code
:) > used to work with an old release of avr-gcc, I could find the verion
:) > if required.
:) >
:) > 00000000 <i2c_delay_T2>:
:) >    0:   00 c0           rjmp    .+0             ; 0x2
:) >    2:   ff cf           rjmp    .-2             ; 0x2
:) >    4:   fe cf           rjmp    .-4             ; 0x2
:) >    6:   fd cf           rjmp    .-6             ; 0x2
:) >    8:   08 95           ret
:) >
:) > Is this a bug or what?
:) >
:)
:) Unfortunately the old version of avr-gcc that assembled 'rjmp +2' as if it
:) were 'rjmp .+2' has gone from our server to the great bit bucket in the sky,
:) so its version is unknown, but I think that it was released in 2001. I can
:) confirm that it used to behave this way, as I have code in source control
:) that I had to modify to work with version 20021209. It's probably only of
:) academic interest now that an old version of avr-gcc was broken.
:)
:) Thanks for the interest.
:)
:) TomH <tomh(AT)optiscan(DOT)com>
:) avr-gcc-list at http://avr1.org
:)

See this thread for an explanation of what changed:

  http://avr1.org/pipermail/avr-gcc-list/2002-September/005187.html

Basically, Alan Modra (binutils develper) made a change to gas which
changed the behaviour of the +2 from a relative addr to an absolute
address. Unfortunately, the avr port of gcc was spitting out the "+2"
instead of the ".+2".

Gcc has since been changed to output the correct code.

Ted Roth

avr-gcc-list at http://avr1.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]