[Top][All Lists]

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

RE: [avr-gcc-list] Position Independent Code / Data (PIC /PID)

From: Weddington, Eric
Subject: RE: [avr-gcc-list] Position Independent Code / Data (PIC /PID)
Date: Thu, 22 May 2008 08:10:29 -0600


> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Moritz Struebe
> Sent: Wednesday, May 21, 2008 1:54 AM
> To: avr-gcc-list
> Subject: [avr-gcc-list] Position Independent Code / Data (PIC /PID)
> I already posted this to avr-libc, but I didn't get an answer 
> jet and it 
> probably was the wrong group.

Hi Morty,

I'm sure others saw your message there too (I did). But no responded yet
either because they are busy or because they don't have a good answer
for you.

> Hi there,
> I developed module support for Nut/OS running on a ATmega128. At the
> moment I allocate memory and then link against this information. Using
> PIC would save me this trouble.

> I did some research on PIC/PID & AVR, but mostly found 
> guesswork and/or
> even false information. (Or people complaining that someone 
> posted in an
> AVR and not in the Microchip-Forum. ;-) )

That's common. :-) It's pretty rare that someone talks about Position
Independent Code in regards to the AVR.

> Dunkels et al. say that PIC is limited to 4K [1]. I'm not 
> sure why this
> is the case. Looking at the documentation I come up with 
> +-2^16 words =
> 64K.
> I'm also not sure how to interpret the -mshort-calls option. Does this
> mean I get only rjmps and the linker will complain if the 
> jumps get too
> long, or will the Linker silently fail.

Looking in the avr-libc manual, -mshort-calls is described as:
"Use rjmp/rcall (limited range) on >8K devices. On avr2 and avr4
architectures (less than 8 KB or flash memory), this is always the case.
On avr3 and avr5 architectures, calls and jumps to targets outside the
current function will by default use jmp/call instructions that can
cover the entire address range, but that require more flash ROM and
execution time."

Honestly, I don't know if the linker will complain if the jumps are too
long, as not many people use -mshort-calls.

> Further on I curious whether it would be (theoretically) 
> possible to let
> the linker decide whether to use jmp or rjmp or even do 
> double rjmps to
> cover the full range. I know, the latter is a bit strange, but would
> enable code > 64K to be position independent.

The linker now has "linker relaxation" available. This means that you do
not have to use -mshort-calls (and it is recommended that you don't).
When you call linker relaxation it will optimize the jmp/call to
rjmp/rcall as needed.

Remember that functions are word-aligned, so jmp/call can reach 64K
*words* (128K bytes). Look how GCC is implemented for the ATmega256x

> I was wondering whether PID is supported because it came up in one or
> two threads. But I assume not.

AFAIK, no one has gotten it working.

If you do get it working, please let us know.

Eric Weddington

reply via email to

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