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

[Georg-Johann Lay]

Raymond Moore schrieb:
> On Sun, Mar 13, 2011 at 3:59 PM, David Brown <address@hidden> wrote:
>> 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.

Note that this function would have to be linked into compiler
executable. gcc has to know what to do.

I agree to 100% with Eric that this is nothing anyone wants to have in
official gcc releases.

Moreover such an support would need changing avr backend in many
places, anyway. So if the compiler just emit calls to support
functions you would see this calls on every access to memory, causing
trouble of all kinds (clobbering regs, writing reloads, etc).

>> With enough LTO magic, the function calls may even have their overhead
>> reduced to almost nothing.
>>
> 
> David,
> That is exactly the kind of thing I would like to do.
> 
> As for the other concerns, I am not really looking at pushing this
> upstream but more a project for myself that I would make available to
> the world as an optional patch.  My inquiry here was mostly an early
> question of how feasible this would be and where should I start
> looking in the code to get a start on it.  As for what project I am
> wanting to use this for, there are a number of them.  It came to mind
> as I was looking at the python on a chip project that wants lots of
> memory.

If you like to do such an extension, you will have to go through gcc's
internals, anyway.

Basically, there are two approaches: changing gcc, i.e. avr backend
directly, or writing a plug-in. I never did the latter, so I cannot
tell you if this approach is general and plugin-development is mature
enough. Plugins are supported since gcc 4.5, but you might find more
comfortable with gcc 4.6.

Johann