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 5A5673858D28 for ; Tue, 27 Jun 2023 12:26:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A5673858D28 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; Tue, 27 Jun 2023 14:26:10 +0200 id 0000000008874C7F.00000000649AD562.000034F9 Received: from public-gprs403814.centertel.pl ([37.47.208.167]:4324 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 1qE7ll-00CJ5N-UF for gcc@gcc.gnu.org; Tue, 27 Jun 2023 14:26:09 +0200 Message-ID: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> Date: Tue, 27 Jun 2023 14:26:02 +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: "gcc@gcc.gnu.org" From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 Subject: 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: 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