Hi,
W dniu 5.07.2023 o 19:39, David Brown pisze:
[------------------]
I'm not sure what this means? At compile time, you only have literals,
so what's missing?
The compiler knows a lot more than just literal values at compile time -
lots of things are "compile-time constants" without being literals that
can be used in string literals. That includes the value of static
"const" variables, and the results of calculations or "pure" function
const --> created by a literal.
calls using compile-time constant data. You can do a great deal more of
"compile time constant data" -> literal
this in C++ than in C ("static const int N = 10; int arr[N];" is valid
in C++, but not in C). Calculated section names might be useful for
sections that later need to be sorted.
To be fair, you can construct string literals by the preprocessor that
would cover many cases.
OK. We are talking of convenience syntax that allows for using any
"name" in c-sources as "const-literal" if only its rooted in literals
only. That's useful.
+2. :)
I can also add that generating linker symbols from compile-time
constructed names could be useful, to use (abuse?) the linker to find
issues across different source files. Imagine you have a
+1
microcontroller with multiple timers, and several sources that all need
to use timers. A module that uses timer 1 could define a
[----------------------]
__attribute__((section("jit_buffer,\"ax\"\n@")))
I assume, that adding an attribute should split a particular section
into "an old one" and "the new one with new attribute", right?
You can't have the same section name and multiple flags. But you
sometimes want to have unusual flag combinations, such as executable ram
sections for "run from ram" functions.
section flags reflect "semantic" of the section (ro v.s. rw is different
semantics at that level). So, how do you "merge" RAM (a section called
".data"), one with "!x" flag, and the other with "x" flag?
conflicting flags of sections with the same name have to be taken into
consideration.
One would need to have linker logic (and linker script definitions)
altered, to follow that (other features so far wouldn't require any
changes to linkers, I think).
to add the flags manually, then a newline, then a line comment
character (@ for ARM, but this varies according to target.)
6. Convenient support for non-initialised non-zeroed data sections in
a standardised way, without having to specify sections manually in
the source and linker setup.
What gain and under which circumstances you get with this? I mean, why
enforce keeping uninitialized memory fragment, while that is just a
one shot action at load time?
Very often you have buffers in your programs, which you want to have
statically allocated in ram (so they have a fixed address, perhaps
specially aligned, and so you have a full overview of your memory usage
in your map files), but you don't care about the contents at startup.
Clearing these to 0 is just a waste of processor time.
At startup? Really? Personally I wouldn't care if I waste those cycles.
And having that explicitly "vocalized" in sources, I think it'll just
make them harder to read by a maintainer.
Otherwise, from my personal experience, it may or may not be desirable.
7. Convenient support for sections (or variables) placed at specific
addresses, in a standardised way.
Hmm... Frankly, I'm quite comfortable with current features of linker
script, and I do it like this:
SECTIONS
{
sfr_devices 0x40000000 (NOLOAD): {
. = ALIGN(1K); PROVIDE(TIM2 = .);
. = 0x00400; PROVIDE(TIM3 = .);
. = 0x00800; PROVIDE(TIM4 = .);
}
}
The only problem is that so far I'm not aware of command line options
to "supplement" default linker script with such fragment. Option "-T"
replaces it, which is a nuisance.
These are ugly and hard to maintain in practice - the most common way to
give fixed addresses is to use macros that cast the fixed address to
pointers to volatile objects and structs.
Yes, I know that macros are traditionally used here, but personally I
think using them is just hideous. I'm using the above section
definitions for years and they keep my c-sources nice and clean. And (in
particular with stm32) if I change the target device, I just change the
linker script and don't usually have to change the sources. That's
really nice. It's like efortless porting.
Having said that. I'm opened to suggestion how to get this better - like
having a compiler "talk to linker" about those locations.
But sometimes it is nice to have sections at specific addresses, and it
would be a significant gain for most people if these could be defined
entirely in C (or C++), without editing linker files. Many embedded
toolchains support such features - "int reg @ 0x1234;", or similar
syntax. gcc has an "address" attribute for the AVR, but not as a common
attribute. (It is always annoying when one target has an attribute that
would be useful on other ports, but only exists on the one target.)
Yes, I know that. Then again (personally) I do prefer to be able to tell
the compiler "-mcpu=atmega128" ... and so have it select appropriate
linker script, while NOT changing my sources, then do it the other way
around.
[----------------]
Extrapolating your words: Do you think of sections that you would have
full control on it's content at compilation, and it isn't sufficient
to do it like this:
char private[] __attribute__((section("something"))) = {
0xFF, 0x01, 0x02, ....
};
You also need control of the allocation (or lack thereof). This can be
done using sections with flags and/or linker file setup, but again it
would be good to have a standardised GCC extension for it. It is far
easier for people to use a GCC attribute than to learn about the messy
details of section flags and linker files.
OK. But IMHO, should you move the functionality from linker to GCC, then
all the "mess" just get transferred upstairs. And to know the linker is
a must if you do a bare-metal programming anyway.
Still, standardization is good, good, good. But how to you standardize
something "private" by definition?
[------------]
11. Convenient support for building up tables where the contents are
scattered across different source files, without having to manually
edit the linker files.
do you have an example where that is useful?
You might like to have a code organisation where source files could
define structures for, say, threads. Each of these would need an entry
in a thread table holding priorities, run function pointer, etc. If
this table were built up as a single section where each thread
declaration contributed their part of it, then the global thread table
would be built at link time rather than traditional run time setup. The
advantages include a clear static measure of the number of the number of
threads (see point 9), clear memory usage, and smaller initialisation
code. (Obviously we are talking about statically defined threads here,
not dynamically defined threads.)
I still don' get it. (pt.9 - sizes/locations of sections available to
compiler? relevant to this?)
Then again. I wouldn't aspire to understand everything. If that's
useful, let it be.
But I'd object to call this constructs "a table". A programmer should
have control of how compiler interprets his/her words. "table" has a
very well defined semantics and to have it the way you propose ... it'd
be better to have a different name/syntax for those other objects.
-R
