Re: wishlist: support for shorter pointers

["Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>]

On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote:
> Hi Martin,
> 
> W dniu 28.06.2023 o 15:00, Martin Uecker pisze:
>>
>> Sounds like named address spaces to me:
>> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
> 
> Only to same extend, and only in x86 case.
> 
> The goal of the wish-item I've describe is to shorten pointers. I may be 
> wrong and have misread the specs, but the "address spaces" 
> implementation you've pointed out don't look like doing that. In 
> particular the AVR variant applies to devices that have a "native int" 
> of 16-bits, and those devices (most of them) have address space no 
> larger. So there is no gain. Their pointers cover all their address 
> space and if one wanted to have shorter pointers ... like 12-bits - 
> those wouldn't "nicely fit into register", or 8-bits - those would 
> reduce the "addressable" space to 256 bytes, which is VERY tight for any 
> practical application.
> 
> Additionally, the AVR case is explained as "only for rodata" - this 
> completely dismisses it from my use.
> 
> To explain a little more: the functionality I'm looking for is something 
> like x86 implementation of that "address spaces". The key functionality 
> here is the additional register like fs/gs (an address offset register). 
> IMHO the feature/implementation in question would HAVE TO use additional 
> register instead of letting linker adjust them at link time, because 
> those "short" pointers would need to be load-and-stored dynamically and 
> changed dynamically at runtime. That's why I've put an example of ARM 
> instruction that does this. Again IMHO the only "syntactic" feature,that 
> is required for a compiler to do "the right thing" is to make compiler 
> consider segment (segment name, ordinary linker segment name) where a 
> particular pointer target resides. Then if that segment where data (of 
> that pointer) reside is declared "short pointers", then compiler loads 
> and uses additional register pointing to the base of that segment. Quite 
> like intel segments work in hardware.
> 
> Naturally, although I have hints on such mechanism behavior, I have no 
> skills to even imagine where to tweak the sources to achieve that.


I think I understand what you're asking for but:
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.
3) I doubt it would be an overall win in the end.

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

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