Re: wishlist: support for shorter pointers

[David Brown <david@westcontrol.com>]

On 05/07/2023 15:29, Rafał Pietrak wrote:
> Hi,
> 
> 
> W dniu 5.07.2023 o 14:57, David Brown pisze:
> [------------]
>>
>> My objection to named address spaces stem from two points:
>>
>> 1. They are compiler implementations, not user code (or library code), 
>> which means development is inevitably much slower and less flexible.
>>
>> 2. They mix two concepts that are actually quite separate - how 
>> objects are allocated, and how they are accessed.
> 
> 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).

>> Access to different types of object in different sorts of memory can 
>> be done today.  In C, you can use inline functions or macros.  For 
>> target-specific stuff you can use inline assembly, and GCC might have 
>> builtins for some target-specific features.  In C++, you can also wrap 
>> things in classes if that makes more sense.
> 
> Personally, I'd avoid inline assembly whenever possible. It does a very 
> good job of obfuscating programmers' intentions. From my experience, I'd 
> rather put the entire functions into assembler if compiler makes obstacles.
> 

I'd rather keep the assembly to a minimum, and let the compiler do what 
it is good at - such as register allocation.  That means extended syntax 
inline assembly (but typically wrapped inside a small inline function).

> But that's not an issue here.

Agreed.

> 
>> Allocation is currently controlled by "section" attributes.  This is 
>> where we I believe GCC could do better, and give the user more 
>> control. (It may be possible to develop a compiler-independent syntax 
>> here that could become part of future C and C++ standards, but I think 
>> it will unavoidably be heavily implementation dependent.)
> 
> I agree.
> 
>>
>> All we really need is a way to combine these with types to improve 
>> user convenience and reduce the risk of mistakes.  And I believe that 
>> allowing allocation control attributes to be attached to types would 
>> give us that in GCC.  Then it would all be user code - typedefs, 
>> macros, functions, classes, whatever suits.
> 
> OK. Sounds good.
> 
> Naturally I have my "wishlist": the "small pointers" segment/attribute :)
> 
> But how (and to what extend) would you do that? I mean, the convenient 
> syntax is desirable, but IMHO at this point there is also a question of 
> semantics: what exactly compiler is supposed to tell linker? I think it 
> would be good to list here the use scenarios that we now of. Scenarios 
> that would benefit from compiler communicating to linker more then 
> names@sections. (even if such list wouldn't evolve into any 
> implementation effort at this point I think that would nicely conclude 
> this thread.)
> 

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.

2. Adding a suffix to section names.

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

4. Pragmas to apply section names (or prefixes or suffixes) to a block 
of definitions, changing the defaults.

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@")))

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.

7. Convenient support for sections (or variables) placed at specific 
addresses, in a standardised way.

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

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.

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.

11. Convenient support for building up tables where the contents are 
scattered across different source files, without having to manually edit 
the linker files.


Much of this can be done today, but involves manual (and therefore 
error-prone) effort and inconvenience.