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

[David Brown]

On 15/03/11 15:25, Weddington, Eric wrote:
> > -----Original Message----- From:
> > address@hidden
> > [mailto:address@hidden
> > On Behalf Of Administrator Sent: Tuesday, March 15, 2011 12:43 AM
> > To: address@hidden Subject: Re: [avr-gcc-list] Re: an
> > idea: adding serial sram to avr to extendheap storage
> >
> > On 14.03.2011 16:11, Georg-Johann Lay wrote:
> > > I agree to 100% with Eric that this is nothing anyone wants to
> > > have in official gcc releases.
> >
> > 100% disagree. A lot of people wants to have data qualifiers like
> > __flash and __eeprom instead of intrinsic access functions and
> > wants compiler to check correctness of pointers to such data
> > typecasts. It requires address spaces support i.e. it's just the
> > partial solution of topic starter's task.
>
> You are talking about 2 separate things.
>
> The Multiple Address Spaces feature is already in GCC, and two
> targets support it. Work is being done on the AVR port right now to
> support multiple address spaces, such as __flash and __eeprom.
>
> However, there won't be support for user-defined address spaces which
> then have the compiler generate special code to access some other
> chip X. That should rightfully be in the user's code, or at the very
> least, put into a GCC plug-in. This kind of stuff is very specific to
> a user or application, and is not generic enough to warrant inclusion
> in the compiler itself.

My thought was that the user-specific code should be in the user program 
- I certainly was not suggesting that there should be code to access a 
serial SRAM within the standard gcc builds.  What I was hoping for is 
that the standard builds could contain generic extendible address 
spaces, whose actual implementation could be in user code.  The idea is 
to get some way to allow a user to implement their own "__serialsram" 
address space with only AVR code - no changes to gcc, and no gcc plugins.

I don't know if it is possible to do this with gcc multiple address 
space support as it stands today.  Even if it is possible, it may not be 
possible to do efficiently.  But if it /were/ possible, then it would 
open up a range of features for the AVR and many other gcc targets.  It 
would mean for example that implementing the __flash and __eeprom 
address spaces would become an AVR library issue rather than a gcc 
development issue.

mvh.,

David