From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-SV0-obe.outbound.protection.outlook.com (mail-sv0nor01on2041.outbound.protection.outlook.com [40.107.225.41]) by sourceware.org (Postfix) with ESMTPS id 45CCB3858284 for ; Wed, 5 Jul 2023 14:45:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45CCB3858284 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=BMUj8H96WrcERVJ+JeUE5eOfQkR44W2HTIGjSsHEt000OKBataphrTg8I2l1flYHY/DLKznTiIAGsK/wAYzxI/DN3jFGHhh7tjfTFSHZmtvRFp828SSRA/sR4eIOzyrlO23H1QD9blHeAIDywvOhB6c9rndykj/+14P8kCfgC+ZHDMxIhsev9Ak8JfeEfiifMppiBd6JSvwnb2vqASG6ocsEWJPEX+XhVQUloXVHMtYFG9sixNJZ4Q6eM9sT3eTTIrFaDkFs06RRiNcq6IVfWF5828cbdiLp2tyK93v1Kv3Tyi6ke0AWIp5H5hh/tciWfi5g+43IDJy1XmDyYpl2Nw== 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=FIDA1mVjqCI9xmwwPLsVOjxl8CERjD9s2cX02qpycD8=; b=i3n2vHg9/W4l8bMh3+drqoznNn1rt2kn9uyfmICRAxGqjg81dod+KQkdoDnfMjCfV4TtxgcyiqC32+U2kNkbjtatytO/WVRsAoq6XdILT4C0y78+huWcsdKsFDxPDd9w1wsFzUJ8zJoUaZ/Wb8bHibV7Frwn+qjyjo7a+MFDHex3Zot7xdPqjoHXDIpiO26h9Fh2nT+pab9cKCGGnLH7kO55sT11FJz3qnu8zcgGGmZHfBJdxPAWG38or/ZnIZrKGhADiFByvg6adc4W79Xmlwi0Ca68u8Jpx+f4cefO4haroY3+bI9iP8w3zGnZImuJ/TAtdq7viX/gPYcshp0swQ== 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=FIDA1mVjqCI9xmwwPLsVOjxl8CERjD9s2cX02qpycD8=; b=qTrZ4uSqgJazL/amnf9zPbPhj68mnBAuXto+ipKc/ncePjzX0Al2cuQRmAjzMLrSZBBW/ueWDCM/DA8wVfrA9VUZp864+SNgnmsgi149sMNWoV0yhvPiHkijRd9jyyTN3RPuNXohU15CNsqY+Ul2x+dkcve8fanv0zg+FIbkW7MXWJqqiSCFXLepZpljv3BY4CFZb7QbKksCeyIe318Bw2B7zZkk0siwYXm2pJROVEfcJczjZbbv4jz1YvKbItNybeaYKcLpgHuvNHJAphLBlAYcJqBc3pW0/2UZfIhCR3atef9/2gkP5mnO+jHSAPBFi8VBAKniM6u9siPglrsiJg== 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 OL1P279MB0849.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:4a::13) 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 14:45:21 +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 14:45:21 +0000 Message-ID: Date: Wed, 5 Jul 2023 16:45:20 +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?= , Martin Uecker , Ian Lance Taylor Cc: "Richard Earnshaw (lists)" , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <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> <45292545-b4e1-a2c8-38d0-a7773f309ca5@ztk-rp.eu> <25afc1cb-3a62-135d-3206-2d9eb6216944@westcontrol.com> <701a38b8-9e90-36ce-9357-8b648f04a4d8@ztk-rp.eu> <540fa64b-0263-ba43-2c2a-2973ab376826@ztk-rp.eu> From: David Brown In-Reply-To: <540fa64b-0263-ba43-2c2a-2973ab376826@ztk-rp.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SV0P279CA0031.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:12::18) To SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SV0P279MB0233:EE_|OL1P279MB0849:EE_ X-MS-Office365-Filtering-Correlation-Id: a710613b-c12a-4a99-fb88-08db7d667593 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: o3PFU8Uw/NCPXhdc0VUwCOz7VyiFpHfWTg7Tnk2DqQGDEigb6cnml8RT9Fc35bzNtWiXhCXs5dqEEbZVT4V5B5xgHDlv1gwKZcyonywk4NeJw1WgS1jjUOWh5vW84j62A/tGY7PLuUFgVc3LxMmSXzbrkdvXQ6p2sgsiukXjkzEgcoa02hL203IybyHM9ofz7SvdMkjBD/+PnqV7ByiLoas07yIddue+kR1cOrI/B0HgKDyGdhg7u0VBlvOgaSXIf7lKNuEyf+Todkj1G6N+ACxugf6kqAgCAnQgz732Nx+hNpJvdddzl+b4sn/ex26eE2tMjL4VOq0vSvBiIDXCwD6TXkOPJLR2O9gWNyxym8K+DIREH79wfTp6m3k0T3jcVgAMHs0H+FT6vIPRQ31AT16L8MjOAmn2KsJt7JTwJ8ss6PXhiG/4U4cWjZO+Cc+UeTvkD68j0YVCpZAkST4Z8SZNhM1PNg3XmBYn+Dz+i1ZecssCCWOCJxkrf3TjCyEWPihPAgMrzewS7aymQ88k2gOHiocGIaNE+uokxPtSJdw3usnCbVbhAHqMDUw/pqbgtkpcQUdtOZ3pUIaabv9aiRNWV2uoNuidoM94VOnb6/flQXJVm21wRgOQ3h8iCF959MOLvjKGT+I7u9aZOJIgdxsuM/06Xh3V1CMB/avVLRc= 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)(39840400004)(376002)(396003)(366004)(136003)(451199021)(5660300002)(8936002)(8676002)(41300700001)(316002)(2906002)(83380400001)(31686004)(6506007)(2616005)(4326008)(66476007)(66946007)(38100700002)(66556008)(86362001)(186003)(53546011)(26005)(54906003)(110136005)(478600001)(6486002)(31696002)(36756003)(6512007)(87944012)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1ltc3JjV3VCdlcveTEwL2tTZFVJUkFyZm9LeWV5dzcycEVkck1Id003L3A2?= =?utf-8?B?U1RXOFZrQTRLRDE0UkR0WHZEMFFVaXZ5bGVEL3oyR2Rza0hNandRNWsrZTB1?= =?utf-8?B?RENtaXpDTzhKbUYwQWxTdXRVcCticndueHk4Wm5yNisyQ3BJQmV5QXdoemtk?= =?utf-8?B?b0NBekw4c3QwaVdwelg0SVdtMG9hRGVNV1NrbmIxTEpMWUpMaEtUcXNzZHNr?= =?utf-8?B?NFBOOU1VNGVqWVNIbnYrdFhRUjVFWHRYNGhuNGhOR2JiaVJHaFNaS29ib0lv?= =?utf-8?B?bG1RNDM2b3dadUVHNXhiRDh4MGlDSGs2NEl4WXFjcm9tL2Z1RncvK0h3UTJn?= =?utf-8?B?YVNiUDFsVnJUYkc1VUhVeGdNanU4RCtKS3hnTmhVWEJjZGVUYXY4bjhLaVUv?= =?utf-8?B?N2MvY3JPRm1WRXptUkFKY3NmM0g1YlF3ek5jS1VxUCt1RmhVMGtQa2hjQmFM?= =?utf-8?B?Zk5MT20wSDNQTGtuZmgwNFNPVGxlVTg0QUx5NG45N1UzSTBWRGR5S2N2VEw4?= =?utf-8?B?K2RTcWJwUGpQd2hQNlNIVElOdG1TV0wrd2xzYVhPbDczakVNcGI2OXJ1RmZG?= =?utf-8?B?aFN6cUdqMFNXa3VZUzFmQTN4WGRva3RUL3g5Wm5WZGsyZUlrbWZuN1BDa3Vz?= =?utf-8?B?L3E5cndJemI0d1oxNzB5OElxZk9HK1RGa0dkWVJsZDlHK0krWkxLUlA0a0xV?= =?utf-8?B?TXk3RGFkTXNoN0VZejlxanNHRmlJV2hSUTVlNjI0M1A4Z3V0aWthQWNTcG9B?= =?utf-8?B?THRzR1ZlQ2h4Wi80L1Z4T2xSbXErNDNwakp6S3JnaDVQeGNVZmNsdGdmdC9V?= =?utf-8?B?NjZTY0pDRnZjNDRISXMyRWJQWXNOdkVGUWRWcXJKcEdsbGxKNmFUUFNuYnVa?= =?utf-8?B?c0RERzN5RnBSazJUMkRiRnUxKzF5OUc3U250TWh2cFZDTG5iMVBvTmZyYXVh?= =?utf-8?B?K05hUWl6V0JPc2krbGRBRGN1RlBvU1dqSlh1dGI5M0hsRVplMlpWcjdaMUp2?= =?utf-8?B?SEJ6S1I2aEdIVTZOQThGOENVSXo4c3FLZ3lubDBFN0pMdFk0ZzdvTGloalhU?= =?utf-8?B?dFRsNGwwdjlyK004d0ZjQ002eXlXU1drbzNBNkxBNkFxbmNXYlp6K3N0aUp6?= =?utf-8?B?RThuL1ZNTVk4V1JoTlQyelVHQW15VEEzbktEZkJzdDNqMFlNdyszNE80alJS?= =?utf-8?B?M0hieTUvODlhV2hZOEoxWjBqVkRwVlJKeGV1ZzQxQ1dVckowUWE3bGIzL2FW?= =?utf-8?B?L0NKU200QU5td1FHdUEwVXRmcUlRVnRqUDlwb1BVTFVHaW5MN0hjZWJ0SWl4?= =?utf-8?B?ZHBpdHBOdC9qRlJqbGVWYTR5azVBblJlYlYvNXdaazAvalo5a0Q2Z1JkNk9V?= =?utf-8?B?MzVNQ09wT0xmRjh2dUlVQ25vNk9nWEFwbjJOSTlHTGk3cnNoS0sxeEZmcHpD?= =?utf-8?B?UjcxY3lFL1hMUE1IWG00c3NEVXhsbTBQRUprMmdFK1N4MlZyVy9QdmpNTCto?= =?utf-8?B?emI2WGw1bStPNG9zZlpPS3VSZGlGaXRSTGtzNGJsTitUbmhEazJDaWpuUU10?= =?utf-8?B?dHZZYWs1bXUrVlNibC95M3NvdXIzYTRlVkRCSVJCaTd5ZFFNQzlZb3NHeVUz?= =?utf-8?B?bGQ5WmdaZXlHWVYzUXluQlZoWVR0azREYjd6WUUxQVdOZzZ0ZjhsVGhDNk5q?= =?utf-8?B?Mm1kSEhNU0lET2ZGSUN2ek9UNVZ3SmhBTGpsVGxtTVVjL0M2cVExbE9mQ3Vy?= =?utf-8?B?QndzYjlNWVVyV3hXVis5Y3E4VVU5UENzak10TEJkNHdpbk5vUXROcEtmVCtR?= =?utf-8?B?UWUyNWRwQldkS2gvVTVwaDhOU2lYbjhaSUZwb1RWKzBtOFUxYVgvd0FHdk1x?= =?utf-8?B?cFhVdndXb1ppd1ZMUXBMUGQ0Y3grRXEvZ0ZCRlZ3bmxpSE1GMG51cmpITUI4?= =?utf-8?B?OWs0RkIrUklWeFdobHhBK09HUXJjckNKcml0dUFWYndrS3V4cDQ4L05xVHRG?= =?utf-8?B?YklEWStWMFNpNnJ2dk44RDdNdnUwWU9Mc2pDeFRxa2NOOFQ5U2RiQXBUR21o?= =?utf-8?B?MEtqOGI3eGdoTU5JbVBPZGpQSGovTWtNeE1wOFRLTnJVaW54bEZJY1A4SW5v?= =?utf-8?Q?58TK2un8kVHFtyRkbdFpQsNiI?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: a710613b-c12a-4a99-fb88-08db7d667593 X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0233.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2023 14:45:21.7066 (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: 7216NOhLP3z315ycDXB6xrAXVSKtrYhrexXt1jCuFpias+5rozIB7bEg8N7xLVAj5nYRzBTEckVsl6CdC7Cxeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OL1P279MB0849 X-Spam-Status: No, score=-2.5 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 15:29, Rafał Pietrak wrote: > Hi, > > > W dniu 5.07.2023 o 14:57, David Brown pisze: > [------------] >> >> My objection to named address spaces stem from two points: >> >> 1. They are compiler implementations, not user code (or library code), >> which means development is inevitably much slower and less flexible. >> >> 2. They mix two concepts that are actually quite separate - how >> objects are allocated, and how they are accessed. > > OK. I don't see a problem here, but I admit that mixing semantics often > lead to problems. > I think it also allows better generalisation and flexibility if they are separate. You might want careful control over where something is allocated, but the access would be using normal instructions. Conversely, you might not be bothered about where the data is allocated, but want control of access (maybe you want interrupts disabled around accesses to make it atomic). >> Access to different types of object in different sorts of memory can >> be done today.  In C, you can use inline functions or macros.  For >> target-specific stuff you can use inline assembly, and GCC might have >> builtins for some target-specific features.  In C++, you can also wrap >> things in classes if that makes more sense. > > Personally, I'd avoid inline assembly whenever possible. It does a very > good job of obfuscating programmers' intentions. From my experience, I'd > rather put the entire functions into assembler if compiler makes obstacles. > I'd rather keep the assembly to a minimum, and let the compiler do what it is good at - such as register allocation. That means extended syntax inline assembly (but typically wrapped inside a small inline function). > But that's not an issue here. Agreed. > >> Allocation is currently controlled by "section" attributes.  This is >> where we I believe GCC could do better, and give the user more >> control. (It may be possible to develop a compiler-independent syntax >> here that could become part of future C and C++ standards, but I think >> it will unavoidably be heavily implementation dependent.) > > I agree. > >> >> All we really need is a way to combine these with types to improve >> user convenience and reduce the risk of mistakes.  And I believe that >> allowing allocation control attributes to be attached to types would >> give us that in GCC.  Then it would all be user code - typedefs, >> macros, functions, classes, whatever suits. > > OK. Sounds good. > > Naturally I have my "wishlist": the "small pointers" segment/attribute :) > > But how (and to what extend) would you do that? I mean, the convenient > syntax is desirable, but IMHO at this point there is also a question of > semantics: what exactly compiler is supposed to tell linker? I think it > would be good to list here the use scenarios that we now of. Scenarios > that would benefit from compiler communicating to linker more then > names@sections. (even if such list wouldn't evolve into any > implementation effort at this point I think that would nicely conclude > this thread.) > Let me try to list some things I think might be useful (there may be some overlap). I am not giving any particular order here. 1. Adding a prefix to section names rather than replacing them. 2. Adding a suffix to section names. 3. Constructing section names at compile time, rather that just using a string literal. (String literals can be constructed using the pre-processor, but that has its limitations.) 4. Pragmas to apply section names (or prefixes or suffixes) to a block of definitions, changing the defaults. 5. Control of section flags (such as read-only, executable, etc.). At the moment, flags are added automatically depending on what you put into the section (code, data, read-only data). So if you want to override these, such as to make a data section in ram that is executable (for your JIT compiler :-) ), you need something like : __attribute__((section("jit_buffer,\"ax\"\n@"))) to add the flags manually, then a newline, then a line comment character (@ for ARM, but this varies according to target.) 6. Convenient support for non-initialised non-zeroed data sections in a standardised way, without having to specify sections manually in the source and linker setup. 7. Convenient support for sections (or variables) placed at specific addresses, in a standardised way. 8. Convenient support for sections that are not allocated space by the linker in the target memory, but where the contents are still included in the elf file and map files, where they can be read by other tools. (This could be used for external analysis tools.) 9. Support for getting data from the linker to the code, such as section sizes and start addresses, without having to manually add the symbols to the linker file and declare extern symbols in the C or C++ code. 10. Support for structs (or C++ classes) where different parts of the struct are in different sections. This would mean the struct could only be statically allocated (no stack allocation - just global or static), and it would have no accessible address or size (you could have pointers to fields, but not to the struct objects themselves). This would let you tie together objects made of multiple parts such as constant data in flash and writeable data in ram. 11. Convenient support for building up tables where the contents are scattered across different source files, without having to manually edit the linker files. Much of this can be done today, but involves manual (and therefore error-prone) effort and inconvenience.