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 10:09:36 -0700



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


> -----Original Message-----
> From: avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.org
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.org] 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.

_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Does this mean that the avr-gcc developers don't plan on adding support for the TR 18037 draft then?

reply via email to

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