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.
