avr-g++ lacks __flash?

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it a known problem that avr-g++ doesn't seem to support the __flash keyword ?

 

BillW-MacOSX-2<10166> /usr/local/CrossPack-AVR-48/bin/avr-g++ -mmcu=atmega328p flash.c
flash.c:3:7: error: '__flash' does not name a type
 const __flash int x = 12;
       ^
flash.c: In function 'int main()':
flash.c:6:13: error: 'x' was not declared in this scope
     PORTB = x;
             ^

 
BillW-MacOSX-2<10167> /usr/local/CrossPack-AVR-48/bin/avr-gcc -mmcu=atmega328p flash.c

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not a *problem*, it's the limitation of the *language* (C++) - or, more precisely, the lack of a specification of named address spaces for C++.

 

Quote from https://gcc.gnu.org/onlinedocs/g...

"As an extension, GNU C supports named address spaces as defined in the N1275 draft of ISO/IEC DTR 18037. "

 

https://gcc.gnu.org/ml/gcc-patch...

 

JW

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, ok.  I was assuming that C++ was still supposed to be a superset of C.  The deviation is a bit disconcerting.

I guess I can sorta see how it might be incompatible with C++; do you have a pointer to an explanation of the C extension that makes it clearer what this means from the compiler designer perspective?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB (Georg-Johan Lay) who implemented __flash in avr-gcc for us has said that the ruling committee for C++ have their head too far up their arse (my words not his!) to ever consider adding anything to the core language that might support Harvard address spaces. So it's a pretty fair bet avr-g++ is NEVER going to get __flash and will always have to use the pgm_read_*() kludge from AVR-LibC.

 

BTW most GCC installations have a ..\doc directory and within that there should be a "gccint" document that documents the internal working of GCC for compiler developers. It is a VERY "heavy" read!

 

(but as I say, forget it, even though you might ultimately be able to patch up a g++ to do __flash basing the work in SprinterSB's gcc work it's never going to get accepted as a patch to the main line anyway).