Hi,
W dniu 5.07.2023 o 13:55, David Brown pisze:
On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:
[--------------]
Wouldn't it be easier and more natural to make the "named spaces" a
synonym to specific linker sections (like section names, or section
name prefix when instead of ".data.array.*" one gets
".mynamespace.array.*")?
You can, of course, write :
#define __smalldata __attribute__((section(".smalldata)))
I'd rather see the "section" attribute extended to allow it to specify a
prefix or suffix (to make subsections) than more named address spaces.
me to. (pun not intended :)
I'm a big fan of only putting things in the compiler if they have to be
there - if a feature can be expressed in code (whether it be C, C++, or
preprocessor macros), then I see that as the best choice.
Fully agree. ... almost fully.
I'd rather say: "I'm a big fun of being able to tell the compiler what I
mean, but leave functionality/algorithms in libs".
And I think this has some resonance to our discussion. I think, that as
of today, C-sources (though the compiler) don't have enough "vocabulary"
to tell the linker "what we mean", and so the ability to "select flash
vs RAM" or "one RAM vs another" is limited. The compiler/linker language
is pretty much limited to resolved/unresolved names and their binding to
linker segments.... like you've pointed above.
[--------]
But let's have look at it. You say, that "names spaces affect
allocation details, which cannot be done with C++". Pls consider:
1. for small embedded devices C++ is not a particularly "seller". We
even turn to assembler occasionally.
I have been writing code for small embedded systems for about 30 years.
I used to write a lot in assembly, but it is very rare now. Almost all
of the assembly I write these days is inline assembly in gcc format -
and a lot of that actually contains no assembly at all, but is for
careful control of dependencies or code re-arrangements. The smallest
device I have ever used was an AVR Tiny with no ram at all - just 2K
flash, a 3-level return stack and its 32 8-bit registers. I programmed
that in C (with gcc).
Well, similar here, although not that intensive (hobby, not profession).
Still, I've never touched the Tiny, as I wasn't able to wrap my head
around those limited resources for anything more then a blinker.
[--------------]
Allocation control is certainly important at times, but it's far from
being as commonly needed as you suggest.
(Dynamic allocation is a different matter, but I don't believe we are
talking about that here.)
yes, not about that.
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?
-R
