Re: wishlist: support for shorter pointers

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

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.

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

But that's not an issue here.

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

-R