RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheapstorage

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of David Brown
> Sent: Tuesday, March 15, 2011 2:47 PM
> To: address@hidden
> Subject: [avr-gcc-list] Re: an idea: adding serial sram to avr to
> extendheapstorage
> 
> 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.  

That's my concern too. It's a whole other kettle of fish.

> 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.

Well, I certainly don't mind that __flash and __eeprom would turn into compiler 
issues. That's been desired since at least 2001/2002, if not earlier.

I agree, user-defined address spaces would be a cool feature as you describe 
it. But unless there's a volunteer to help with that, it's going to be yet 
another cool feature that will have to wait until we get the other cool 
features on the list done.