Re: [avr-gcc-list] RFC gcc multiple memory space implementation

[David Brown]

>
> One of the major issue concerning implementing this into gcc is the fact
> that gcc has no current mechanisms for setting attributes that are a
> part of the type. GCC has attributes for functions and for data
> storeages, but not for types.
>

Introducing this would require changes to the gcc core, so maybe it is worth
thinking about what other advantages and disadvantages this could bring,
both to the avr port and to other targets.  Could the same sort of idea be
used to implement more flexible volatiles (such as for registers that can be
freely read, but have controlled writes), or the sort of memory access
control available in Java (as far as I have read - I've never tried it
myself) allowing data to be specified as non-cached, or shared between
threads, or whatever?  My guess is it will be easier to get support from
core gcc developers if it has as wide an appeal as possible.

Are strings going to be automatically put in the program memory address
space?  That would normally make the most sense, but it would break direct
usage of strings in something like printf - programmers would have to write
printf_P("Error !") to get the types correct.  Of course, good embedded
programming practice makes very little use of such constructs directly
(preferring more specific formating functions, or at least printnf functions
and safer code like printf_P("%S", "Error !") ).  Printf would also need a
format type for program memory strings - ImageCraft's compiler uses "%S".

David