From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-SV0-obe.outbound.protection.outlook.com (mail-sv0nor01on2051.outbound.protection.outlook.com [40.107.225.51]) by sourceware.org (Postfix) with ESMTPS id 5A5523858423 for ; Wed, 5 Jul 2023 11:34:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A5523858423 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=Wmy7gEnKgB9NuCeSBmgCL7Kr0EaAsIpSFWqXcp7p/KvV3Uhrj+6JSSD4IQLCasHYY0cr6kxH8hHYO0EOwkBDiqPsxklTX91w3K9ULHHKxzslG3jUbLxuFi4ms4/rTm52zvl5hknOuC1hzfw9XczrHMwFWDUQYkuL/++hG1WCEIeNXfDsI+zTjmFYzdxlK10W5BukoQnHT5q2i1DV9xAt0Atfim6oXHlXZC/Bg07RP3wY0p19hHlzMHAybrAR/Gq4Mu0+NSyqzNPF2qHlmVXbt1IcdLfPQITkrVKa/iCFZ9vGIUYEGHLZW8JT+FA0bvelvlrnG2UPrr9FZzCLXy0xvA== 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=qbyULPQB7DtZHnNyui7l2h88+L/1Mte1MDGusrXZLek=; b=KYxyLFe7EqYzN+RlE69KWqssmhMICZcICNgpoOh2RArVIYOfEHPx96N9x15w5cO3jaCFoaITk8ljQ8PHAZhKIFs1Lv4pSErmJ+dsPnJKxYc7AZVIkSaZe6g8WDQjEPOYSm4e6YNcey8iJmJf470v6GMWH4Pi6umCRVE1MvcV8fueuBlfNc226IDrg2kyVzyyUPrA5xr1ZC356CL7JUmYh6M1T8IgQPAROOuXtaGdqikjuc8jmn3Pr1GPZB81June600IE8/ViWOnmZRGRN4GzlYBPB7q/Hlk1qsmGMHMQCLXcMViPZCBBbphXnaafIZ4pk1J9I2qBwq3Xg+LG6h8Rw== 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=qbyULPQB7DtZHnNyui7l2h88+L/1Mte1MDGusrXZLek=; b=r9bUS8YpOD5wauVrP4u/kwGocbzWSDESKsd13dN2SK4udZnD2RoeGqqAc/qMt6v57qTwyXnDHqQ/mlVxUmv2SL5g/uAAuJRjqh4myv2Zr0e9l768Ax4ikuFZJjOooXecawDWgvpz++AXOwDh6sdTO0GF222yHiVfSdFre0QlcxrBgjbmZQMgj+6OkFFEmR0ZAfXUt1F8bI3lDeS++mqqeGY7RFQBnkLJ3P7q7tAfTMYCAaq1OkW6BHf6pr2NnGG4yOywvm9XlWqR3suOZgeQ/MvolD/0JZAdQdGCHwCkTOj8/jbjGXP1zJjYsXWEiwbVYHn+KkdR3WrqK57DLUVyFA== 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 SVZP279MB0784.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:26::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6565.17; Wed, 5 Jul 2023 11:34:05 +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.6565.016; Wed, 5 Jul 2023 11:34:05 +0000 Message-ID: <90b69927-65ac-98b4-c709-762b395018a4@westcontrol.com> Date: Wed, 5 Jul 2023 13:34:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: wishlist: support for shorter pointers Content-Language: en-GB To: Martin Uecker , =?UTF-8?Q?Rafa=c5=82_Pietrak?= , Ian Lance Taylor Cc: "Richard Earnshaw (lists)" , "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> <6c881d3fc76d112d52ec668d05b68394ae792f30.camel@gwdg.de> <1eeef918-80d0-12a3-e7e9-5a75b25fb769@ztk-rp.eu> <8825a11f-e462-8d97-3cdf-a5015250f3c1@westcontrol.com> <1be0adf325de7bf6cdb9c5caa7be2b41e5734786.camel@gwdg.de> From: David Brown In-Reply-To: <1be0adf325de7bf6cdb9c5caa7be2b41e5734786.camel@gwdg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SV0P279CA0011.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:11::16) To SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SV0P279MB0233:EE_|SVZP279MB0784:EE_ X-MS-Office365-Filtering-Correlation-Id: cc35c243-2358-423e-c347-08db7d4bbd56 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OF6gwDMgIownw+PIFwGU9nqzzGbmI4RRHXYNIECq0OnZS4hTNR7xcjZ0tdljI3zwCA9AyTK731sm67yv52jEyR6BHnWYLtjnNg2o76rlmVsbk/EA6vIupj0xInkneMSl6XC0csQA2fg1G3s2kKE8Z14zQnBqevj/L0+34uP8Mm17WjIov0G1JY15g3JPzeFjJCi6zsZt1ywIEcP1Dj+p5MYyFOV3L5in7PAJQu2g6s0/wuFWNHAag1xQTVLuQ4vEcm7VsVVODYyN0XXWRf7IAWN+hq/JvaRUIhmY0MMIyJNNMq7nM4FnrATkv9H3/DvJ0ytR++pfVEF3jHnKBta+oo0Dl191gJyF5nXeNsUVAmKbJ0mhkGF0onq5RDQwLWcPxsQjuGFHbSUQJ31lE6xQ2GNaYkbD28rHnd71lefNQ2VZF64wKA94B1D+UkHCPAR3Kl/+dyLptKF3Wv4PsnovkdjDlVrGiSGpyC9hF3AJMblrqnCFll37/k2PI64m1dlYxSBYx0JDu8cFF6cHGhaGIw+JE9dkAUh8Xv0Pe/we4itVXkEf9AcGttZDTwa9nT83DFdK211sNCQnHpiIgETKpO0i/I2hyco6tq0HP79ef5boIUdiWcnx9yiaOb8x07wXw4A6x4RQHZ7UzWLdpZ5mMQ== 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)(39840400004)(376002)(366004)(396003)(346002)(136003)(451199021)(31686004)(6486002)(478600001)(110136005)(54906003)(83380400001)(2616005)(36756003)(86362001)(31696002)(2906002)(66946007)(53546011)(186003)(6506007)(26005)(6512007)(38100700002)(66556008)(316002)(4326008)(41300700001)(66476007)(8936002)(8676002)(5660300002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Mytoa1hsNENhVGNxKytQZTF2MFhQT01PTUxlUUF0aitZMlZUR3poTk5JcWdT?= =?utf-8?B?U1NnVjlkSUpiUVBqZmFqcFd5U2lDMkVoRVl2SjUrR1pxblh6cVJwZEdDazNk?= =?utf-8?B?ay9KY2dsZThkLzZld3N0MGx4bTFtdU5iQ2d1QkN3cTVIbkhubXZDb3F4SExK?= =?utf-8?B?aEFOVVR0TTFZSGZ3bVpJK1F2VTJHWDlhVFlkRzhucGNVMU4venRWUVpSYi90?= =?utf-8?B?TE05emlLdGs4Y3AyOWNBUTlXbm0vQ3huQUVISTQ1R0U4dzVnWE8vU1d2bEQr?= =?utf-8?B?cXhSaytyVnpUaXprVnVwOVJiSzJqTGVIZ1RPemxoRWg4QS9MZEQrVDU5bzFq?= =?utf-8?B?dUlWaS9SY3ZrSHBXTmNUNllpNW52RWEvK2wvZHVJb0FhcDZ1bzV3a2lOclF6?= =?utf-8?B?ZTJoTUg5bFg0L1VLVTdPbkh4dHo1UkxuZ28xRDYxZGRpUVZnZm1DZGtJR3BP?= =?utf-8?B?US8wODYyN1JGdXkrTXNkc01ibDBUQWt0QXVYMm5oRWNpSDdleVJwcXFqeDNZ?= =?utf-8?B?dmZWcTkva3NyNjBVLzFiNmgxb3RvK0loTXZoOEpMRW5qblI0dm40MTRjWFdX?= =?utf-8?B?aG54dTNkSEM4eVRMY0ZYbUsvRm04bTNmWHErVnozY3QwVUU5TFFCMldldzV4?= =?utf-8?B?TUcxZDJRdElVeWJWcE9qd01xS01NUmw4Nzg2emR3NTg3N0paMXVKV2kyODM0?= =?utf-8?B?d2dVOHlKc0FYcUhmZCtLVlEwU3RnWHRlWllhV1VnTmhTbXBSalZkQ2xxV2J6?= =?utf-8?B?U0VXTmVSTHg1QVB3OFI1WjFBV3VDdmlYbmlxbGkwSnV4b3VMM3k5cmdPYWJB?= =?utf-8?B?ZSt3aVc5RDM0MEZ4bDlPSDB2cFJGTlJmRzFUb0lTaURGQ2VlTmI3and1N2Zp?= =?utf-8?B?WGYzYTN2TVl0bTBMNndiN0hMbWFvVFBRTEExNnh0WDUyYkJMQll0R09PLzkz?= =?utf-8?B?czJIU3cxc3FqNjdnQ1l4UUxsWkk1bUdlNDhoVnZxVXk3ckZUQkVZQUVSaGo1?= =?utf-8?B?eSs1Qm5UZ0pWVjRKTjkreHJVWW9OZ2hmVHVHUm5PUjk0cVlqQnQrWmRmWkN2?= =?utf-8?B?ankxOXB6ZE1yUXVZQ1ZUUHMvUUFmODBXME54QmNCK2t0MGM1amF3NERrV2Z2?= =?utf-8?B?Z1ljRFBYWTdjOHFrZGNyK0RGQnRLK0JEYmxaOE5ZdGh6ZnRUazhwRk5vYVdD?= =?utf-8?B?dVk1L09mTHBSak0xR2lNS1hqVy9TdG1TSEVBcFRwb0NOd0dXVm9hRGZ5WFN6?= =?utf-8?B?eEpwK08vM3lMdThHRUZJbDJmY0g5UmE5Q2lvNVk5ZU0yUVpzWVpUd1lrMWlk?= =?utf-8?B?MXo5QVEvY1lRZ2gxS0NSNjRXN1d2WTdtb25VS2IrcHdUTmlRY2Z4WGhkS3g4?= =?utf-8?B?aUlZYzJLVzlNdE9MUmw4d1hONjU5aXpJZDZjYkJ2OGR6UFNteWRBdWoweEdO?= =?utf-8?B?aGRKaWFVc2d6SVF4eEZVTnU4WnhKM0wxb0ZBZ0wvZ2pTL1h3ckR4eUhBNmFC?= =?utf-8?B?YmgrTmJOa3hFVmtFeE9QWVFjRytlMzBiWGMrUi9ZMWs1TkNPK1NwYURzRlUy?= =?utf-8?B?NHBKZjNnMzZlVyt6ODNuZ2c3VWplUUpTZ0JlUkhrazU3dVJVRnZ0MUhkRnc4?= =?utf-8?B?NTdwS3FWMGdPVXl4dzY3ekdxSURsbzFSWFIxcVViWitZd2NxOTlJWlE3QTR5?= =?utf-8?B?VktGN2dURHp4cko0VExycDVNc3VpSXNaa3AreFBXRHZveUJsVDNkQnAxWG9m?= =?utf-8?B?TWxYNUVpRnB4QnYvTHB2SlJMZVg5My9QeW9zVjF0bUw3TGtTVi93cnJ1Z3JL?= =?utf-8?B?VEJ1QlVuOCtEaTB5aUFiOTM5ZVYxNk5ZeVR4bEJwTGdqSThyNHpSUmlPckpL?= =?utf-8?B?bmZMalNCWjhRVmdjTGJDNk1JV1VwdW5qOHhkS3RDZGlLWnl6dWQrcCtIeFRR?= =?utf-8?B?emtVMnFvVTZ4cWVOTEdRVWlFejh2RkxaOHdsT01kenEvUFVTTGJpZUN3UTVK?= =?utf-8?B?Mk9HWkVQQzI2UWRxMENadjVTZHhVSU9DUmN1dVZ5NlJiTWlPa1pDaWRWTWx0?= =?utf-8?B?b05DTm1OOUQ5ZFZObEFEdXJhQWdjZGZINWtJdVVBNHZZb1k0dGRNUlU3WnEr?= =?utf-8?Q?eYUsUcAuIweiyHBVPc/uo5gBG?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc35c243-2358-423e-c347-08db7d4bbd56 X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0233.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2023 11:34:05.6744 (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: ewNqD5FqOS+VsgF4uR+qtGy0cr5FnUQGY6EEto8sz8iqLPUGkg7op6WoAvVvdG/gH9oSMw+n8P7ZEHcf8x+5qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SVZP279MB0784 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 05/07/2023 11:25, Martin Uecker wrote: > Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown: >> On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: > > ... >> >> In my personal opinion (which you are all free to disregard), named >> address spaces were an interesting idea that failed.  I was >> enthusiastic >> about a number of the extensions in TR 18307 "C Extensions to support >> embedded processors" when the paper was first published.  As I >> learned >> more, however, I saw it was a dead-end.  The features are too >> under-specified to be useful or portable, gave very little of use to >> embedded programmers, and fit badly with C.  It was an attempt to >> standardise and generalise some of the mess of different extensions >> that >> proprietary toolchain developers had for a variety of 8-bit CISC >> microcontrollers that could not use standard C very effectively.  But >> it >> was all too little, too late - and AFAIK none of these proprietary >> toolchains support it.  GCC supports some of the features to some >> extent >> - a few named address spaces on a few devices, for "gnuc" only (not >> standard C, and not C++), and has some fixed point support for some >> targets (with inefficient generated code - it appears to be little >> more >> than an initial "proof of concept" implementation). >> >> I do not think named address spaces have a future - in GCC or >> anywhere >> else.  The only real use of them at the moment is for the AVR for >> accessing data in flash, and even then it is of limited success since >> it >> does not work in C++. > > Can you explain a little bit why you think it is a dead-end?  It > seems an elegant solution to a range of problems to me. Named address spaces are not standardised in C, and I do not expect they ever will be. The TR18307 document is not anywhere close to being of a quality that could be integrated with the C standards, even as optional features, and much of it makes no sense in practice (I have never heard of the IO stuff being implemented or used). The few compilers that implement any of it do so in different ways - the "__flash" address space in AVR GCC is slightly different from the same extension in IAR's AVR compiler. For existing compilers, there is a strong inconsistency as to whether such things are "named address spaces", "extension keywords", "type qualifiers", "attributes", or other terms, all with subtly (or not so subtly) different effects on how they are used, what restrictions exist, conversions between types, and how errors can be diagnosed. Sometimes these features are considered part of the data type, sometimes of pointer types, sometimes they are just about data placement. Since every compiler targeting these small awkward microcontrollers has a different idea of what something like "const __flash int x = 123;" means, and has been implementing their own ideas for a decade or two before TR18307 ever proposed "named address spaces", the TR hasn't a hope of being a real standard. Named address spaces are not implemented at all, anywhere (AFAIK), for C++. (Some embedded toolchains have limited support for C++ on such microcontrollers, but these are again not really named address spaces.) Since C++ usage is heavily increasing in the small embedded system world, this is important. (GCC has much of the honour for that - as ARM took a bigger share of the market and GCC for ARM improved, the toolchain market was no longer at the mercy of big commercial vendors who charged absurd amounts for their C++ toolchains.) A feature which is only for C, and not supported by C++, is almost guaranteed to be dead-end. And of course the type of processor for which named address spaces or other related extensions are essential, are a dying breed. The AVR is probably the only one with a significant future. Part of the appeal of ARM in the embedded world is it frees you from the pains of target-specific coding with some of your data in "near" memory, some in "extended" memory, some in "flash" address spaces or "IO" address spaces. It all works with standard C or C++. The same applies to challengers like RISC-V, MIPS, PPC, and any other core - you have a single flat address space for normal data. > > I have no idea how much the GCC features are actually used, > but other compilers for  embedded systems such as SDCC also > support named address spaces. > And the targets supported by SDCC are also dead-end devices - there is not a single one of them that I would consider for a new project. These microcontrollers are now used almost exclusively for legacy projects - updates to existing hardware or software, and rely on compatibility with existing C extensions (whether they are called "named address spaces", "extension keywords", or anything else). Now, there are things that I would like to be able to write in my code that could appear to be candidates for some kind of named address space. For example, I might want data that is placed in an external eeprom - it could be nice to be able to define, declare, read and write it like normal data in the code. But key to this would be the ability to define the way this works in /user/ code - named address spaces require changing the toolchain, which is out of the question in almost all use-cases. And it would spoil one of C's key advantages over alternative languages - to a fair extent (though not as completely as many people believe), you can guess what is happening from the code. You assume that "x = eeprom_var;" is small and efficient, while "x = read_eeprom(eeprom_var)" might take significant time to execute. People don't like hidden things in their C code. It would be conceivable for GCC to add extensions that could be used to define your own named address spaces in user code. But doing so would require a lot of syntax and features that already exist in C++. I would rather see better ways of controlling placement of data added to the compiler. In another post, I suggested allowing variable attributes - such as "section" - to be attached to types. I'd also like to see a way to specify the section name by compile-time evaluated code, not just a string literal. I'd like to be able to give sub-sections, and section flags in a convenient way. And - perhaps most importantly - I'd like to be able to use #pragma's to give sections for code or data for a block of code and data at a time, rather than having to specify it individually on each function. (That could perhaps also be done by allowing section attributes on namespaces in C++.) David