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

[Raymond Moore]

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.
>
> With enough LTO magic, the function calls may even have their overhead
> reduced to almost nothing.
>
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

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.

I know the xmega chips can do this, using serial ram chips as main
memory and all, but they are not as easy to use as atmega and attiny
chips tend to be.  I work with a lot of kids from 10 to 16 years old,
teaching them simple programming and microcontroller development using
AVR microcontrollers and working with surface mount chips tends to be
a problem.  We have plenty of through-hole parts and solderless
breadboards and such so we mostly stick with what we can easily and
cheaply work with.

Thank you all for your help and information,

Ray