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

[E. Weddington]

On 17 Mar 2003 at 22:50, Marek Michalkiewicz wrote:

> 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

You're right, as always. :-)

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

Yes, too.
 
> 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...

That's completely up to you. I'm certainly not ready to hack gcc. 
But, sure, that would be nice to have these built-in.

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

Agreed.

BTW,

Is there any way to do conditional compilation *within* an inline 
assembly macro? Right now an inline assembly macro has to be created 
for each variant and then it can be conditionally mapped to the final 
API symbol.

Thanks,
Eric