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 E6E123858423 for ; Wed, 5 Jul 2023 13:35:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E6E123858423 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 15:30:05 +0200 id 000000001C809BC4.0000000064A5705D.0000238F Received: from public-gprs569267.centertel.pl ([37.225.86.244]:8156 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 1qH2a4-00Eiq4-4w; Wed, 05 Jul 2023 15:30:05 +0200 Message-ID: <540fa64b-0263-ba43-2c2a-2973ab376826@ztk-rp.eu> Date: Wed, 5 Jul 2023 15:29:59 +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> <701a38b8-9e90-36ce-9357-8b648f04a4d8@ztk-rp.eu> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: 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 14:57, David Brown pisze: [------------] > > My objection to named address spaces stem from two points: > > 1. They are compiler implementations, not user code (or library code), > which means development is inevitably much slower and less flexible. > > 2. They mix two concepts that are actually quite separate - how objects > are allocated, and how they are accessed. OK. I don't see a problem here, but I admit that mixing semantics often lead to problems. > Access to different types of object in different sorts of memory can be > done today.  In C, you can use inline functions or macros.  For > target-specific stuff you can use inline assembly, and GCC might have > builtins for some target-specific features.  In C++, you can also wrap > things in classes if that makes more sense. Personally, I'd avoid inline assembly whenever possible. It does a very good job of obfuscating programmers' intentions. From my experience, I'd rather put the entire functions into assembler if compiler makes obstacles. But that's not an issue here. > Allocation is currently controlled by "section" attributes.  This is > where we I believe GCC could do better, and give the user more control. > (It may be possible to develop a compiler-independent syntax here that > could become part of future C and C++ standards, but I think it will > unavoidably be heavily implementation dependent.) I agree. > > All we really need is a way to combine these with types to improve user > convenience and reduce the risk of mistakes.  And I believe that > allowing allocation control attributes to be attached to types would > give us that in GCC.  Then it would all be user code - typedefs, macros, > functions, classes, whatever suits. OK. Sounds good. Naturally I have my "wishlist": the "small pointers" segment/attribute :) But how (and to what extend) would you do that? I mean, the convenient syntax is desirable, but IMHO at this point there is also a question of semantics: what exactly compiler is supposed to tell linker? I think it would be good to list here the use scenarios that we now of. Scenarios that would benefit from compiler communicating to linker more then names@sections. (even if such list wouldn't evolve into any implementation effort at this point I think that would nicely conclude this thread.) -R