Re: [avr-libc-dev] [Bug #2839] PRG_RDB not in documentation

[Marek Michalkiewicz]

On Mon, Mar 17, 2003 at 11:50:37AM -0700, E. Weddington wrote:
> IMO, through conditionals, there should just be 1 function / symbol 
> that will read a byte from anywhere in the flash. Right now in 
> pgmspace.h, there's __LPM and __ELPM but PRG_RDB is not switched to 
> point to __ELPM so PRG_RDB won't be completely valid for mega128. 

But, there should also be another function / symbol that uses only
16 bits of the address, even for mega128.  Using RAMPZ and ELPM is
inefficient, and not necessary in most typical cases (the linker
scripts are set up so that "progmem" data is placed at the low
addresses, still leaving the upper 64K for executable code).

So, I think there should really be two symbols:
 - using a short (16-bit) pointer, always LPM (even on mega128),
   like the current PRG_RDB
 - using a long pointer, using RAMPZ and ELPM if available,
   otherwise using LPM and ignoring the high address bits

While we are at it, reading 16-bit constants from program memory is
done quite often, so it would be nice to have macros for this too
(they can be optimized with post-increment on the enhanced core).

Idea for GCC 3.4, if time permits (almost impossible, but...) -
GCC could have built-in functions for program memory reads, and
handle them as UNSPEC at the RTL level.  Perhaps this would allow
making better use of post-increment - I have to look into it...

> I would also like this cleaned up because it affects the bootloader 
> support API (boot.h) that I have to submit. Right now I repeat the 
> read byte functionality in my boot.h.

Boot loader for mega128 is special - always in the upper 64K, so you
have to use ELPM all the time, and you have to use -mno-tablejump so
that GCC itself will not use LPM in large "switch" statements.

But, using these long pointers (RAMPZ:Z) on anything less than m128
can make the boot loader significantly larger, so it is a good idea
to still provide the 64K-limited API for smaller devices.

> And well.... I suppose it's time.... I'll volunteer to rewrite and 
> submit some new pgmspace.h stuff. And now I'll officially ask if I 
> can be listed as developer and have CVS write access to avr-libc.

No problem as far as I am concerned - your work is much appreciated.

Marek