> Wiadomość napisana przez David Brown <david.br...@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.br...@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 ?
