From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23042 invoked by alias); 23 Feb 2019 18:38:22 -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 23034 invoked by uid 89); 23 Feb 2019 18:38:21 -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,KAM_SHORT,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, wiadomo X-HELO: 10.mo179.mail-out.ovh.net Received: from 10.mo179.mail-out.ovh.net (HELO 10.mo179.mail-out.ovh.net) (46.105.79.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Feb 2019 18:38:19 +0000 Received: from player794.ha.ovh.net (unknown [10.109.143.208]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 8135C11AD18 for ; Sat, 23 Feb 2019 19:38:16 +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 player794.ha.ovh.net (Postfix) with ESMTPSA id 5F026300E6E8; Sat, 23 Feb 2019 18:38:14 +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: Sat, 23 Feb 2019 18:38:00 -0000 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <81B3654D-A99C-4216-A207-0522C9E8AA68@netng.pl> References: To: David Brown X-Ovh-Tracer-Id: 10598940248518220607 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddruddvgdduudekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00129.txt.bz2 > Wiadomo=C5=9B=C4=87 napisana przez David Brown = w dniu 23.02.2019, o godz. 16:34: >=20 > On 22/02/2019 23:34, =C5=81ukasz Kostka wrote: >> Hi >> I am using for a while now gcc and especially __progmem__ attribute. I= =E2=80=99d like to report a feature request for gcc to handle reading from = flash memory variables. Compiler has all the knowledge (target device, avai= lability of LPM, ELPM instructions etc.) in order to properly interpret var= iable 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 f= lash. >> Can serve as future implementations for other platforms. >> What do you think ? >=20 > You don't need to write assembly to read flash data with AVR gcc - you ha= ve never needed it. To use the "progmem" attribute, include the header and use the macros and functions from there, such as "pgm_rea= d_byte". >=20 > That is my point. I still need to use "ppm_read_byte"=20 >=20 >=20 > Newer versions of AVR gcc have named address spaces, making the process s= impler. I must admit I haven't written any AVR code since these were added= to the compiler, but I assume they work fine: >=20 > >=20 Thx. I didn=E2=80=99t read this before. This works only for C. I use C++ an= d there are no named address spaces extensions :-( My end goal is to use all variables in exactly same way as in regular code = without