[Top][All Lists]

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

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

From: David Brown
Subject: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
Date: Tue, 15 Mar 2011 21:47:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

On 15/03/11 15:25, Weddington, Eric wrote:

-----Original Message----- From:
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.

My thought was that the user-specific code should be in the user program - I certainly was not suggesting that there should be code to access a serial SRAM within the standard gcc builds. What I was hoping for is that the standard builds could contain generic extendible address spaces, whose actual implementation could be in user code. The idea is to get some way to allow a user to implement their own "__serialsram" address space with only AVR code - no changes to gcc, and no gcc plugins.

I don't know if it is possible to do this with gcc multiple address space support as it stands today. Even if it is possible, it may not be possible to do efficiently. But if it /were/ possible, then it would open up a range of features for the AVR and many other gcc targets. It would mean for example that implementing the __flash and __eeprom address spaces would become an AVR library issue rather than a gcc development issue.



reply via email to

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