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 AEC253857737 for ; Wed, 5 Jul 2023 09:45:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AEC253857737 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 11:42:25 +0200 id 000000000129BDFB.0000000064A53B01.00000347 Received: from public-gprs569267.centertel.pl ([37.225.86.244]:2808 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 1qGz1k-00EeGf-I0; Wed, 05 Jul 2023 11:42:25 +0200 Message-ID: <45292545-b4e1-a2c8-38d0-a7773f309ca5@ztk-rp.eu> Date: Wed, 5 Jul 2023 11:42:21 +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> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: <8825a11f-e462-8d97-3cdf-a5015250f3c1@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 11:11, David Brown pisze: > On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: [-----------] >>> type) would then be smaller.  At least, this is my understanding >>> of how it could work. > > Note that this only applies to pointers declared to be of the address > space specific type.  If you have "__smalldata int x;" using a > hypothetical new address space, then "&x" is of type "__smalldata int *" > and you need to specify the address space specific pointer type to get > the size advantages.  (Since the __smalldata address space is a subset > of the generic space, conversions between pointer types are required to > work correctly.) I see. [--------] >> thing like "#pragma" at the top of a file would do a better job), >> better something then nothing. Then again, should you happen to fall >> onto an actual documentation of syntax to use this feature with, I'd >> appreciate you sharing it :) >> > > I am not sure if you are clear about this, but the address space > definition macros here are for use in the source code for the compiler, > not in user code.  There is (AFAIK) no way for user code to create > address spaces - you need to check out the source code for GCC, modify > it to support your new address space, and build your own compiler.  This > is perfectly possible (it's all free and open source, after all), but it > is not a minor undertaking - especially if you don't like C++ ! Hmmm. 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.*")? [------] > I realise that learning at least some C++ is a significant step beyond > learning C - but /using/ C++ classes or templates is no harder than C > coding.  And it is far easier, faster and less disruptive to make a C++ > header library implementing such features than adding new named address > spaces into the compiler itself. > > The one key feature that is missing is that named address spaces can > affect the allocation details of data, which cannot be done with C++ > classes.  You could make a "small_data" class template, but variables > would still need to be marked __attribute__((section(".smalldata"))) > when used.  I think this could be handled very neatly with one single > additional feature in GCC - allow arbitrary GCC variable attributes to > be specified for types, which would then be applied to any variables > declared for that type. OK. I see your point. 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. 2. affecting allocation details is usually the hole point of engineering skills when dealing with small embedded devices - the hole point is to have tools to do that. So your current objections to named spaces ... are in fact in favor of them. Isn't it so? -R