Re: Why I've Dropped In

On Wed, 11 Jun 2025 19:47:42 +0000, BGB wrote:

On 6/11/2025 11:37 AM, MitchAlsup1 wrote:

On Wed, 11 Jun 2025 9:42:47 +0000, BGB wrote:
------------------

>
LR: Functionally, in most ways the same as a GPR, but is assigned a
special role and is assumed to have that role. Pretty much no one uses
it as a base register though, with the partial exception of potential
JALR wonk.

One can use JALR to call special subroutines that store multiple
registers
on the stack (or restore them later) wrapping prologue and Epilogue into
little subroutine calls that use a separate LR and thus have lower over-
head than a full blown call. Other than this use and some PDP-11-style
co-routines the explicit specification of LE is completely unnecessary.

   JALR X0, X1, 16  //not technically disallowed...
>
If one uses the 'C' extension, assumptions about LR and SP are pretty
solidly baked in to the ISA design.
>
>
ZR: Always reads as 0, assignments are ignored; this behavior is very
un-GPR-like.
>
GP: Similar situation to LR, as it mostly looks like a GPR.
In my CPU core and JX2VM, the high bits of GP were aliased to FPSR, so
saving/restoring GP will also implicitly save/restore the dynamic
rounding mode and similar (as opposed to proper RISC-V which has this
stuff in a CSR).

With universal constants, you get this register back.

>
>
Though, this isn't practically too much different from using the HOB's
of captured LR values to hold the CPU ISA mode and similar (which my
newer X3VM retains, though I am still on the fence about the "put FPSR
bits into HOBs of GP" thing).
>
Does mean that either dynamic rounding mode is lost every time a GP
reload is done (though, only for the callee), or that setting the
rounding mode also needs to update the corresponding PBO GP pointer
(which would effectively make it semi-global but tied to each PE image).
>
The traditional assumption though was that dynamic rounding mode is
fully global, and I had been trying to make it dynamically scoped.

The modern interpretation is that the dynamic rounding mode can be set
prior to any FP instruction. So, you better be able to set it rapidly
and without pipeline drain, and you need to mark the downstream FP
instructions as dependent on this.

>
So, it may be that having FPSR as its own thing, and then explicitly
saving/restoring FPSR in functions that modify the rounding mode, may be
a better option.

RM is separate from FPSR in My 66000, and uniquely accessible.
-----------------------

Though, OTOH, Quake has stuff like:
   typedef float vec3_t[3];
   vec3_t v0, v1, v2;
   ...
   VectorCopy(v0, v1);
Where VectorCopy is a macro that expands it out to something like, IIRC,
   do { v1[0]=v0[0]; v1[1]=v0[1]; v1[2]=v0[2]; } while(0);
>
Where BGBCC will naively load each value, widen it to double, narrow it
back to float, and store the result.

Sounds like you should be working on the compiler instead of
microarchitectures.