On Tue, Mar 15, 2011 at 10:34 AM, Weddington, Eric < eric.wedding...@atmel.com> wrote:
> > > > -----Original Message----- > > From: John Myers [mailto:atomicdog....@gmail.com] > > Sent: Tuesday, March 15, 2011 11:10 AM > > To: Weddington, Eric > > Cc: Administrator; avr-gcc-list@nongnu.org > > Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to > > extendheap storage > > > > > > > > > > > > Does this mean that the avr-gcc developers don't plan on adding support > > for the TR 18037 draft then? > > Huh? I said this: > > "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." > > I *was* referring to TR 18037 above. So, yes, the avr-gcc developers *are* > working on adding support for the multiple address space feature of TR > 18037. (To be pedantic, TR 18037 contains several different features, one of > which is multiple address spaces.) > > But, to go back to the OP, the multiple address spaces are still hard-coded > in the compiler (such as for flash, eeprom, ram). Adding TR 18037 multiple > address spaces does not allow the user to specify a custom address space and > what code gets generated to access it. > > > TR 18037 does support user defined address spaces. TR 18037 discusses supporting, via _Access and addressmod(), exactly what the OP wants but you said in a previous post that you would object to that.
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
