avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Myers
Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
Date: Tue, 15 Mar 2011 11:50:07 -0700



On Tue, Mar 15, 2011 at 10:34 AM, Weddington, Eric <address@hidden> wrote:


> -----Original Message-----
> From: John Myers [mailto:address@hidden]
> Sent: Tuesday, March 15, 2011 11:10 AM
> To: Weddington, Eric
> Cc: Administrator; address@hidden
> 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.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]