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 A97473857708 for ; Wed, 5 Jul 2023 07:30:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A97473857708 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-25.um.gwdg.de ([134.76.9.235] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qGwxa-000D14-GI; Wed, 05 Jul 2023 09:29:58 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by excmbx-25.um.gwdg.de (134.76.9.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.27; Wed, 5 Jul 2023 09:29:58 +0200 Received: from vra-168-120.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, 5 Jul 2023 09:29:57 +0200 Message-ID: Subject: Re: wishlist: support for shorter pointers From: Martin Uecker To: =?UTF-8?Q?Rafa=C5=82?= Pietrak , David Brown , Ian Lance Taylor CC: "Richard Earnshaw (lists)" , "gcc@gcc.gnu.org" Date: Wed, 5 Jul 2023 09:29:56 +0200 In-Reply-To: References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> <6c881d3fc76d112d52ec668d05b68394ae792f30.camel@gwdg.de> 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-21.um.gwdg.de (134.76.9.231) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.5 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: Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak: > Hi, > > W dniu 5.07.2023 o 00:57, Martin Uecker pisze: > > Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:... > [--------] > > > > > > Yes. named address spaces would be great. And for code, too. > > > > > > > While certainly some work, implementation effort for > > new kinds of named address spaces does not seem to be > > terrible at first glance: > > > > https://gcc.gnu.org/onlinedocs/gccint/target-macros/adding-support-for-named-address-spaces.html > > Oh! I see. this is good news. Although that internals documentation is > complete black magic to me and I cannot tell heads from tails in it, the > surrounding comments sound promising... like GCC-13 actually had the > internal "machinery" supporting named address spaces and just > cpu-platform specific code is missing (for all but "SPU port"). Is that > right? It seems like this. I would need to do more research. > > And if it's so ... there is no mention of how does it show up for > "simple user" of the GCC (instead of the use of that "machinery" by > creators of particular GCC port). In other words: how the sources should > look like for the compiler to do "the thing"? > Not sure I understand the question. You would add a name space to an object as a qualifier and then the object would be allocated in a special (small) region of memory. Pointers known to point into that special region of memory (which is encoded into the type) would then be smaller. At least, this is my understanding  of how it could work. Martin