AVR __progmem__ variable reading

AVR __progmem__ variable reading

[Łukasz Kostka]

Hi

I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions etc.) in order to properly interpret variable is accessed (eg. by array subscription).

This would remove need for any assembly code written to do this.
Make user code much cleaner.
GCC having all this knowledge can optimize end assembly code.
Simple attribute addition will switch from array in memory to array in flash.
Can serve as future implementations for other platforms.

What do you think ?

Re: AVR __progmem__ variable reading

[David Brown]

On 22/02/2019 23:34, Łukasz Kostka wrote:
> Hi
> 
> I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions etc.) in order to properly interpret variable is accessed (eg. by array subscription).
> 
> This would remove need for any assembly code written to do this.
> Make user code much cleaner.
> GCC having all this knowledge can optimize end assembly code.
> Simple attribute addition will switch from array in memory to array in flash.
> Can serve as future implementations for other platforms.
> 
> What do you think ?
> 
> 

You don't need to write assembly to read flash data with AVR gcc - you 
have never needed it.  To use the "progmem" attribute, include the 
<avr/pgmspace.h> header and use the macros and functions from there, 
such as "pgm_read_byte".

<https://www.nongnu.org/avr-libc/user-manual/pgmspace_8h.html>


Newer versions of AVR gcc have named address spaces, making the process 
simpler.  I must admit I haven't written any AVR code since these were 
added to the compiler, but I assume they work fine:

<https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#Named-Address-Spaces>

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 23.02.2019, o godz. 16:34:
> 
> On 22/02/2019 23:34, Łukasz Kostka wrote:
>> Hi
>> I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions etc.) in order to properly interpret variable is accessed (eg. by array subscription).
>> This would remove need for any assembly code written to do this.
>> Make user code much cleaner.
>> GCC having all this knowledge can optimize end assembly code.
>> Simple attribute addition will switch from array in memory to array in flash.
>> Can serve as future implementations for other platforms.
>> What do you think ?
> 
> You don't need to write assembly to read flash data with AVR gcc - you have never needed it.  To use the "progmem" attribute, include the <avr/pgmspace.h> header and use the macros and functions from there, such as "pgm_read_byte".
> 
> <https://www.nongnu.org/avr-libc/user-manual/pgmspace_8h.html>
That is my point. I still need to use "ppm_read_byte" 
> 
> 
> Newer versions of AVR gcc have named address spaces, making the process simpler.  I must admit I haven't written any AVR code since these were added to the compiler, but I assume they work fine:
> 
> <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#Named-Address-Spaces>
> 
Thx. I didn’t read this before. This works only for C. I use C++ and there are no named address spaces extensions :-(

My end goal is to use all variables in exactly same way as in regular code without <arv/pgmspace.h>

Re: AVR __progmem__ variable reading

[David Brown]

On 23/02/2019 19:38, Łukasz Kostka wrote:
> 
> 
>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 23.02.2019, o godz. 16:34:
>>
>> On 22/02/2019 23:34, Łukasz Kostka wrote:
>>> Hi
>>> I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions etc.) in order to properly interpret variable is accessed (eg. by array subscription).
>>> This would remove need for any assembly code written to do this.
>>> Make user code much cleaner.
>>> GCC having all this knowledge can optimize end assembly code.
>>> Simple attribute addition will switch from array in memory to array in flash.
>>> Can serve as future implementations for other platforms.
>>> What do you think ?
>>
>> You don't need to write assembly to read flash data with AVR gcc - you have never needed it.  To use the "progmem" attribute, include the <avr/pgmspace.h> header and use the macros and functions from there, such as "pgm_read_byte".
>>
>> <https://www.nongnu.org/avr-libc/user-manual/pgmspace_8h.html>
> That is my point. I still need to use "ppm_read_byte"

Using pgm_read-byte is not writing assembly code.  I agree that it is an 
inconvenience, but it is far less of an inconvenience than writing 
assembly would be.

>>
>>
>> Newer versions of AVR gcc have named address spaces, making the process simpler.  I must admit I haven't written any AVR code since these were added to the compiler, but I assume they work fine:
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#Named-Address-Spaces>
>>
> Thx. I didn’t read this before. This works only for C. I use C++ and there are no named address spaces extensions :-(
> 

Are you sure?  I don't have a recent AVR compiler handy, but I'd be a 
little surprised if the named address spaces are C only.  (The gcc 
documentation about extensions is not always very clear about whether 
extensions apply to C and C++, or just C.)

With a little effort, I am confident that you could make C++ template 
classes that cover the effects of the address spaces and hide the need 
for pgm_read_byte (and friends) from user code.

> My end goal is to use all variables in exactly same way as in regular code without <arv/pgmspace.h>
> 

I think that will be a bit optimistic.  The big killer here is pointers. 
  It would be reasonable for the compiler to know about direct access to 
variables, and that is in fact what you get with the named address 
spaces.  But if you pass around a "char *" pointer, there is no way for 
the compiler to know that it should point to flash memory rather than 
data memory.  You either have to manually add "pgm_read_byte" and 
friends when using the pointer, or annotate the pointer's type with an 
address space qualifier.

There is a "__memx" address space that can be used to make pointers and 
accesses generic, but that turns pointers into 24-bits and makes access 
significantly bigger and slower - you do not want that as the default.

This sort of thing has been an issue for all sorts of small 
microcontrollers, and all their compilers, since their inception.  It is 
not solvable in an ideal way that gives maximal convenience to 
programmers and still results in efficient code.  The only good solution 
is to move away from such cpu designs - there are very few reasons for 
choosing a core such as the AVR rather than an ARM, MIPS or RISC-V 
alternative.  (You might choose the AVR device for its peripherals, or 
pin package, or power usage - but not for its core.)

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 12:13:
> 
> On 23/02/2019 19:38, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 23.02.2019, o godz. 16:34:
>>> 
>>> On 22/02/2019 23:34, Łukasz Kostka wrote:
>>>> Hi
>>>> I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions etc.) in order to properly interpret variable is accessed (eg. by array subscription).
>>>> This would remove need for any assembly code written to do this.
>>>> Make user code much cleaner.
>>>> GCC having all this knowledge can optimize end assembly code.
>>>> Simple attribute addition will switch from array in memory to array in flash.
>>>> Can serve as future implementations for other platforms.
>>>> What do you think ?
>>> 
>>> You don't need to write assembly to read flash data with AVR gcc - you have never needed it.  To use the "progmem" attribute, include the <avr/pgmspace.h> header and use the macros and functions from there, such as "pgm_read_byte".
>>> 
>>> <https://www.nongnu.org/avr-libc/user-manual/pgmspace_8h.html>
>> That is my point. I still need to use "ppm_read_byte"
> 
> Using pgm_read-byte is not writing assembly code.  I agree that it is an inconvenience, but it is far less of an inconvenience than writing assembly would be.
> 
>>> 
>>> 
>>> Newer versions of AVR gcc have named address spaces, making the process simpler.  I must admit I haven't written any AVR code since these were added to the compiler, but I assume they work fine:
>>> 
>>> <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#Named-Address-Spaces <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#Named-Address-Spaces>>
>>> 
>> Thx. I didn’t read this before. This works only for C. I use C++ and there are no named address spaces extensions :-(
> 
> Are you sure?  I don't have a recent AVR compiler handy, but I'd be a little surprised if the named address spaces are C only.  (The gcc documentation about extensions is not always very clear about whether extensions apply to C and C++, or just C.)
> 
> With a little effort, I am confident that you could make C++ template classes that cover the effects of the address spaces and hide the need for pgm_read_byte (and friends) from user code.
https://pastebin.com/8km1GP9q
I use gcc 8.2.0
> 
>> My end goal is to use all variables in exactly same way as in regular code without <arv/pgmspace.h>
> 
> I think that will be a bit optimistic.  The big killer here is pointers.  It would be reasonable for the compiler to know about direct access to variables, and that is in fact what you get with the named address spaces.  But if you pass around a "char *" pointer, there is no way for the compiler to know that it should point to flash memory rather than data memory.  You either have to manually add "pgm_read_byte" and friends when using the pointer, or annotate the pointer's type with an address space qualifier.
> 
> There is a "__memx" address space that can be used to make pointers and accesses generic, but that turns pointers into 24-bits and makes access significantly bigger and slower - you do not want that as the default.
> 
> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
Yes I know that AVR are old architecture.
I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun. 
Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?

Re: AVR __progmem__ variable reading

[David Brown]

On 24/02/2019 14:47, Łukasz Kostka wrote:
> 
> 
>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no 
>> <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>
>>
>> This sort of thing has been an issue for all sorts of small 
>> microcontrollers, and all their compilers, since their inception.  It 
>> is not solvable in an ideal way that gives maximal convenience to 
>> programmers and still results in efficient code.  The only good 
>> solution is to move away from such cpu designs - there are very few 
>> reasons for choosing a core such as the AVR rather than an ARM, MIPS 
>> or RISC-V alternative.  (You might choose the AVR device for its 
>> peripherals, or pin package, or power usage - but not for its core.)
> Yes I know that AVR are old architecture.
> I will move sooner or later to RISC-V or ARM. In fact bought some board 
> from sparkfun.
> Does it mean that in newer cpu designs storing read only variables in 
> flash is easier than in AVR ?

Most 16-bit and 32-bit cpus have a single address space.  Since the same 
instructions are used to access data whether it is in ram or flash (or, 
in most cases, IO register areas), there is no longer any issue.

The AVR uses different instructions for accessing data from flash and 
from ram, which is what causes the complications.

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
> 
> 
> 
> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>> 
>>> 
>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>> Yes I know that AVR are old architecture.
>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
> 
> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
> 
> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
Thx for clarification
BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?

Re: AVR __progmem__ variable reading

[David Brown]

On 24/02/2019 18:29, Łukasz Kostka wrote:
> 
> 
>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
>>
>>
>>
>> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>>>
>>>>
>>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>>> Yes I know that AVR are old architecture.
>>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
>>
>> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
>>
>> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
> Thx for clarification
> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?
> 

No, neither ARM nor RISC-V has instructions to access data in flash or 
read-only data - that is /precisely/ the point.  Such data is accessed 
exactly like ram data and any other data, using the same instructions 
and from the same single flat memory space.

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 25.02.2019, o godz. 08:43:
> 
> 
> On 24/02/2019 18:29, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
>>> 
>>> 
>>> 
>>> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>>>> 
>>>>> 
>>>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>>>> Yes I know that AVR are old architecture.
>>>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>>>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
>>> 
>>> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
>>> 
>>> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
>> Thx for clarification
>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?
> 
> No, neither ARM nor RISC-V has instructions to access data in flash or read-only data - that is /precisely/ the point.  Such data is accessed exactly like ram data and any other data, using the same instructions and from the same single flat memory space.
Aha :-) So I just declare variable static const and voila. Well that is great. Another strong paint to migrate to newer platforms.

Re: AVR __progmem__ variable reading

[David Brown]

On 25/02/2019 18:09, Łukasz Kostka wrote:
> 
> 
>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 25.02.2019, o godz. 08:43:
>>
>>
>> On 24/02/2019 18:29, Łukasz Kostka wrote:
>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
>>>>
>>>>
>>>>
>>>> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>>>>>
>>>>>>
>>>>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>>>>> Yes I know that AVR are old architecture.
>>>>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>>>>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
>>>>
>>>> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
>>>>
>>>> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
>>> Thx for clarification
>>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?
>>
>> No, neither ARM nor RISC-V has instructions to access data in flash or read-only data - that is /precisely/ the point.  Such data is accessed exactly like ram data and any other data, using the same instructions and from the same single flat memory space.
> Aha :-) So I just declare variable static const and voila. Well that is great. Another strong paint to migrate to newer platforms.
> 

Exactly, yes.  (Or you can use non-static const if that is more
appropriate.)

With the AVR, you can also use "const" like normal - but the data will
be allocated a space in ram and copied over from flash to ram at
startup.  That way it can be read like any other data, without special
consideration, address spaces, pgm_read_byte, etc.  But of course, it
takes up space in ram - so it is fine for small constants, but perhaps a
waste of valuable ram resources for tables or strings.

And remember that on any target, if you have "static const" data and the
compiler can figure out that the data can be used directly for
calculations, immediate data, etc., and no storage is necessary, then no
storage will be allocated (in ram, flash, or anywhere else).

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 25.02.2019, o godz. 18:19:
> 
> On 25/02/2019 18:09, Łukasz Kostka wrote:
>> 
>> 
>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 25.02.2019, o godz. 08:43:
>>> 
>>> 
>>> On 24/02/2019 18:29, Łukasz Kostka wrote:
>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>>>>>> 
>>>>>>> 
>>>>>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>>>>>> Yes I know that AVR are old architecture.
>>>>>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>>>>>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
>>>>> 
>>>>> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
>>>>> 
>>>>> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
>>>> Thx for clarification
>>>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?
>>> 
>>> No, neither ARM nor RISC-V has instructions to access data in flash or read-only data - that is /precisely/ the point.  Such data is accessed exactly like ram data and any other data, using the same instructions and from the same single flat memory space.
>> Aha :-) So I just declare variable static const and voila. Well that is great. Another strong paint to migrate to newer platforms.
>> 
> 
> Exactly, yes.  (Or you can use non-static const if that is more
> appropriate.)
> 
> With the AVR, you can also use "const" like normal - but the data will
> be allocated a space in ram and copied over from flash to ram at
> startup.  That way it can be read like any other data, without special
> consideration, address spaces, pgm_read_byte, etc.  But of course, it
> takes up space in ram - so it is fine for small constants, but perhaps a
> waste of valuable ram resources for tables or strings.
> 
> And remember that on any target, if you have "static const" data and the
> compiler can figure out that the data can be used directly for
> calculations, immediate data, etc., and no storage is necessary, then no
> storage will be allocated (in ram, flash, or anywhere else).
Thx again for clarification.

Re: AVR __progmem__ variable reading

[SenthilKumar.Selvaraj]

David Brown writes:

> On 25/02/2019 18:09, Łukasz Kostka wrote:
>> 
>> 
>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 25.02.2019, o godz. 08:43:
>>>
>>>
>>> On 24/02/2019 18:29, Łukasz Kostka wrote:
>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no> w dniu 24.02.2019, o godz. 14:58:
>>>>>
>>>>>
>>>>>
>>>>> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>>>>>> Wiadomość napisana przez David Brown <david.brown@hesbynett.no <mailto:david.brown@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13:
>>>>>>>
>>>>>>>
>>>>>>> This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  It is not solvable in an ideal way that gives maximal convenience to programmers and still results in efficient code.  The only good solution is to move away from such cpu designs - there are very few reasons for choosing a core such as the AVR rather than an ARM, MIPS or RISC-V alternative.  (You might choose the AVR device for its peripherals, or pin package, or power usage - but not for its core.)
>>>>>> Yes I know that AVR are old architecture.
>>>>>> I will move sooner or later to RISC-V or ARM. In fact bought some board from sparkfun.
>>>>>> Does it mean that in newer cpu designs storing read only variables in flash is easier than in AVR ?
>>>>>
>>>>> Most 16-bit and 32-bit cpus have a single address space.  Since the same instructions are used to access data whether it is in ram or flash (or, in most cases, IO register areas), there is no longer any issue.
>>>>>
>>>>> The AVR uses different instructions for accessing data from flash and from ram, which is what causes the complications.
>>>> Thx for clarification
>>>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to access data in flash / rodata ?
>>>
>>> No, neither ARM nor RISC-V has instructions to access data in flash or read-only data - that is /precisely/ the point.  Such data is accessed exactly like ram data and any other data, using the same instructions and from the same single flat memory space.
>> Aha :-) So I just declare variable static const and voila. Well that is great. Another strong paint to migrate to newer platforms.
>> 
>
> Exactly, yes.  (Or you can use non-static const if that is more
> appropriate.)
>
> With the AVR, you can also use "const" like normal - but the data will
> be allocated a space in ram and copied over from flash to ram at
> startup.  That way it can be read like any other data, without special
> consideration, address spaces, pgm_read_byte, etc.  But of course, it
> takes up space in ram - so it is fine for small constants, but perhaps a
> waste of valuable ram resources for tables or strings.

FWIW, chips with the "avrxmega3" ISA, like the attiny416,
attiny816, attiny3216 (and almost all new devices releaesd in the last
year or so) have flash mapped into the data address space. For those
devices, rodata remains in flash and the compiler emits data address
space instructions (LDS, LD..) for reads - no wasted RAM.

Regards
Senthil