From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sm.strop.com.pl (sm.strop.com.pl [83.17.179.219]) by sourceware.org (Postfix) with ESMTPS id CF9533858408 for ; Wed, 5 Jul 2023 10:20:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF9533858408 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ztk-rp.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ztk-rp.eu Received: from zorro.ztk-rp.eu ([::ffff:10.208.4.171]) (TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by sm.strop.com.pl with ESMTPS; Wed, 05 Jul 2023 12:17:52 +0200 id 000000000129BDF2.0000000064A54350.00000847 Received: from public-gprs569267.centertel.pl ([37.225.86.244]:30665 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qGza2-00Eeuq-7v; Wed, 05 Jul 2023 12:17:51 +0200 Message-ID: <2532f0bb-0a72-8136-42bf-8a7dce7ee904@ztk-rp.eu> Date: Wed, 5 Jul 2023 12:17:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Martin Uecker , David Brown , 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> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 37.225.86.244 X-SA-Exim-Mail-From: embedded@ztk-rp.eu X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 Subject: Re: wishlist: support for shorter pointers X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000) X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu) Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=embedded@ztk-rp.eu; remoteip=::ffff:10.208.4.171; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl; List-Id: Hi W dniu 5.07.2023 o 11:29, Martin Uecker pisze: > Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak: [--------------] >> Then again ... apparently you are guessing the answer. Incidentally, >> that would be my guess, too. And while such "syntax" is not really >> desirable (since such attribution at every declaration of every >> "short >> pointer" variable would significantly obfuscate the sources and a >> thing >> like "#pragma" at the top of a file would do a better job), better >> something then nothing. > > If you want to mix pointers I think it would make the code clearer > if the name space is explicit. But yes, you would need to add > those annotations. > > But maybe one could also consider a pragma that sets a default > name space mode for some region of code in the source. Yes. When there is a pragma to set a default for section of sources, one has to have another pragma, to "restore" compiler default. > >> Then again, should you happen to fall onto an >> actual documentation of syntax to use this feature with, I'd >> appreciate >> you sharing it :) > > Sorry, I thought I shared this before: > > https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html Thenx ... I've only scanned it (so I may be wrong with the following), but the example for AVR target looks ... strange. First example reads: char my_read (const __flash char ** p) { /* p is a pointer to RAM that points to a pointer to flash. The first indirection of p reads that flash pointer from RAM and the second indirection reads a char from this flash address. */ return **p; } now, how come a programmer (or a compiler) can possibly know, that it's not the other way around, meaning: first flash, then RAM) ... I know, that this is probably pointless here, but if the "named spaces" are to be fully generic, then "flash" does not necessarily mean "read only". There may be other "types" of memory, like "Close Coupled Memory", or some embedded device dedicated buffers. So something like: const __flash struct test_s { const __flash struct test_s *m,*n; int a,b,c; }; struct test_s *Z; // struct is already know to be in __flash // no need to repeat that info. Still, the Z is naturally in default namespace - in RAM struct test_s * my_read (struct test_s ** p) { /* P being passed as argument in register is a pointer in RAM, that points to a structure in __flash ... because that's how struct test_s is originally declared */ return *p; } is more readable to me :) and should I need to port the code to other devices I just take out the __flash from one/single place in the sources. Easy and painless. then again. To understand what the code does, I really don't need the __flash notification every time the structures in question appear. > > The draft specification mentioned there can be found herE: > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf OK. Thenx, -R