From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by sourceware.org (Postfix) with ESMTPS id D8BB83858408 for ; Wed, 5 Jul 2023 12:01:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D8BB83858408 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de Received: from excmbx-05.um.gwdg.de ([134.76.9.209] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qH1CQ-0005eQ-3r; Wed, 05 Jul 2023 14:01:34 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by excmbx-05.um.gwdg.de (134.76.9.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.27; Wed, 5 Jul 2023 14:01:33 +0200 Received: from fbmtpc21.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.27; Wed, 5 Jul 2023 14:01:33 +0200 Message-ID: <752c1de8615ee565f227a5682887a8039f32a56b.camel@gwdg.de> Subject: Re: wishlist: support for shorter pointers From: Martin Uecker To: David Brown , =?UTF-8?Q?Rafa=C5=82?= Pietrak , Ian Lance Taylor CC: "Richard Earnshaw (lists)" , "gcc@gcc.gnu.org" Date: Wed, 5 Jul 2023 14:01:27 +0200 In-Reply-To: <90b69927-65ac-98b4-c709-762b395018a4@westcontrol.com> References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> <6c881d3fc76d112d52ec668d05b68394ae792f30.camel@gwdg.de> <1eeef918-80d0-12a3-e7e9-5a75b25fb769@ztk-rp.eu> <8825a11f-e462-8d97-3cdf-a5015250f3c1@westcontrol.com> <1be0adf325de7bf6cdb9c5caa7be2b41e5734786.camel@gwdg.de> <90b69927-65ac-98b4-c709-762b395018a4@westcontrol.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-12.um.gwdg.de (134.76.9.221) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Thanks David! I do not think I agree with all of it (e.g. sdcc is actively developed with regular releases and supports  tiny devices which are used for extreme low-power  applications) and I do not personally think that only  C++ counts nowadays, especially in the embedded world,  but we do not need to discuss this now. I still very much appreciate your input! Note that I am involved with C standardization, but TR 18307 precedes this. Martin Am Mittwoch, dem 05.07.2023 um 13:34 +0200 schrieb David Brown: > > > On 05/07/2023 11:25, Martin Uecker wrote: > > Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown: > > > On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: > > > > ... > > > > > > In my personal opinion (which you are all free to disregard), > > > named > > > address spaces were an interesting idea that failed.  I was > > > enthusiastic > > > about a number of the extensions in TR 18307 "C Extensions to > > > support > > > embedded processors" when the paper was first published.  As I > > > learned > > > more, however, I saw it was a dead-end.  The features are too > > > under-specified to be useful or portable, gave very little of use > > > to > > > embedded programmers, and fit badly with C.  It was an attempt to > > > standardise and generalise some of the mess of different > > > extensions > > > that > > > proprietary toolchain developers had for a variety of 8-bit CISC > > > microcontrollers that could not use standard C very effectively.  > > > But > > > it > > > was all too little, too late - and AFAIK none of these > > > proprietary > > > toolchains support it.  GCC supports some of the features to some > > > extent > > > - a few named address spaces on a few devices, for "gnuc" only > > > (not > > > standard C, and not C++), and has some fixed point support for > > > some > > > targets (with inefficient generated code - it appears to be > > > little > > > more > > > than an initial "proof of concept" implementation). > > > > > > I do not think named address spaces have a future - in GCC or > > > anywhere > > > else.  The only real use of them at the moment is for the AVR for > > > accessing data in flash, and even then it is of limited success > > > since > > > it > > > does not work in C++. > > > > Can you explain a little bit why you think it is a dead-end?  It > > seems an elegant solution to a range of problems to me. > > Named address spaces are not standardised in C, and I do not expect > they > ever will be.  The TR18307 document is not anywhere close to being of > a > quality that could be integrated with the C standards, even as > optional > features, and much of it makes no sense in practice (I have never > heard > of the IO stuff being implemented or used). > > The few compilers that implement any of it do so in different ways - > the > "__flash" address space in AVR GCC is slightly different from the > same > extension in IAR's AVR compiler.  For existing compilers, there is a > strong inconsistency as to whether such things are "named address > spaces", "extension keywords", "type qualifiers", "attributes", or > other > terms, all with subtly (or not so subtly) different effects on how > they > are used, what restrictions exist, conversions between types, and how > errors can be diagnosed.  Sometimes these features are considered > part > of the data type, sometimes of pointer types, sometimes they are just > about data placement. > > Since every compiler targeting these small awkward microcontrollers > has > a different idea of what something like "const __flash int x = 123;" > means, and has been implementing their own ideas for a decade or two > before TR18307 ever proposed "named address spaces", the TR hasn't a > hope of being a real standard. > > Named address spaces are not implemented at all, anywhere (AFAIK), > for > C++.  (Some embedded toolchains have limited support for C++ on such > microcontrollers, but these are again not really named address > spaces.) > Since C++ usage is heavily increasing in the small embedded system > world, this is important.  (GCC has much of the honour for that - as > ARM > took a bigger share of the market and GCC for ARM improved, the > toolchain market was no longer at the mercy of big commercial vendors > who charged absurd amounts for their C++ toolchains.)  A feature > which > is only for C, and not supported by C++, is almost guaranteed to be > dead-end. > > And of course the type of processor for which named address spaces or > other related extensions are essential, are a dying breed.  The AVR > is > probably the only one with a significant future.  Part of the appeal > of > ARM in the embedded world is it frees you from the pains of > target-specific coding with some of your data in "near" memory, some > in > "extended" memory, some in "flash" address spaces or "IO" address > spaces.  It all works with standard C or C++.  The same applies to > challengers like RISC-V, MIPS, PPC, and any other core - you have a > single flat address space for normal data. > > > > > I have no idea how much the GCC features are actually used, > > but other compilers for  embedded systems such as SDCC also > > support named address spaces. > > > > And the targets supported by SDCC are also dead-end devices - there > is > not a single one of them that I would consider for a new project.  > These > microcontrollers are now used almost exclusively for legacy projects > - > updates to existing hardware or software, and rely on compatibility > with > existing C extensions (whether they are called "named address > spaces", > "extension keywords", or anything else). > > > Now, there are things that I would like to be able to write in my > code > that could appear to be candidates for some kind of named address > space. >   For example, I might want data that is placed in an external eeprom > - > it could be nice to be able to define, declare, read and write it > like > normal data in the code.  But key to this would be the ability to > define > the way this works in /user/ code - named address spaces require > changing the toolchain, which is out of the question in almost all > use-cases.  And it would spoil one of C's key advantages over > alternative languages - to a fair extent (though not as completely as > many people believe), you can guess what is happening from the code. > You assume that "x = eeprom_var;" is small and efficient, while "x = > read_eeprom(eeprom_var)" might take significant time to execute.  > People > don't like hidden things in their C code. > > It would be conceivable for GCC to add extensions that could be used > to > define your own named address spaces in user code.  But doing so > would > require a lot of syntax and features that already exist in C++. > > I would rather see better ways of controlling placement of data added > to > the compiler.  In another post, I suggested allowing variable > attributes > - such as "section" - to be attached to types.  I'd also like to see > a > way to specify the section name by compile-time evaluated code, not > just > a string literal.  I'd like to be able to give sub-sections, and > section > flags in a convenient way.  And - perhaps most importantly - I'd like > to > be able to use #pragma's to give sections for code or data for a > block > of code and data at a time, rather than having to specify it > individually on each function.  (That could perhaps also be done by > allowing section attributes on namespaces in C++.) > > > David >