[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: [avr-gcc-list] Re: an idea: adding serial sram to avr to extend heap storage
Date: Sun, 13 Mar 2011 21:59:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]