public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: "Łukasz Kostka" <lukasz.kostka@netng.pl>
Cc: gcc@gcc.gnu.org
Subject: Re: AVR __progmem__ variable reading
Date: Mon, 25 Feb 2019 17:19:00 -0000	[thread overview]
Message-ID: <d43a53be-1f3e-7393-b789-6f88bb11973f@hesbynett.no> (raw)
In-Reply-To: <420601D1-9B74-4009-B59C-AC16FA1FE170@netng.pl>

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).

  reply	other threads:[~2019-02-25 17:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 22:34 Łukasz Kostka
2019-02-23 15:34 ` David Brown
2019-02-23 18:38   ` Łukasz Kostka
2019-02-24 11:13     ` David Brown
2019-02-24 13:47       ` Łukasz Kostka
2019-02-24 13:58         ` David Brown
2019-02-24 17:29           ` Łukasz Kostka
2019-02-25  7:43             ` David Brown
2019-02-25 17:09               ` Łukasz Kostka
2019-02-25 17:19                 ` David Brown [this message]
2019-02-25 19:32                   ` Łukasz Kostka
2019-02-26  6:05                   ` SenthilKumar.Selvaraj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d43a53be-1f3e-7393-b789-6f88bb11973f@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gcc@gcc.gnu.org \
    --cc=lukasz.kostka@netng.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).