[Top][All Lists]

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

Re: AW: AW: [avr-gcc-list] Compiler error

From: Bernard Fouché
Subject: Re: AW: AW: [avr-gcc-list] Compiler error
Date: Tue, 31 May 2005 12:31:45 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Unless I've missed something, one can still face problems unless pointers are wider than 16 bits: if a program uses PSTR() to store strings in flash, fprintf_P and such will have to be forced to use pgm_read_byte_far() for all targets wider then 64K. Otherwise, when one compile the program it may work, then some more constants are added, and the upper ones can cross the 64K boundary.

At the moment pgm_read_byte() is defined as being pgm_read_byte_near() in pgmspace.h and pgm_read_byte() is used by fprintf_P()/puts_P(), etc.. Also problems may arise with constants like __fp_cosinus() since table_cos() can be split across a 64K boundary. (please correct me if I'm wrong).

A warning at link time saying that constants are bigger than 64K would help, or warnings in the pgmspace documentation.


Joerg Wunsch wrote:

"Haase Bjoern (PT-BEU/EMT) *" <address@hidden> wrote:

Which would be kinda neat in order to support the ATmega256's 24-bit
(code) address space, btw.

IIUC, Marek is trying hard to keep working with 2-Byte pointers by
introducing jump stubs in the lower 64k memory for functions
residing in > 128k memory. So there will most probably never be need
for 3-Byte pointers.

I think both ideas have some merit.  24-bit pointers are a universal
solution (like a "huge" memory model) to the problem, the jump stubs
sound like a hack at first, although I agree they might perhaps
eventually even save some code (like the jump stubs IAR is using for
16 K ROM devices).

reply via email to

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