Re: wishlist: support for shorter pointers

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

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.

but OK. I see your point.

[----------]
> 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?

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

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?

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

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

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, ....
};

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

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.

-R