Re: wishlist: support for shorter pointers

[Martin Uecker <muecker@gwdg.de>]

Am Mittwoch, dem 05.07.2023 um 12:17 +0200 schrieb Rafał Pietrak:
> 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, 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) ... 

It should work exactly like qualifiers:

const __flash char **p;
// pointer to pointer to char in flash

const char * __flash *p; 
// pointers to pointer in flash to pointer in char

const char ** __flash p;
// pointer in flash to pointer in RAM to pointer to char


So the same rules as for 'const'.

> 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. 

Yes. This would be device-specific. Although one could
consider more generic user-defined name spaces as well.
This was discussed before for security boundaries, e.g.
__kernel and __user.


> 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

The name space would not automatically become
part of the struct test_s type similar to how const
would not  become part of it.  But one should be
able to use a typedef:

typedef const __flash struct test_s { } test_s;
 


> 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.

You could do this with a typedef as above or also with a macro:

#ifdef ..
#define my_namespace __flash
##else
#define my_namespace
#endif

So I think portability is not a problem. 

> 
> then again. To understand what the code does, I really don't need the
> __flash notification every time the structures in question appear.

In general, I think ones does: The flash pointers can not 
store pointers to arbitrary objects in ram so one needs 
to keep them appart to avoid mistakes.

If one has types which are only used for objects in flash, one 
can use a typedef and then one does not need the annotation 
every time.


Martin