avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a


From: Marek Michalkiewicz
Subject: Re: [avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a
Date: Sat, 12 Apr 2003 18:31:09 +0200
User-agent: Mutt/1.4i

On Fri, Apr 11, 2003 at 01:38:16PM +0200, Joerg Wunsch wrote:
> But that prevents people from using > 64 KB of constant ?progmem?
> data.  I think an option to allow for this would be nice (like
> -mlarge-model or something like that), in case someone really needs
> huge tables in flash ROM, with only little code.  Of course, it should
> be off by default.

It's not easy.  Just to show how ugly it can get, here is a macro
necessary to take the address of a progmem object possibly above 64K:

/* PTR is a variable of type "unsigned long" where a long pointer
   to the progmem object named by X will be stored.  */
#define GET_LONG_ADDR(ptr, x)                   \
        asm (                                   \
                "ldi %A0,lo8(" #x ")" "\n\t"    \
                "ldi %B0,hi8(" #x ")" "\n\t"    \
                "ldi %C0,hh8(" #x ")" "\n\t"    \
                "clr %D0"                       \
                : "=d" (ptr)                    \
        );

Simple "unsigned long ptr = (unsigned long) &x;" will only get the
low 16 bits (and _sign_-extend the pointer to 32 bits, even though
the pointer is cast to _unsigned_ long - very strange...).

IMHO, how to access progmem data above 64K in the most efficient way
is very dependent on the application.  If an API for this will be
added to avr-libc, I think it probably should be separate from the
current (simple and efficient, but limited to 64K) API.

Another potential problem appears when RAMPZ is used both in the main
program and in interrupts - interrupt handlers should then save RAMPZ
just like any other registers.

> At least, it's documented in the datasheet.

OK.  I just hope the 8K wrap-around still works...  Currently, there
is one AVR_ISA_MEGA flag for both "jmp/call supported" and "no 8K
wrap-around" which may have to be separated.  For now, the assembler
has the -mall-opcodes option to allow all opcodes on any device.

> Are you going to commit that, and close the bug report?

Done.

Marek





reply via email to

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