[avr-gcc-list] Re: an idea: adding serial sram to avr to extend heap storage

[David Brown]

On 13/03/11 19:01, John Myers wrote:
> Hi Ray,
>
> It sounds like what you want is to create another address space.
> There is the TR 18037 draft called "Programming Languages - C -
> Extensions to support embedded processors".  GCC has some support for
> it: http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html

What would be very neat is if there were some way to have named address 
spaces defined by the compiler user, rather than the compiler writer. 
The compiler writer would have to define a few "hookable" extended 
address spaces, with generic names - something like ADDR_SPACE_1 which 
called functions like

void ADDR_SPACE_1_WRITE(ADDR_SPACE_1 void * dest, const void * src, 
size_t n);

void ADDR_SPACE_1_READ(void * dest, const ADDR_SPACE_1 void * src, 
size_t n);

You could define a few address spaces like this.

It is likely that the size of the pointers would have to be defined at 
gcc compile time, rather than use time - thus you'd pre-define 
"hookable" address spaces ADDR_SPACE_16_1, ADDR_SPACE_16_2, 
ADDR_SPACE_32_1, ADDR_SPACE_32_2, etc.


To use these, the user would use something like "#define exSRAM 
ADDR_SPACE_16_1" and define the appropriate read and write functions.  A 
bit of linker file options could then let you define data directly in 
these address spaces (though initialising the data properly would be 
more complicated).  Any access to the data would result in calling the 
appropriate functions.

With enough LTO magic, the function calls may even have their overhead 
reduced to almost nothing.