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 D38003858D37 for ; Wed, 28 Jun 2023 14:54:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D38003858D37 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, 28 Jun 2023 16:51:19 +0200 id 0000000010043EA0.00000000649C48E7.00000911 Received: from public-gprs403814.centertel.pl ([37.47.208.167]:11926 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 1qEWVo-00CdJp-Mj; Wed, 28 Jun 2023 16:51:18 +0200 Message-ID: Date: Wed, 28 Jun 2023 16:51:13 +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: 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: <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 37.47.208.167 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,KAM_SHORT,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 Martin, W dniu 28.06.2023 o 15:00, Martin Uecker pisze: > > Sounds like named address spaces to me: > https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html Only to same extend, and only in x86 case. The goal of the wish-item I've describe is to shorten pointers. I may be wrong and have misread the specs, but the "address spaces" implementation you've pointed out don't look like doing that. In particular the AVR variant applies to devices that have a "native int" of 16-bits, and those devices (most of them) have address space no larger. So there is no gain. Their pointers cover all their address space and if one wanted to have shorter pointers ... like 12-bits - those wouldn't "nicely fit into register", or 8-bits - those would reduce the "addressable" space to 256 bytes, which is VERY tight for any practical application. Additionally, the AVR case is explained as "only for rodata" - this completely dismisses it from my use. To explain a little more: the functionality I'm looking for is something like x86 implementation of that "address spaces". The key functionality here is the additional register like fs/gs (an address offset register). IMHO the feature/implementation in question would HAVE TO use additional register instead of letting linker adjust them at link time, because those "short" pointers would need to be load-and-stored dynamically and changed dynamically at runtime. That's why I've put an example of ARM instruction that does this. Again IMHO the only "syntactic" feature,that is required for a compiler to do "the right thing" is to make compiler consider segment (segment name, ordinary linker segment name) where a particular pointer target resides. Then if that segment where data (of that pointer) reside is declared "short pointers", then compiler loads and uses additional register pointing to the base of that segment. Quite like intel segments work in hardware. Naturally, although I have hints on such mechanism behavior, I have no skills to even imagine where to tweak the sources to achieve that. -R > > Best, > Martin > > Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pietrak via Gcc: >> Hello everybody, >> >> I'm not quite sure if this is correct mailbox for this suggestion (may >> be "embedded" would be better), but let me present it first (and while >> the examples is from ARM stm32 environment, the issue would equally >> apply to i386 or even amd64). So: >> >> 1. Small MPU (like stm32f103) would normally have small amount of RAM, >> and even somewhat larger variant do have its memory "partitioned/ >> dedicated" to various subsystems (like CloseCoupledMemory, Ethernet >> buffers, USB buffs, etc). >> >> 2. to address any location within those sections of that memory (or >> their entire RAM) it would suffice to use 16-bit pointers. >> >> 3. still, declaring a pointer in GCC always allocate "natural" size of a >> pointer in given architecture. In case of ARM stm32 it would be 32-bits. >> >> 4. programs using pointers do keep them around in structures. So >> programs with heavy use of pointers have those structures like 2 times >> larger then necessary .... if only pointers were 16-bit. And memory in >> those devices is scarce. >> >> 5. the same thing applies to 64-bit world. Programs that don't require >> huge memories but do use pointers excessively, MUST take up 64-bit for a >> pointer no matter what. >> >> So I was wondering if it would be feasible for GCC to allow SEGMENT to >> be declared as "small" (like 16-bit addressable in 32-bit CPU, or 32-bit >> addressable in 64-bit CPU), and ANY pointer declared to reference >> location within them would then be appropriately reduced. >> >> In ARM world, the use of such pointers would require the use of an >> additional register (functionally being a "segment base address") to >> allow for data access using instructions like: "LD Rx, [Ry, Rz]" - >> meaning register index reference. Here Ry is the base of the SEGMENT in >> question. Or if (like inside a loop) the structure "pointed to" by Rz >> must be often used, just one operation "ADD Rz, Ry" will prep Rz for >> subsequent "ordinary" offset operations like: "LD Ra, [Rz, #member]" ... >> and reentering the loop by "LDH Rz, [Rz, #next]" does what's required by >> "x = x->next". >> >> Not having any experience in compiler implementations I have no idea if >> this is a big or a small change to compiler design. >> >> -R > >