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 A48243858D35 for ; Thu, 29 Jun 2023 06:19:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A48243858D35 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; Thu, 29 Jun 2023 08:19:55 +0200 id 0000000003CACA23.00000000649D228B.0000109D Received: from public-gprs569267.centertel.pl ([37.225.86.244]:17738 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 1qEl0T-00Cp6T-1W; Thu, 29 Jun 2023 08:19:54 +0200 Message-ID: Date: Thu, 29 Jun 2023 08:19:49 +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: "Richard Earnshaw (lists)" , Martin Uecker , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> 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 Richard, W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze: [-----------] > I think I understand what you're asking for but: > 1) You'd need a new ABI specification to handle this, probably involving > register assignments (for the 'segment' addresses), the initialization > of those at startup, assembler and linker extensions to allow for > relocations describing the symbols, etc. I was thinking about that, and it doesn't look as requiring that deep rewrites. ABI spec, that could accomodate the functionality could be as little as one additional attribute to linker segments. Pls consider: 1. having that additional attribute (say "funny-ptr") of a segment. 2. ... from linker one would require only: 2.a) raising an error (fail) if one object has same segment-name WITH that attribute, and another object has that segment WITHOUT one. 2.b) raise an error (fail) if the resulting output segment would be larger then "max" (normally, max=64kB). 3. assembler would only need to be able to declare a segment with the new attribute 4. almost all the implementation changes are within the CC. Those changes can be broken down into a couple of scenarios: 4.a) for the following explanation, instead of __attribute__(section()), I will use shortcut. 4.b) assignment of "normal" to "funny" (char* x; char* y; x = y); here compiler would have to substract segment base address before deposition value at "&x", but for subsequent use of "x", compiler does NOT need to do anything. 4.c) reverse assignment (y = x); here compiler does nothing special, just uses "current/adjusted" value of "x". 4.d) comparation (x == y); compiler does nothing special - at this point, some register will already have "current/adjusted" value of "x". 4.e) comparation to NULL (x; !x; x == NULL); those test have to be done on "unadjusted" value of "x", so if register containing "x" is already adjusted, the base address will have to get substracted from "x" before test. And it may be good to take special care on loops (like "for()"). In case the loop looking like this: "for(;x; x = x->next)" the test is to be done before adjusting the pointer "x" by segment base address for the next loop-cycle, so there is no penalty for that test. I hope I didn't omit any important cases. If so, it doesn't look huge. Now, I'm NOT trying to persuade anybody, that it's "simple" and thus should be worth doing. I'm just doing some "intellectual exercise" with analyzing the challenge. -R