Re: wishlist: support for shorter pointers

[David Brown <david@westcontrol.com>]

On 05/07/2023 18:13, Rafał Pietrak via Gcc wrote:
> Hi,
> 
> W dniu 5.07.2023 o 16:45, David Brown pisze:
>> On 05/07/2023 15:29, Rafał Pietrak wrote:
> [---------------]
>>> OK. I don't see a problem here, but I admit that mixing semantics 
>>> often lead to problems.
>>>
>>
>> I think it also allows better generalisation and flexibility if they 
>> are separate.  You might want careful control over where something is 
>> allocated, but the access would be using normal instructions. 
>> Conversely, you might not be bothered about where the data is 
>> allocated, but want control of access (maybe you want interrupts 
>> disabled around accesses to make it atomic).
> 
> that would require compiler to know the "semantics" of such section. I 
> don't think you've listed it below, worth adding. If I understand you 
> correctly, that means the code generated varies depending on target 
> section selected. This is linker "talking" to compiler if I'm not mistaken.
> 

No, it's about the access - not the allocation (or section).  Access 
boils down to a "read" function and a "write" function (or possibly 
several, optimised for different sizes - C11 _Generic can make this 
neater, though C++ handles it better).

> 
> [----------]
>> Let me try to list some things I think might be useful (there may be 
>> some overlap).  I am not giving any particular order here.
>>
>> 1. Adding a prefix to section names rather than replacing them.
> 
> OK. +1
> 
>> 2. Adding a suffix to section names.
> 
> +1
> 
>> 3. Constructing section names at compile time, rather that just using 
>> a string literal.  (String literals can be constructed using the 
>> pre-processor, but that has its limitations.)
> 
> 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 
calls using compile-time constant data.  You can do a great deal more of 
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.

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 
microcontroller with multiple timers, and several sources that all need 
to use timers.  A module that uses timer 1 could define a 
"using_timer_1" symbol for link time (but with no allocation to real 
memory).  Another module might use timer 2 and define "using_timer_2". 
If a third module uses timer 1 again, then you'd get a link-time error 
with two conflicting definitions of "use_timer_1" and you'd know you 
have to change one of the modules.

> 
>> 4. Pragmas to apply section names (or prefixes or suffixes) to a block 
>> of definitions, changing the defaults.
> 
> +1
> 
>> 5. Control of section flags (such as read-only, executable, etc.).  At 
>> the moment, flags are added automatically depending on what you put 
>> into the section (code, data, read-only data).  So if you want to 
>> override these, such as to make a data section in ram that is 
>> executable (for your JIT compiler :-) ), you need something like :
>>
>>      __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.

> 
> 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.


>> 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.

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.)


> 
>> 8. Convenient support for sections that are not allocated space by the 
>> linker in the target memory, but where the contents are still included 
>> in the elf file and map files, where they can be read by other tools. 
>> (This could be used for external analysis tools.)
> 
> Isn't it so, that current debugger sections are just that?

They are, yes.  But it would be useful to have non-debug user sections 
that act in a similar manner - it would not confuse debuggers, and be 
easier for user-written parsers to pull out of the elf or map files.

> 
> 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.

>> 9. Support for getting data from the linker to the code, such as 
>> section sizes and start addresses, without having to manually add the 
>> symbols to the linker file and declare extern symbols in the C or C++ 
>> code.
> 
> +1
> 
>> 10. Support for structs (or C++ classes) where different parts of the 
>> struct are in different sections.  This would mean the struct could 
>> only be statically allocated (no stack allocation - just global or 
>> static), and it would have no accessible address or size (you could 
>> have pointers to fields, but not to the struct objects themselves).  
>> This would let you tie together objects made of multiple parts such as 
>> constant data in flash and writeable data in ram.
> 
> +1
> 
>> 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.)

> 
> 12. I'd supplement the list with a better control on code section names 
> towards something like code namespaces.
> 
> 13. and data sections "growing downwords" like stack does. This is for 
> more flexible planning of memory layouts of micros (limited RAM). One 
> class of sections you put into RAM sequencialy bottom to top, the other 
> category from top to bottom.
> 

Fair enough.