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 222F43858D1E for ; Wed, 28 Jun 2023 07:13:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 222F43858D1E 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 09:13:24 +0200 id 0000000010043EAD.00000000649BDD94.00004329 Received: from public-gprs403814.centertel.pl ([37.47.208.167]:5944 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 1qEPMh-00CXLV-DI; Wed, 28 Jun 2023 09:13:24 +0200 Message-ID: Date: Wed, 28 Jun 2023 09:13:14 +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: waffl3x Cc: "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@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.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.8 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 Alex! W dniu 28.06.2023 o 03:54, waffl3x pisze: > I want to preface this stating that I have little to no experience in compiler > development, I am only merely just getting into it. With that said, I have messed around > with library design a fair amount, and this seems like something that could be > implemented in a library. It might be slightly comfier implemented on the compiler side, > but I question how generally it could be implemented. I thought of it a lot, and library implementation is something I'd rather avoid. Before I elaborate, let me put some excerpts of the code in question. GREP-ing the sources for "->next" (list processing) this is how it looks like. I have a lot of code like this scattered around: ------------------- y->next = NULL; if (our) { out->next = a; for (y = t->HD; y && y->next; y = y->next) if (y) y->next = a; fit->HD = a->next; fit->win = a->next; b = a->next; -------------------- This is from just one source file, which otherwise is "plain C". If I was to put it into a library that use "asm tweaked fancy pointers", a portable fragment of code becomes "target dedicated" - this is undesired. To elaborate: even in (or may be "particularly" in) embedded world, one prefers to have as portable code (to other targets) as possible. And I must say, that such code fragments as quoted are scattered around my sources practically everywhere. If I "convert" them to a library, the entire project becomes "target locked", and in consequences "unmaintainable". Such move practically kills it. Now, let me put the case into numbers: if I use stm32f030 instead of stm32f103, I may end up with just 4kB of RAM. The struct I heavily use here is 32bytes long, but with 16-bit "pointers" it collapses to 16bytes. This structure pops up in many places and within a running system it may reach 100 instances. It's a LOT of space to fight for. -R PS: pls CC the response to my address (as you have done) - I'm not sure if I get mails from the list.