Re: wishlist: support for shorter pointers

["Rafał Pietrak" <embedded@ztk-rp.eu>]

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