wishlist: support for shorter pointers

[Rafał Pietrak]

Hi,

W dniu 5.07.2023 o 13:55, David Brown pisze:
> On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:
[--------------]
>> 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.

me to. (pun not intended :)

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

Fully agree. ... almost fully.

I'd rather say: "I'm a big fun of being able to tell the compiler what I 
mean, but leave functionality/algorithms in libs".

And I think this has some resonance to our discussion. I think, that as 
of today, C-sources (though the compiler) don't have enough "vocabulary" 
to tell the linker "what we mean", and so the ability to "select flash 
vs RAM" or "one RAM vs another" is limited. The compiler/linker language 
is pretty much limited to resolved/unresolved names and their binding to 
linker segments.... like you've pointed above.

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

Well, similar here, although not that intensive (hobby, not profession). 
Still, I've never touched the Tiny, as I wasn't able to wrap my head 
around those limited resources for anything more then a blinker.

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

yes, not about that.

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

Doesn't it call for "something" that a c-source (through the compiler) 
can express to the linker programmers' intention?

-R