> -----Original Message----- > From: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On > Behalf Of David Brown > Sent: Tuesday, March 15, 2011 2:47 PM > To: avr-gcc-list@nongnu.org > 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. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
