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
