Re: Why I've Dropped In

BGB <cr88192@gmail.com> writes:

On 6/11/2025 11:51 AM, Anton Ertl wrote:

Link register: On some architectures there is a register that is a GPR
as far as most instructions are concerned.  But the call instruction
with immediate (relative) target uses that register as implicit target
for the return address.  MIPS is an example of that.  Power has LR as
a special-purpose register.
 

>
It is GPR like, but in terms of role, I don't consider it as such.
>
In RV64, in theory, JAL and JALR could use any register. But, the C ABI
effectively limits this choice to X1.

So what?  The architecture does not.  Also, given that static linking
and maybe even whole-program optimization are on the rise, the forces
that coerce you to use the ABI are getting smaller.

Implicitly, the 'C' extension and some other (less standardized)
extensions also tend to hard-code the assumption of X1 being the link
register.

Yes, the C extension is designed for minimizing the code size of
common code, and assumes that the code follows the ABI.  But nothing
in the architecture forces you to use compressed instructions.
Whenever it is more advantageous to use an instruction in a way that
cannot be compressed, you just do it.  E.g., if you do whole-program
optimization, and you have functions

A (called from 10 sites)
B calls A (called from 2 sites, address not taken for indirect calling)
C calls B

Then one can use JAL or JALR with the target X1 to call A, and these
instructions may be compressible.  And one can use JAL or JALR with a
different target to call B.  The benefit of that is that B does not
need to save and restore the address it returns to, eliminating the
code needed for that, and the time needed to perform this saving and
restoring.

However, the architecture specification says that using x1 and x5 are
considered to be link registers for branch prediction purposes, so
ideally one will use x5 as target for calls to B, and for further
levels the question is if it is good enough to just use plain
indirect-branch prediction for those calls, or if one invests into the
saving and restoring in order to use the return-address stack for
branch prediction.

Well, it is more a case here of, "try to put something other than the
stack pointer in SP and see how far you get with that".
>
There are multiple levels of systems (ISA design, OS, ...)

Neither the ISA nor the system call interfaces I have looked at would
cause any problems if I use x2 (sp) on RISC-V for something else.
Maybe in case of a handled signal the OS would write to to a place
pointed to by x2, but that requires 1) installing a signal handler and
2) not using sigaltstack() to tell the OS where to write in such a
case.  Of course the signal handler (if any) with see x2 set to point
to the alternative stack, but all the regular user code can use x2 for
whatever purpose seems appropriate.  Some programming languages are
designed to work without stack (e.g., early Fortran), some to use
multiple stacks (e.g., Forth).

I am not saying they don't look like GPRs in the ISA, but rather that
they aren't really GPRs in terms of roles or behavior, but rather they
are essentially SPRs that just so happen to live in the GPR numbering space.

As far as the architecture is concerned, they are GPRs.  Yes, an ABI
specifies a special role for some of them, but the ABI is software,
not architecture.  E.g., in early MIPS ABIs (in particular, on
Ultrix), there was no GP, in later MIPS ABIs, there was.

One can nicely see the role of the ABI in Table 25.1 of
<http://staff.ustc.edu.cn/~comparch/reference/riscv-spec%EF%BC%880305%EF%BC%89.pdf>
(page 137); it has a column called "Register" (with names like "x1")
and a column called "ABI name" (with names like "ra").  The caption
says: "Assembler mnemonics for RISC-V integer and floating-point
registers, and their role in the first standard calling convention."

So the architects expect the architecture to live longer than this
ABI.

It might be even due to things as simple as "well, the OS kernel and
program launcher assume that stack is in X2, and system calls assume
stack is in X2, ...". You have little real choice but to put the stack
in X2, and if you try putting something else there, and a system call or
interrupt happens, ..., there is little to say that things wont "go
sideways", so, not really a GPR.

I don't know what OS you have in mind, but in any OS where there is a
boundary between user space and system space, the system does not use
what may be the user-space stack pointer for storing its data, not on
system calls, and certainly not on interrupts.  And when I last looked
at Linux system calls, the actual system call interface (not the C
wrapper around it) passed parameters to system calls in registers, not
on the user-level stack.

The only case where a stack pointer register may come into play is
when the OS calls a signal handler, but I have not looked at the
machine-level interface there, so I cannot say for sure.  In any case,
that does not affect all the code that is not a signal handler.

Global Pointer is assumed as such by the ABI, and OS may care about it,
so not really a GPR.

Why should the OS kernel care about the global pointer of a user-level
program?

I decided to classify X5/TP as a GPR as its usage is roughly up to the
discretion of the ABI and C runtime library (at least in RISC-V, there
are no hard-coded ISA level assumptions about TP, nor does it cross into
the OS kernel's realm of concern).

Table 25.1 (mentioned above) gives tp as ABI name for x4, and t0 as
ABI name for x5.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>