[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] __PC__ or _PC_ ???
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] __PC__ or _PC_ ??? |
Date: |
Wed, 21 Aug 2002 21:39:03 +0200 |
User-agent: |
Mutt/1.2.5i |
As Theodore A. Roth wrote:
> I've also been thinking about this and am beginning to question wether it
> should even be documented. My experience has been that the developer
> really has no way to directly access the PC (program counter) on the AVR.
> Can someone give me a concrete example of using the _PC_ symbol which
> justifies it's existence in the docs? How does gcc/gas handle this symbol?
If you look into the compiler-generated code, it's obviously part of the
standard preamble inserted into each compiled program. It's indeed called
_PC_, and has a fixed value of 2.
Occasionally, the compiler generates jumps that jump just over a jump :)
using this special name:
.L68:
lds r24,measuring_mode
lds r25,(measuring_mode)+1
sbiw r24,0
brne _PC_+2
rjmp .L70
sbiw r24,1
breq .L77
.L69:
My guess from a first glance is that this happens in situations where the
directly reachable offset for the conditional branch instructions is
exhausted, so a larger rjmp (or even jump on the large devices) is needed.
_PC_ is then used as sort of a `location counter', although it actually
just seems to be the offset relative to the current location.
I don't understand all this. Instead, gas' location counter named `.'
should IMHO have been used. Both branches in the following code assemble
into the same instruction (just send it through the compiler, and
disassemble it using avr-objdump -d):
% cat foo.s
_PC_ = 2
.global main
main:
brne _PC_ + 2
rjmp foo
brne . + 2
rjmp bar
foo: nop
bar: nop
Maybe Denis or Marek could give us some more enlightenment...
IMHO, this symbol shouldn't be documented at all.
--
J"org Wunsch Unix support engineer
address@hidden http://www.interface-systems.de/~j/