From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53314 invoked by alias); 24 Feb 2019 17:29:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 53223 invoked by uid 89); 24 Feb 2019 17:29:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*r:sk:dynamic, H*RU:sk:dynamic, Hx-spam-relays-external:sk:dynamic, designs X-HELO: 12.mo4.mail-out.ovh.net Received: from 12.mo4.mail-out.ovh.net (HELO 12.mo4.mail-out.ovh.net) (178.33.104.253) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Feb 2019 17:29:11 +0000 Received: from player159.ha.ovh.net (unknown [10.109.159.68]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 4A55C1D74B4 for ; Sun, 24 Feb 2019 18:29:09 +0100 (CET) Received: from netng.pl (dynamic-78-8-169-236.ssp.dialog.net.pl [78.8.169.236]) (Authenticated sender: lukasz.kostka@netng.pl) by player159.ha.ovh.net (Postfix) with ESMTPSA id 45D152EC92EB; Sun, 24 Feb 2019 17:29:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: AVR __progmem__ variable reading From: =?utf-8?Q?=C5=81ukasz_Kostka?= In-Reply-To: Date: Sun, 24 Feb 2019 17:29:00 -0000 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <411E48E5-7C80-4D6B-B4F3-5A3934904F45@netng.pl> References: <81B3654D-A99C-4216-A207-0522C9E8AA68@netng.pl> To: David Brown X-Ovh-Tracer-Id: 15304357435624053567 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrudeggddutdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00135.txt.bz2 > Wiadomo=C5=9B=C4=87 napisana przez David Brown = w dniu 24.02.2019, o godz. 14:58: >=20 >=20 >=20 > On 24/02/2019 14:47, =C5=81ukasz Kostka wrote: >>> Wiadomo=C5=9B=C4=87 napisana przez David Brown > w dniu 24.02.2019, o godz. 12:13: >>>=20 >>>=20 >>> This sort of thing has been an issue for all sorts of small microcontro= llers, and all their compilers, since their inception. It is not solvable = in an ideal way that gives maximal convenience to programmers and still res= ults in efficient code. The only good solution is to move away from such c= pu 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 i= ts 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 fl= ash is easier than in AVR ? >=20 > 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. >=20 > The AVR uses different instructions for accessing data from flash and fro= m 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 a= ccess data in flash / rodata ?