From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sm.strop.com.pl (sm.strop.com.pl [83.17.179.219]) by sourceware.org (Postfix) with ESMTPS id 733BC3858C5E for ; Wed, 5 Jul 2023 12:26:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 733BC3858C5E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ztk-rp.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ztk-rp.eu Received: from zorro.ztk-rp.eu ([::ffff:10.208.4.171]) (TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by sm.strop.com.pl with ESMTPS; Wed, 05 Jul 2023 14:25:34 +0200 id 000000000129B303.0000000064A5613E.00001B0E Received: from public-gprs569267.centertel.pl ([37.225.86.244]:11838 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qH1Zd-00EhJd-9I; Wed, 05 Jul 2023 14:25:33 +0200 Message-ID: <701a38b8-9e90-36ce-9357-8b648f04a4d8@ztk-rp.eu> Date: Wed, 5 Jul 2023 14:25:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: David Brown , Martin Uecker , Ian Lance Taylor Cc: "Richard Earnshaw (lists)" , "gcc@gcc.gnu.org" 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> <45292545-b4e1-a2c8-38d0-a7773f309ca5@ztk-rp.eu> <25afc1cb-3a62-135d-3206-2d9eb6216944@westcontrol.com> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: <25afc1cb-3a62-135d-3206-2d9eb6216944@westcontrol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 37.225.86.244 X-SA-Exim-Mail-From: embedded@ztk-rp.eu X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 Subject: Re: wishlist: support for shorter pointers X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000) X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu) Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=embedded@ztk-rp.eu; remoteip=::ffff:10.208.4.171; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl; List-Id: Hi, W dniu 5.07.2023 o 13:55, David Brown pisze: > On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote: [--------------] >> Wouldn't it be easier and more natural to make the "named spaces" a >> synonym to specific linker sections (like section names, or section >> name prefix when instead of ".data.array.*" one gets >> ".mynamespace.array.*")? > > You can, of course, write : > > #define __smalldata __attribute__((section(".smalldata))) > > I'd rather see the "section" attribute extended to allow it to specify a > prefix or suffix (to make subsections) than more named address spaces. me to. (pun not intended :) > I'm a big fan of only putting things in the compiler if they have to be > there - if a feature can be expressed in code (whether it be C, C++, or > preprocessor macros), then I see that as the best choice. Fully agree. ... almost fully. I'd rather say: "I'm a big fun of being able to tell the compiler what I mean, but leave functionality/algorithms in libs". And I think this has some resonance to our discussion. I think, that as of today, C-sources (though the compiler) don't have enough "vocabulary" to tell the linker "what we mean", and so the ability to "select flash vs RAM" or "one RAM vs another" is limited. The compiler/linker language is pretty much limited to resolved/unresolved names and their binding to linker segments.... like you've pointed above. [--------] >> But let's have look at it. You say, that "names spaces affect >> allocation details, which cannot be done with C++". Pls consider: >> 1. for small embedded devices C++ is not a particularly "seller". We >> even turn to assembler occasionally. > > I have been writing code for small embedded systems for about 30 years. > I used to write a lot in assembly, but it is very rare now.  Almost all > of the assembly I write these days is inline assembly in gcc format - > and a lot of that actually contains no assembly at all, but is for > careful control of dependencies or code re-arrangements.  The smallest > device I have ever used was an AVR Tiny with no ram at all - just 2K > flash, a 3-level return stack and its 32 8-bit registers.  I programmed > that in C (with gcc). Well, similar here, although not that intensive (hobby, not profession). Still, I've never touched the Tiny, as I wasn't able to wrap my head around those limited resources for anything more then a blinker. [--------------] > Allocation control is certainly important at times, but it's far from > being as commonly needed as you suggest. > > (Dynamic allocation is a different matter, but I don't believe we are > talking about that here.) yes, not about that. > >> So your current objections to named spaces ... are in fact in favor of >> them. Isn't it so? >> > > Not really, no - I would rather see better ways to handle allocation and > section control than more named address spaces. Doesn't it call for "something" that a c-source (through the compiler) can express to the linker programmers' intention? -R