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
