From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by sourceware.org (Postfix) with ESMTPS id A687C3858D35 for ; Wed, 28 Jun 2023 13:00:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A687C3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de Received: from excmbx-11.um.gwdg.de ([134.76.9.220] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qEUmc-000KHS-GI; Wed, 28 Jun 2023 15:00:30 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by excmbx-11.um.gwdg.de (134.76.9.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.27; Wed, 28 Jun 2023 15:00:30 +0200 Received: from vra-171-131.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.27; Wed, 28 Jun 2023 15:00:29 +0200 Message-ID: <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> Subject: Re: wishlist: support for shorter pointers From: Martin Uecker To: =?UTF-8?Q?Rafa=C5=82?= Pietrak , "gcc@gcc.gnu.org" Date: Wed, 28 Jun 2023 15:00:26 +0200 In-Reply-To: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-12.um.gwdg.de (134.76.9.221) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sounds like named address spaces to me: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html 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