RE: [avr-libc-dev] New pgm_read_ptr() macro?

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Thursday, June 03, 2010 1:04 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] New pgm_read_ptr() macro?
> 
> On 03/06/2010 10:09, Weddington, Eric wrote:
> > Hi Jan,
> >
> > Be sure to keep posts on-list.
> >
> > I would be ok with adding this and adding Dean's new macro too.
> > Removing functionality from avr-libc gets into
> > backwards-compatibility issues.
> >
> > However, I want to make sure that this has been tested out, and that
> > documentation is included. In both patches.
> >
> 
> I've used it myself in applications, but it would be good for 
> others to 
> test it.  In particular, it should be tested with different levels of 
> optimisation (in case the __builtin functions don't disappear 
> properly), 
> and it should be tested with different language flags (in case type 
> __builtin functions or typeof conflict with pendantic flags).
> 
> There is also, as you say, some documentation needed.  The 
> limitation of 
> the macro is that it only works for sizes 1, 2 or 4.  If you 
> try to use 
> it with a different size, you get a compile-time error, which 
> is nice. 
> Unfortunately, the error message is a bit obscure, and needs 
> documentation.  If anyone has a better way to produce an 
> error message 
> with risk of generating code, I'd love to know!
> 
> As another point, should we improve the consistency between 
> eeprom.h and 
> pgmspace.h by adding a "pgm_read_block" function/macro?  This 
> could, I 
> think, be as simple as:
> 
> #define pgm_read_block(dst, src, n) (void) memcpy_P(dst, src, n)
> 
> Or it could be optimised as inline assembly.
> 
> Should the pgm_read macro then call this for other sizes, or 
> should it 
> give a compile-time error?
> 
> And if a general pgm_read macro is a good idea, should we 
> also have an 
> eeprom_read macro and an eeprom_write macro?

I think that these area all great ideas, and yes, should be done. I would also 
like very much to finally add the FAR macros that Carlos put together a long 
time ago, or something very similar. I don't remember if there was ever any 
issues with them that need to get resolved, or if there is basic agreement that 
these should be added the way they are etc. But I would like to put the issue 
to rest and get them added in some fashion. And, of course, any help on this 
would be very much appreciated.

Eric