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

[Omar Choudary]

Sorry if this has been discussed already (way too many e-mails to keep
up in a short day), but see this:
http://www.nongnu.org/avr-libc/user-manual/malloc.html

It should be trivial to use the heap in external RAM. I haven't
personally tested this but the avr-libc seems to support it fully.

Omar

On Mon, Mar 14, 2011 at 2:11 PM, Georg-Johann Lay <address@hidden> wrote:
> 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
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>