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
