With respect to MCUs with Harvard architecture (separate address spaces for code and data), Clang wins over GCC (
gcc and
g++).
On AVRs, using Clang (either C or C++),
int get(__attribute__((address_space (1))) const int *p) { return *p; }reads a byte from the Flash using
LPM instruction. Both also allow you to define types that specifically use an address space, i.e.
typedef unsigned char uchar_flash __attribute_((address_space (1))); unsigned char get(const uchar_flash *p) { return *p; }The same is wired on x86-64 for using FS and GS segments (address spaces 257 and 256, respectively).
GCC does have the attribute, but it doesn't seem to be wired to anything.
g++ (C++) does not support address spaces.
gcc (C) does support address spaces, but via custom qualifiers:
__flash on AVR,
__seg_fs on x86-64, and so on.
Paul Iannetta did very recently
post a patch to
g++ that would fix this –– simply wiring the existing support together ––, but I haven't tested the patch to check if that suffices for AVR or if a tiny additional patch is needed to register the keywords on the AVR arches; but, I do believe it allows the
__flash qualifier to work on
g++ also. Which would be a HUGE improvement, actually. (A simple preprocessor macro could then declare a C and C++ PROGMEM macro that would work on clang, clang++, gcc, and g++. Thus far, only clang, clang++, and gcc can support one.)
Yet, because it's GCC, I give it about 3% chance of actually being accepted upstream within the next five years. After all, the issue was only raised in
2016, which is "yesterday" in GCC terms. Give it a decade or two, after it has been hashed out in academia first.
Full disclosure: I'd test the patch, but I'm on a laptop whose fan gets awfully loud when compiling GCC. If anyone is up to it, and willing to check, I'd recommend doing so and reporting success to both GCC mailing list as well as the
GCC bug 69549 (referring to the patch on the GCC mailing list).