From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by sourceware.org (Postfix) with ESMTPS id CBD333858D32 for ; Wed, 28 Jun 2023 01:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBD333858D32 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com Date: Wed, 28 Jun 2023 01:54:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1687917281; x=1688176481; bh=XRN33gjmwcBFtAe+HvqELHIt0lKhnJCf0vsmpOBANRQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=rqKvgCTpozvJYzr7RwMMI+yEycHG/DcKzI49W08+7NeJxSyhd0E5VoD03ugt8kIaK nZyuNJiADrIYVN05zJ7pLDIssIKhK5gpsAWWJODvWakgXWrgpMfxQffVebmQy//O+y mTtyG2KwwM4KKeENHQC1BmdpbPqWyTdWRZg/Li33hbXcL2uh/GprSzfcTZJQdw04ae f0puga6IEq30G1XYHc+eMCZA/103GIM5JjlBW1PnIP21o8hELwrCd77nu+3/hAm3xz 7EK/kVWSqouqKoKhyYY/NJXEvLsldbhYMLwJ2ELhkCuZ6AOxpof6+Zjql43ihuqqi1 AYr8aVW5luZFg== To: =?utf-8?Q?Rafa=C5=82_Pietrak?= From: waffl3x Cc: "gcc@gcc.gnu.org" Subject: Re: wishlist: support for shorter pointers Message-ID: In-Reply-To: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: I want to preface this stating that I have little to no experience in compi= ler 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 c= ompiler side, but I question how generally it could be implemented. >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. What you say here makes me feel like you should just be implementing this i= n library. With how you're describing it, it seems like the compiler would ha= ve no idea what the "segment base address" would actually be without additional annota= tion. Since you would need that annotation anyway, it seems best implemented in l= ibrary. I think what you want to do (for 16 bit pointers) is have a struct that internally is a fixed width 16 bit uint, and have an operator* that sets up= the registers for that particular segment. It would be a bit of an implementation task si= nce you have to do some inline ASM, but thats just the reality of implementing low = level libraries. Like I said before, and unless I'm mistaken, since the segments = would need annotations anyway, it probably makes the most sense to implement this in l= ibrary as I'm describing. I believe these types would be referred to as "fancy pointers."=20 Hopefully I'm not too mistaken as I don't have any experience with this fie= ld. In general though, I believe that if something can be implemented in a reas= onable way in library, then it belongs in library, not in language or other extens= ions. -Alex