This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: AVR 16-bit I/O access order fix, PR target/20288
- From: Björn Haase <bjoern dot m dot haase at web dot de>
- To: schlie at comcast dot net
- Cc: marekm at amelek dot gda dot pl,gcc-patches at gcc dot gnu dot org
- Date: Mon, 7 Mar 2005 21:56:13 +0100
- Subject: Re: AVR 16-bit I/O access order fix, PR target/20288
Hi,
one brief remark concerning the issue of support for multiple memory spaces in
gcc. In my opinion it is a principal weakness of the c-language that it
assumes a single unified memory space and IMHO it will never be possible to
overcome this difficulty without using extensions to the language.
What I personally have done in order to solve this issue for me is: I switched
to c++ for my projects. While still writing essentially c programs and
refraining from using, e.g. new and delete, I am using c++ for the single
purpose to have access to the extended type system. This makes it possible to
define classes like "pointer to program memory", array in program memory or
"variable in eeprom". WIthin the class definitions, I make use of inline
assembly expressions that handle the operations. E.g. for the class
uint8_t_eeprom one could overload the "=" operator so that it writes the
right hand side into the eeprom or one could define a conversion routine to
uint8_t that essentially implements a eeprom read access. The only thing to
keep care of then is to make shure that the linker places objects of class
uint8_t_eeprom in the .eeprom section (by using appropriate attributes when
defining the object). Code is fairly efficient. Similar solutions work for
program memory.
Yours,
Björn