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: Weddington, Eric
Subject: RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
Date: Tue, 15 Mar 2011 08:25:29 -0600


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden 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.



reply via email to

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