Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?

[Joerg Wunsch]

As Marek Michalkiewicz wrote:

> GCC doesn't do anything with RAMPZ and doesn't use ELPM.  All data
> is assumed to be in the lower 64K of program memory, and the upper
> 64K can only be used for executable code.  Linker scripts put any
> sections with ".progmem*" names below .text, and you can have
> almost 64K (minus interrupt vectors) of this data.

Ah, OK, this makes some sense.

> One exception: there is a separate crt*.o for each device, so the
> ones for >64K devices use RAMPZ and ELPM in the loop that copies
> initialized data from Flash to RAM.

Yep, i've seen this.

> BTW, a note for printf/printf_P implementors: if we want to stay
> compatible with ICC-AVR, one person using that compiler told me
> they use %S in the format string to access a string constant in
> the program memory.  Unfortunately, this conflicts with glibc
> use of %S - "This is an alias for `%ls' which is supported for
> compatibility with the Unix standard." but I don't think we are
> going to support multibyte characters anytime soon :).

I don't think multibyte characters are around the corner, either.

Both implementations conflict with the C standard anyway.  In order
to see what the standard has to say about identifiers that start
with underscores, i stumpled across it that only lowercase letters
are allowed as implementation-defined extensions.

I guess we'll bit the bullet, and just use %S as well, but i
personally feel it's stupid that commercial compiler vendors
ship library implementations that violate the standard when there's
no actual need to (chosing a lowercase letter would have been easy).

> There may be special applications with a lot (>64K) of constants
> in Flash, and small code.  It makes sense to organize the data in
> smaller pieces (each <64K), addressed with 16-bit offsets from the
> (17-bit) base address of the object.  There was some discussion
> about this a few months ago, here is an example (not tested, and
> only for the enhanced core - mega128 replaces mega103 anyway):

But wouldn't this also constitute a case where another avr6
architecture definition made some sense?  At least, that's the
only way i could see how library code could ever determine whether
RAMPZ/ELPM is needed or not.  (Library code doesn't have the detailed
__AVR_ATmegaXXX__ macros available when compiling.)

Thanks for the reply!
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/