Re: wishlist: support for shorter pointers

["Rafał Pietrak" <embedded@ztk-rp.eu>]

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