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

[Bernard Fouché]

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.

   Bernard

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).
>
>