On Tue, Mar 15, 2011 at 7:25 AM, Weddington, Eric <eric.wedding...@atmel.com > wrote:
> > > > -----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 Administrator > > Sent: Tuesday, March 15, 2011 12:43 AM > > To: avr-gcc-list@nongnu.org > > 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 > AVR-GCC-list@nongnu.org > 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?
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
