This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]