Re: wishlist: support for shorter pointers

[David Brown <david@westcontrol.com>]

On 28/06/2023 10:35, Rafał Pietrak via Gcc wrote:
> Hi Jonathan,
> 
> W dniu 28.06.2023 o 09:31, Jonathan Wakely pisze:
>>
>>
>>
>> If you use a C++ library type for your pointers the syntax above 
>> doesn't need to change, and the fancy pointer type can be implemented 
>> portable, with customisation for targets where you could use 16 bits 
>> for the pointers.
> 
> As you can expect from the problem I've stated - I don't know C++, so 
> I'll need some more advice there.
> 
> But, before I dive into learning C++ (forgive the naive question).... 
> isn't it so, that C++ comes with a heavy runtime? One that will bloat my 
> tiny project? Or the bloat comes only when one uses particular 
> elaborated class/inheritance scenarios, and this particular case ( for 
> (...; ...; x = x->next) {} ) will not draw any of that into this project?
> 


Let me make a few points (in no particular order) :

1. For some RISC targets, such as PowerPC, it is common to have a 
section of memory called the "small data section".  One of the registers 
is dedicated as an anchor to this section, and data within it is 
addressed as Rx + 16-bit offset.  But this is primarily for data at 
fixed (statically allocated) addresses, since reads and writes using 
this address mode are smaller and faster than full 32-bit addresses. 
Normal pointers are still 32-bit.  It also requires a dedicated register 
- not a big cost when you have 31 GPRs, but much more costly when you 
have only 13.

2. C++ is only costly if you use costly features.  On small embedded 
systems, you want "-fno-exceptions -fno-rtti", and you will get as good 
(or bad!) results for C++ as for C.  Many standard library features 
will, however, result in a great deal of code - it is usually fairly 
obvious which classes and functions are appropriate.

3. In C, you could make a type such as :

	typedef struct {
		uint16_t p;
	} small_pointer_t;

and conversion functions :

	static const uintptr_t ram_base = 0x20000000;

	static inline void * sp_to_voidp(small_pointer_t sp) {
		return (void *)(ram_base + sp);
	}

	static inline small_pointer_t voidp_to_sp(void * p) {
		small_pointer_t sp;
		sp.p = (uintptr_t) p - ram_base;
		return sp;
	}

Then you would use these access functions to turn your "small pointers" 
into normal pointers.  The source code would become significantly harder 
to read and write, and less type-safe, but could be quite efficient.

In C++, you'd use the same kinds of functions.  But they would now be 
methods in a class template, and tied to overloaded operators and/or 
conversion functions.  The result would be type-safe and let you 
continue to use a normal pointer-like syntax, and with equally efficient 
generated code.  You could also equally conveniently have small pointers 
to ram and to peripheral groups.  This mailing list is not really the 
place to work through an implementation of such class templates - but it 
certainly could be done.


4. It is worth taking a step back, and thinking about how you would like 
to use these pointers.  It is likely that you would be better thinking 
in terms of an array, rather than pointers - after all, you don't want 
to be using dynamically allocated memory here if you can avoid it, and 
certainly not generic malloc().  If you can use an array, then your 
index type can be as small as you like - maybe uint8_t is enough.


David