This should at least be optional and not default. Too bad the compiler cannot do this (use `puts_p() if used on a constant string literal)) automatically...

I was thinking about using PROGMEM as well. Note that PROGMEM is a macro defined by the AVR libc, which is defined as __attribute__((__progmem__)). Maybe it makes sense to use our own define instead, to have the possibility to use the same API in case other harvard architectures. E.g. the ESP8266 seems to also be a hardward architectured modified to be able to access program memory.

However, I'm not sure if overwriting (parts of) stdio is the best approach, as unprepared code will break by this change. What we could do instead is to provide special functions and qualifiers for working with flash memory. E.g. we could create our own define for PROGMEM that would just be defined as const on von-Neumann and as const __attribute__((__progmem__)) on AVR. And then we could provide puts_progmem() as well, which would be a static inline wrapper for puts() on von-Neumann and for puts_P() for AVR. That way code could be explicitly prepared to work with this without any disadvantages (except for additional clutter to the source code) for von-Neumann machines. And unprepared code that just keeps using const char *foo and regular puts() will not break.

One point that I was specifically looking at is the stringification in SAUL of both sensors/actuators and units. Those seem to be the largest chunk of data allocated constants on AVR and getting them to flash would allow examples/default to run again on the Arduino Uno. Given the popularity of that board, I really would like our default example to again work there. People having an Arduino Uno and trying to run examples/default on it will get a bad first impression of RIOT right now and I really would love to change this.

One point that I was specifically looking at is the stringification in SAUL of both sensors/actuators and units. Those seem to be the largest chunk of data allocated constants on AVR and getting them to flash would allow examples/default to run again on the Arduino Uno. Given the popularity of that board, I really would like our default example to again work there. People having an Arduino Uno and trying to run examples/default on it will get a bad first impression of RIOT right now and I really would love to change this.

Yes probably all the shell commands function could use this.

What we could do instead is to provide special functions and qualifiers for working with flash memory. E.g. we could create our own define for PROGMEM that would just be defined as const on von-Neumann and as const attribute((progmem)) on AVR.

Yes this would be better than refining puts, which would hide the actual behavior of the function. But how do you see this working with uses like puts("foo")? I guess having two versions of puts_pgmsapce where one is just puts_P(_s) and the other puts_P(PSTR(_s)) would work but at the price of some clutter. Maybe we don't mind this?

What I do not understand: If Cortex-M3 is also a Harvard machine, why can it be handled transparency by the compiler there?
Is this a shortcoming of avr-gcc or or is there something inherently different with the AVR architecture that makes this necessary?

Is this a shortcoming of avr-gcc or or is there something inherently different with the AVR architecture that makes this necessary?

The difference between the Harvard and the von-Neumann architecture in the "original" sense is that Harvard has two distinct address spaces for program and data, and von-Neumann only has one for both.

Many modern Harvard architectures however map program space also into the data address space. (Even the ATtiny of the AVR family do so.) If that is the case, you can safely access ROM data in the very same way as RAM data (except it is read-only).

In the classic Harvard machine, it is completely impossible to read data from program memory - you can only run it. The ATmega family is already an improvement upon this, as it has two load instructions - one working with data addresses, one with program addresses. However, the compiler must now which instruction it has to emit at compile time. And as data and program address can have the same value range, you couldn't even provide a generic helper like:

void memcpy_program_or_data(void *dest, void *src, size_t len)
    if (is_program_memory(src)) {
        memcpy_from_program_memory(dest, src, len);
    }
    else {
        memcpy(dest, src, len);
    }
}

So, yes: It is a limitation of the AVR (or specifically, the ATmega family - it would work fine for ATtinys).