From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-SV0-obe.outbound.protection.outlook.com (mail-sv0nor01on2086.outbound.protection.outlook.com [40.107.225.86]) by sourceware.org (Postfix) with ESMTPS id 6D1AC3858D35 for ; Tue, 4 Jul 2023 15:55:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D1AC3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=westcontrol.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JEJ3q1ooKJXjG7q+AcfNqy/M+jGs47Ih6LqktnoYI6E2EZ5OB7T/uhJ6BHqSv/AVdzPT/5IxlZf3TDm6QR3VosCjtOgiMhdk/NfWCqoKsrtdI7kcMjGxf2/ShK74+EQgBolWDgAHJxGzXXHwEgdT19CmorBE1CcYQ04cK7DgDVGZcF9zTBatL9HAXAiu9+UFvAuN1Hv7aII4nI77tBFNyWsocrGjqkdUOJRUnGYdqpRb6pWVFmSMouBoY4jAIvU1k5i6FpuDjLD0vvy03lM9ClTWg2N2acdcQOihRtRaykX0zp1B7NUgLwc8cP631JjbxsZJNBWNfpXM8FVgAh2kFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sf6pdUCST4Lq/xX4Hc98y4VExDbwZpEUINCQTcPJIbQ=; b=LlzPm+pRbc13u+ZyUcBM9B5198BlzfuVw70fEcJ8U0/LvDrUUbNn/PgsgC2HV20vsTZEz6Rlqa7hpYc0MYf0khnqngs+pmPzaGBfYuEHumtxMQvxEePovKxgsvGAxuD9q2sxOKDhnLnrfFaG6fhrUyF6MjX3Q04GtZDtMz4koBuXN2NtA1gXX4k02r/ExGBKP9L7T6p6j8vIVr9wN0h5BoIFsnjePHL30QjnhhvIFSenSfYLhbXmeN4ddWFkBxZOeqXw6uIoB0Jeg27F4at9he8EM9WRLbIBrxsw+TN2q10hCXDMuPhuEK8h5H9Ps6JxjzWdnGi1E0zeDpTCxQVP+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=westcontrol.com; dmarc=pass action=none header.from=westcontrol.com; dkim=pass header.d=westcontrol.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westcontrol.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sf6pdUCST4Lq/xX4Hc98y4VExDbwZpEUINCQTcPJIbQ=; b=AwaQVTXHnOqLJDEqAb8YGZZeGeEqo2h1PwXv5epQzT5dgSSKEVYk6ogNPB/+0Ke89O3oGpOOTbJRH7glTO+QHwGqB3f+aTTUiycRf3a7mvUk8S+GUwUkINHyYRtmG8iqf7M7hkEYovYHcAlidrlMlfb+9Jm5Vzb2gkrIYUnetHGrYhBUDht3kHBEFYJvBuxG0oigM1DVz2zGUBABh5Y7OVhtu/NV6JzMqTSuzHWC3cdhYomVzONCHsMmEbR913q17qJTy3NdEF7xPjQ6WlNujrUB1f0omEYzE99P0CawYCKhYpdgju79eB3SdRf4oebbQZFWHjqgl1GXn10GE3WbVA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=westcontrol.com; Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) by SV0P279MB0250.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6544.24; Tue, 4 Jul 2023 15:55:38 +0000 Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::b999:1d1d:3eb1:b8f1]) by SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::b999:1d1d:3eb1:b8f1%7]) with mapi id 15.20.6544.024; Tue, 4 Jul 2023 15:55:38 +0000 Message-ID: <6fad0dd9-847b-eba0-8f79-6b2a72b68293@westcontrol.com> Date: Tue, 4 Jul 2023 17:55:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: wishlist: support for shorter pointers Content-Language: en-GB To: =?UTF-8?Q?Rafa=c5=82_Pietrak?= , Ian Lance Taylor Cc: "Richard Earnshaw (lists)" , Martin Uecker , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> From: David Brown In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SV0P279CA0033.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:12::20) To SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SV0P279MB0233:EE_|SV0P279MB0250:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c0729aa-081f-46ba-ee73-08db7ca71c54 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cNrgkuPZTr+EajHuTSBPhoFyVWlStVODgJ/Pc5hCxBW9zqM9KD5h9FmRDmjpHe67ZW4+dk+IBieUWXmdUPv+KK9UhWcnlSpdUMqTtpOchHvaD20VGVH/UGkF0Q+mTHAuDO3+AK44rOJK4uHNvjG7gbhrqcgUJnlxyGwu+9ty/iuhq03Uy1oSENT/X1YhhyaEiEJvViU+s209fp3M4eF8gJv+hc0vjzC1W6HW8WArb/oJ4WaY8D8ER1bLYgjH0h4qigLPhunoYjdU6G6jMBI/CRDUtvkcG9pPJl7V1ngVI5kZfXPXohSOjD8TLtkPV65YsDE8PhraEABCze5iZl0+WGBiGcT20sX9dwX4EoSRvKXnCA/oQmUdbz7E0I3k5pjpEqREbyBY9eTA64i4oEXsywg2qqonw1o1GyPoM6JXxCMn/CIkNXYENFGp0h59r5tbxDFiA4rRAUV0QI4q5lMY62KwLX5fm+7GcM1YUvxAkp0z1ZXDNb4IPmP5VJo8KTRxr5krUXzHF4pPFbGxGe5G61xp5eWqF0Rdonqqr0gjnKkEVQcDm3gG2gx9SCAUuYnA5AiPqqvR1DzUHGallywIXEh8xRNth6bZJS2bl1WzNOPxbVqR8Ze1Cob/SPuGSuKIHwKWDvzbY9S5qHvS3psong== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SV0P279MB0233.NORP279.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230028)(4636009)(346002)(136003)(376002)(366004)(39840400004)(396003)(451199021)(26005)(478600001)(31686004)(6506007)(6512007)(86362001)(31696002)(2616005)(186003)(53546011)(54906003)(38100700002)(66946007)(66556008)(4326008)(66476007)(83380400001)(110136005)(6486002)(316002)(5660300002)(8676002)(8936002)(41300700001)(2906002)(36756003)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U0FtdXRtcHpmNlQ3ZWFKTDdYcWhkcnc4VFhtb1NrdEN5WVhDUkltcEU0UnVY?= =?utf-8?B?QytldHBJVWcxa3Zyemk0dzVtOGQ2cCtxYVI5MTlkakw3TFZzWk5aSTJQQ3F3?= =?utf-8?B?TDZnSzNUYlR3ZjlGYnZvRFpWdWlGdnZXU3ZOa1gyTjZGWG4zNnFBMjZCdlYr?= =?utf-8?B?Q21NMmw2VTlVSkd1LzNMaUxacVQxc25XY28xWWo0YXRwTS92KzFKaHVqejNE?= =?utf-8?B?ZFVscmtINlFVR3dFTFVseXQ3Y3pqZ1ZOSmMwRjQrVS9jbkR0UXloRFU0MUFP?= =?utf-8?B?cm9uWDh4bGZOT2RpZDRIMk9TbVVYQ1V2WU9Vb0t3cWFUWjNQRk4zSDZRdmk2?= =?utf-8?B?WHN6NUlOZ1FBUW5yK092QkRFYlpkMTZZT2FjTHdTSGN5cnNhNnFsZDF2Y3RD?= =?utf-8?B?RkJHWkxSa1FiZ01KNE56WVE4aTJ2YjdmTVNpVlBTZ0FIWnlFT01IaGVpbjZp?= =?utf-8?B?bnVndGFBU1E3UmtRYmZscWFJdiswUmtBUFhtZTNwZVNESDNMRVpiclZvb1A1?= =?utf-8?B?ZDNuZytpMHVHUytKbEpFQjM0TVhvSFA3VHIyZnZXY0s4MTV1Slo4OENnUU1m?= =?utf-8?B?bXFRR2pLSTA5NkV5MzhtMHk4T1dCUmprY2NWb3BDMlphMXY3K0pjUHJaVUZv?= =?utf-8?B?NStVUUVXKzJ3a2FIaWdCVFAxUjdINUNoMDF3WjhSZXgyS1lrMFFEVHc4MmtP?= =?utf-8?B?WHFhRFR0eXcwZkMwd253eHZXWHBqaVhBa0E1Y0p0QkhHTzdQcFE3OXV4RHJz?= =?utf-8?B?bVI4V0x1cjFmRFpObUZXWlJmdXVWNm1vaCtuYkFwL2RZWkYwZzFIQXpoOGVM?= =?utf-8?B?U1dMeFRtQkpVOXpCR2pHVDZaYlFDRGQzQ3RYUFlrSmVxLzZYVUM1dktocXhF?= =?utf-8?B?dEpxOWlFVEVlQit0VlhlelRVaElZVG5Pc3pybFE3dnN4S3FvbFJsK0xsZjFB?= =?utf-8?B?NFpGYjVNR21ma3ZsYnloenM1dWJma2RNMkhDY0pUWVV1azhBM0x6NzFhTGFy?= =?utf-8?B?VEM3eWd4dTRFKytZcUVSOE80QmlTNXpPREpEQTlsUFVrSzBqWGVadEwrTm5W?= =?utf-8?B?QnNBc3pHSEhGeUhIazNyR3d5YTA1T2xBc1R0aVZaenNFZDlJSHhYL1J6OEN4?= =?utf-8?B?R0R6cFF3bE9kUkovMGtFMjhGRWdNeFUzdlhyUFhGaVVxQ2VlamN3OFJRMHg0?= =?utf-8?B?bC9Xb3lqcUEwWTBpMU1IZ1l5TE9LK3lSZ3NXclRTa2NmYXloMGxjTUFvQ1ZB?= =?utf-8?B?T1JrcUlhdHFXQmlrRGtTdktGMU9oTExvZXlBVjZOMWowSGpxdU42eU5PNHow?= =?utf-8?B?d3diSWFpWTdsRE0reHlaSXFmZkFvZFUzZGM2UGRtUk5aYkFRL1JaY2ZVUmx1?= =?utf-8?B?VWp6R2JjR1NCTlZTMjN3YXJvL2d6d1V2bjRtTDN0aEhITGZXS1czNjFLRGYr?= =?utf-8?B?ZXZMU1NRd1BKQk5QaHJUbkJVbGgxcm5rVFlTSmgraitTeE1UTkdJUUcwS2RB?= =?utf-8?B?K2ZtMmJlM0ZidnhWdmNvZlV3cllneElCREl2YjUrblp6MW5oY3p5TVE0Zy9v?= =?utf-8?B?QkkyVDBXMEFFSzlja29SNGQwTzlZUVgzWncyaHFRbE9ENzNNSFhtYlRyWTYr?= =?utf-8?B?b0pCRzdvVUNaZ2dDTWIwRVQvUlVzZytyb0pObHI1L3FCbzA4N3k3bGFDd3BX?= =?utf-8?B?T2JsdFFCZDN5Q1pGTGVyZTFnLzRzWWRWbkMwVDc0SnpIMTRmSHhkMDhqQUJO?= =?utf-8?B?NElVSHlXL3hQVFcwL0RVTFhDMWFZalE3eTQ1dm1vc3l6cjlqL0tBb1Jzekoz?= =?utf-8?B?VWxLdTVWckJEOXJYSEdPMmoza2dJZGxnc1RucXV3azg0NGdnUWtaYWx6NDh5?= =?utf-8?B?TGFLVE5mYnBqdnUzVGd5eklyOHBrcWZ1VFlnQ3lxMngrSW92WmJQU2VOUVFk?= =?utf-8?B?RDhSZ1JnN2RxUUpWMSt3OU5hY2RIdHNTZGt6dUVGdFdhWUIvamM4bU5QRmZr?= =?utf-8?B?WkdiWDA2c1NmWEl1b3IwaDl4Z01HNEw0UmRaOS9CMUJWOU80b2ZiUXBRUGVw?= =?utf-8?B?UThzcG1tNnVaMytTZmdxVkpvbHRkZEZUY21ybE1IenVaZXlybHZuSWt4TTkw?= =?utf-8?Q?8jf4v4PkIm2932zkoepp6j78n?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c0729aa-081f-46ba-ee73-08db7ca71c54 X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0233.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2023 15:55:38.1811 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c75fbd3c-42ad-4db0-9cff-972faf83ae45 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UaSl9EQpUh5w6C0ozeqU2Fjdln3PPq3f4LOZcWhDeFhpxXagvYJ2enln+t0AgBO0DTILkl8yJbdgSo6QoJ1o0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SV0P279MB0250 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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: On 04/07/2023 16:46, Rafał Pietrak wrote: > Hi, > > W dniu 4.07.2023 o 14:38, David Brown pisze: > [---------] >> A key difference is that using 32-bit pointers on an x86 is enough >> address space for a large majority of use-cases, while even on the >> smallest small ARM microcontroller, 16-bit is not enough.  (It's not >> even enough to access all memory on larger AVR microcontrollers - the >> only 8-bit device supported by mainline gcc.)  So while 16 bits would >> cover the address space of the RAM on a small ARM microcontroller, it >> would not cover access to code/flash space (including read-only data), >> IO registers, or other areas of memory-mapped memory and peripherals. >> Generic low-level pointers really have to be able to access everything. > > Naturaly 16-bit is "most of the time" not enough to cover the entire > workspace on even the smallest MCU (AVR being the only close to an > exception here), but in my little experience, that is not really > necessary. (Most MSP430 devices, also supported by GCC, are also covered by a 16-bit address space.) > Meaning "generic low-level pointers really have to...", I > don't think so. I really don't. Programs often manipulate quite > "localized" data, and compiler is capable enough to distinguish and keep > separate pointers of different "domains". What makes it currently > impossible is tools (semantic constructs like pragma or named sections) > that would let it happen. > No, generic low-level pointers /do/ have to work with all reasonable address spaces on the device. A generic pointer has to support pointing to modifiable ram, to constant data (flash on small microcontrollers), to IO registers, etc. If you want something that can access a specific, restricted area, then it is a specialised pointer - not a generic one. C has no support for making your own pointer types, but C++ does. >> >> So an equivalent of x32 mode would not work at all.  Really, what you >> want is a 16-bit "small pointer" that is added to 0x20000000 (the base >> address for RAM in small ARM devices, in case anyone following this >> thread is unfamiliar with the details) to get a real data pointer. >> And you'd like these small pointers to have convenient syntax and >> efficient use. > > more or less yes. But "with a twist". A "compiler construct" that would > be (say) sufficient to get the RAM-savings/optimization I'm aiming at > could be "reduced" to the ability to create "medium-size" array of "some > objects" and have them reference each other all WITHIN that "array". > That array was in my earlier emails referred to as segment or section. > So whenever a programmer writes a construct like: > > struct test_s attribute((small-and-funny)) { >     struct test_s attribute((small-and-funny)) *next, *prev, *head; >     struct test_s attribute((small-and-funny)) *user, *group; > } repository[1000]; > struct test_s attribute((small-and-funny)) *master, *trash; > > compiler puts that data into that small array (dedicated section), so no > "generic low-level pointers" referring that data would need to exist > within the program. And if it happens, error is thrown (or > autoconversion happen). > GCC attributes for sections already exist. And again - indices will give you what you need here more efficiently than pointers. All of your pointers can be converted to "repository[i]" format. (And if your repository has no more than 256 entries, 8-bit indices will be sufficient.) It can be efficient to store pointers to the entries in local variables if you are using them a lot, though GCC will do a fair amount of that automatically. >> >> I think a C++ class (or rather, class template) with inline functions >> is the way to go here.  gcc's optimiser will give good code, and the >> C++ class will let you get nice syntax to hide the messy details. > > OK. Thenx for the advice, but going into c++ is a major thing for me and > (at least for  the time being) I'll stay with ordinary "big" pointers in > plain C instead. > >> There is no good way to do this in C.  Named address spaces would be a >> possibility, but require quite a bit of effort and change to the >> compiler to implement, and they don't give you anything that you would >> not get from a C++ class. > > Yes. named address spaces would be great. And for code, too. > It is good to have a wishlist (and you can file a wishlist "bug" in the gcc bugzilla, so that it won't be forgotten). But it is also good to be realistic. Indices will give you what you need in terms of space efficiency, but will be messier in the syntax. A small pointer class will give you efficient code and neat syntax, but require C++. These two solutions will, however, work today. (And they are both target independent.) David >> (That's not quite true - named address spaces can, I believe, also >> influence the section name used for allocation of data defined in >> these spaces, which cannot be done by a C++ class.) > > OK. > > -R