Re: wishlist: support for shorter pointers

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

Hi Richard,

W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze:
[--------------]
> 
> 
> I think I understand what you're asking for but:

 From what I can see below. You do. The case is exactly this.

> 1) You'd need a new ABI specification to handle this, probably involving 
> register assignments (for the 'segment' addresses), the initialization 
> of those at startup, assembler and linker extensions to allow for 
> relocations describing the symbols, etc.
> 2) Implementations for all of the above (it would be a lot of work - 
> weeks to months, not days).  Little existing code, including most of the 
> hand-written assembly routines is likely to be compatible with the 
> register conventions you'd need to define, so all that code would need 
> auditing and alternatives developed.

I was afraid of that ... admittedly, not to the point you explain here.

> 3) I doubt it would be an overall win in the end.

IMHO achieving the goal is worthwhile, although my estimates on the 
effort is surely not sufficient. I only hope, that it may spark some 
twist in doing the programming, thusly have a significant influence on 
future of programming as such. But, may be not.

> 
> I base the last assertion on the fact that you'd now have three values 
> in many addresses, the base (segment), the pointer and then a final 
> offset.  This means quite a bit more code being generated, so you trade 
> smaller pointers in your data section for more code in your code 

Yes. And this is the actual reality with embedded systems. Atmega can 
have 128k of Flash, and only 4k of RAM, stm32f070 has 32k of flash and 
4k of RAM. Having 1M of flash with just 128k of RAM is common in the 
"bigger" devices. Most of the time, when I have to choose, I'm better 
off moving things info flash instead of keeping them in RAM.

> section.  For example,
> 
> struct f
> {
>    int a;
>    int b;
> };
> 
> int func (struct f *p)
> {
>    return p->b;
> }
> 
> would currently compile to something like
> 
>      ldr r0, [r0, #4]
>      bx lr
> 
> but with the new, shorter, pointer you'd end up with
> 
>      add r0, r_seg, r0
>      ldr r0, [r0, #4]
>      bx lr
> 
> In some cases it might be even worse as you'd end up with 
> zero-extensions of the pointer values as well.

Yes, it would be like this. Only I don't think, that this case would be 
a real problem, since CPU-s usually have those zero-extended register 
loads already within their instruction sets. So in reality the cost will 
be a single ADD instruction before dereference, because the segment 
register would be initialized outside the loops.

-R

> 
> R.
> 
>> -R
>>
>>>
>>> Best,
>>> Martin
>>>
>>> Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pietrak via 
>>> Gcc:
>>>> Hello everybody,
>>>>
>>>> I'm not quite sure if this is correct mailbox for this suggestion (may
>>>> be "embedded" would be better), but let me present it first (and while
>>>> the examples is from ARM stm32 environment, the issue would equally
>>>> apply to i386 or even amd64). So:
>>>>
>>>> 1. Small MPU (like stm32f103) would normally have small amount of RAM,
>>>> and even somewhat larger variant do have its memory "partitioned/
>>>> dedicated" to various subsystems (like CloseCoupledMemory, Ethernet
>>>> buffers, USB buffs, etc).
>>>>
>>>> 2. to address any location within those sections of that memory (or
>>>> their entire RAM) it would suffice to use 16-bit pointers.
>>>>
>>>> 3. still, declaring a pointer in GCC always allocate "natural" size 
>>>> of a
>>>> pointer in given architecture. In case of ARM stm32 it would be 
>>>> 32-bits.
>>>>
>>>> 4. programs using pointers do keep them around in structures. So
>>>> programs with heavy use of pointers have those structures like 2 times
>>>> larger then necessary .... if only pointers were 16-bit. And memory in
>>>> those devices is scarce.
>>>>
>>>> 5. the same thing applies to 64-bit world. Programs that don't require
>>>> huge memories but do use pointers excessively, MUST take up 64-bit 
>>>> for a
>>>> pointer no matter what.
>>>>
>>>> So I was wondering if it would be feasible for GCC to allow SEGMENT to
>>>> be declared as "small" (like 16-bit addressable in 32-bit CPU, or 
>>>> 32-bit
>>>> addressable in 64-bit CPU), and ANY pointer declared to reference
>>>> location within them would then be appropriately reduced.
>>>>
>>>> In ARM world, the use of such pointers would require the use of an
>>>> additional register (functionally being a "segment base address") to
>>>> allow for data access using instructions like: "LD Rx, [Ry, Rz]" -
>>>> meaning register index reference. Here Ry is the base of the SEGMENT in
>>>> question. Or if (like inside a loop) the structure "pointed to" by Rz
>>>> must be often used, just one operation "ADD Rz, Ry" will prep Rz for
>>>> subsequent "ordinary" offset operations like: "LD Ra, [Rz, #member]" 
>>>> ...
>>>> and reentering the loop by "LDH Rz, [Rz, #next]" does what's 
>>>> required by
>>>> "x = x->next".
>>>>
>>>> Not having any experience in compiler implementations I have no idea if
>>>> this is a big or a small change to compiler design.
>>>>
>>>> -R
>>>
>>>
>