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
