Re: wishlist: support for shorter pointers

[David Brown <david@westcontrol.com>]

On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:
> Hi,
> 
> W dniu 5.07.2023 o 11:11, David Brown pisze:
>> On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
> [-----------]

>> I am not sure if you are clear about this, but the address space 
>> definition macros here are for use in the source code for the 
>> compiler, not in user code.  There is (AFAIK) no way for user code to 
>> create address spaces - you need to check out the source code for GCC, 
>> modify it to support your new address space, and build your own 
>> compiler.  This is perfectly possible (it's all free and open source, 
>> after all), but it is not a minor undertaking - especially if you 
>> don't like C++ !
> 
> Hmmm.
> 
> Wouldn't it be easier and more natural to make the "named spaces" a 
> synonym to specific linker sections (like section names, or section name 
> prefix when instead of ".data.array.*" one gets ".mynamespace.array.*")?

You can, of course, write :

#define __smalldata __attribute__((section(".smalldata)))

I'd rather see the "section" attribute extended to allow it to specify a 
prefix or suffix (to make subsections) than more named address spaces.

I'm a big fan of only putting things in the compiler if they have to be 
there - if a feature can be expressed in code (whether it be C, C++, or 
preprocessor macros), then I see that as the best choice.

> 
> [------]
>> I realise that learning at least some C++ is a significant step beyond 
>> learning C - but /using/ C++ classes or templates is no harder than C 
>> coding.  And it is far easier, faster and less disruptive to make a 
>> C++ header library implementing such features than adding new named 
>> address spaces into the compiler itself.
>>
>> The one key feature that is missing is that named address spaces can 
>> affect the allocation details of data, which cannot be done with C++ 
>> classes.  You could make a "small_data" class template, but variables 
>> would still need to be marked __attribute__((section(".smalldata"))) 
>> when used.  I think this could be handled very neatly with one single 
>> additional feature in GCC - allow arbitrary GCC variable attributes to 
>> be specified for types, which would then be applied to any variables 
>> declared for that type.
> 
> OK. I see your point.
> 
> But let's have look at it. You say, that "names spaces affect allocation 
> details, which cannot be done with C++". Pls consider:
> 1. for small embedded devices C++ is not a particularly "seller". We 
> even turn to assembler occasionally.

I have been writing code for small embedded systems for about 30 years. 
I used to write a lot in assembly, but it is very rare now.  Almost all 
of the assembly I write these days is inline assembly in gcc format - 
and a lot of that actually contains no assembly at all, but is for 
careful control of dependencies or code re-arrangements.  The smallest 
device I have ever used was an AVR Tiny with no ram at all - just 2K 
flash, a 3-level return stack and its 32 8-bit registers.  I programmed 
that in C (with gcc).

C++ /is/ a big "seller" in this market.  It is definitely growing, just 
as the market for commercial toolchains with non-portable extensions is 
dropping and 8-bit CISC devices are being replaced by Cortex-M0 cores. 
There is certainly plenty of C-only coding going on, but C++ is growing.

> 2. affecting allocation details is usually the hole point of engineering 
> skills when dealing with small embedded devices - the hole point is to 
> have tools to do that.
> 

When you are dealing with 8-bit CISC devices like the 8051 or the COP8, 
then allocation strategies are critical, and good tools are essential.

But for current microcontrollers, they are not nearly as important 
because you have a single flat address space - pointers to read-only 
data in flash and pointers to data in ram are fully compatible.  You do 
sometimes need to place particular bits of data in particular places, 
but that is usually for individual large data blocks such as putting 
certain buffers in non-cached memory, or a large array in external 
memory.  Section attributes suffice for that.

Allocation control is certainly important at times, but it's far from 
being as commonly needed as you suggest.

(Dynamic allocation is a different matter, but I don't believe we are 
talking about that here.)

> So your current objections to named spaces ... are in fact in favor of 
> them. Isn't it so?
> 

Not really, no - I would rather see better ways to handle allocation and 
section control than more named address spaces.

David