Re: register sets

On Fri, 18 Apr 2025 1:56:24 +0000, Robert Finch wrote:

On 2025-04-17 2:26 p.m., MitchAlsup1 wrote:

On Thu, 17 Apr 2025 13:35:36 +0000, Scott Lurndal wrote:
>

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 4/16/2025 8:42 PM, Robert Finch wrote:

Working on the Qupls3/StarkCPU core it looks like there will be enough
resources to support two sets of registers. The extra set of registers
comes for free for the register file as the BRAMs can support them. The
only increase is in the RAT. The issue I have to trade-off on now is
which of the four operating modes gets its own set of registers while
the other three share a set. However, the first eight registers will be
shared between all modes so that arguments can be passed between them.
The ARM does this. My thought is that the application /  user  mode
gets
its own register set, and the rest of the system shares the other set.
That way there is no need to save and restore the app registers when
calling the system.
>
Another thought is to not include float registers for anything other
than apps. It would save 32 regs per mode, possibly allowing three
register sets to be provided.

>
>
Not to mention speeding up context switches as you don't need to
save/restore the FP registers for those levels that don't have them, and
if only one level does have them, no need to save them if the switch is
to a level that doesn't have them, as they then can't be clobbered.

I have several examples where My 66000 with only 32-GPRs compiles
to fewer instructions than RISC-V with 32+32 registers.
I have other examples where My 66000 does not need spill/fill code
and RISC-V does, too.

Many modern CPUs including intel/amd have mechanisms that the OS
can use to determine if floating point registers have been used
since the user process was dispatched, including a trap to the
OS on the first floating point use.  This allows them to avoid
saving and restoring the FP registers during context switches.

>
The converse point is that the OS may want to use vector instructions
to move data around (Disk-cache to User-buffer) and thus have to have
access to those registers anyway.
>
But, yes, if you have 14 different kinds of register files, you need
something close to 13 of them under flags of control to thin the
work at context switch time.

>
I like having the extra register files, it is just a personal
programming convenience. It reduces the pressure on the general-purpose
register file.

Universal constants also reduces pressure both on ISA on the GPRs, and
on executing instructions.

               It is also a matter of encoding the register selection in
a 32-bit instruction. I did not want to waste more than five bits on the
register selection. It is really a 52?-register machine, but the
instruction encodings do not allow all registers for all instructions.
One can use the move instruction to swap any registers.
>
But it makes the compiler more complex as it has to deal with different
architectural register files. I suppose one could code the compiler for
a machine with a flat 96 registers by surrounding operations with move
instructions. It is code bloat but I do not know if it would affect
performance.
>
Thinking of including a register exchange instruction.

Changing the capital R in RISC into a lower case r ?!?