Re: wishlist: support for shorter pointers

[David Brown <david@westcontrol.com>]

On 05/07/2023 14:25, Rafał Pietrak wrote:
> Hi,
> 
> W dniu 5.07.2023 o 13:55, David Brown pisze:
>> On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:
[--------------]

>>> So your current objections to named spaces ... are in fact in favor 
>>> of them. Isn't it so?
>>>
>>
>> Not really, no - I would rather see better ways to handle allocation 
>> and section control than more named address spaces.
> 
> Doesn't it call for "something" that a c-source (through the compiler) 
> can express to the linker programmers' intention?
> 

Yes, I think that is fair to say.  And that "something" should be more 
advanced and flexible than the limited "section" attribute we have 
today.  But I don't think it should be "named address spaces".

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.

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.

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

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.

David