Re: Why I've Dropped In

On 6/12/2025 2:13 PM, MitchAlsup1 wrote:

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.
 

Possibly, though I had handled it by first copying the LR into a different register.
But, yeah, using a second register, such as X5, would save 1 instruction here.

   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.
 

Well, if using an ABI that either allows absolute addressing or PC-rel access to globals.
The ABI designs I am using in BGBCC and TestKern use a global pointer for accessing globals, and allocate the storage for ".data"/".bss" separately from ".text". In this ABI design, the pointer is unavoidable.
Does allow multiple process instances in a single address space with non-duplicated ".text" though (and is more friendly towards NOMMU operation).

>
>
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.

Errm, there is likely to be a delay here, otherwise one will get a stale rounding mode.
So, setting the rounding mode might be something like:
   MOV .L0, R14
   MOVTT GP, 0x8001, GP  //Set to rounding mode 1, clear flag bits
   JMP R14         //use branch to flush pipeline
   .L0:            //updated FPSR now ready
   FADDG R11, R12, R10  //FADD, dynamic mode
Or, use an encoding with an explicit (static) rounding mode:
   FADD R11, R12, 1, R10

>
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.

In my case, as noted, RM is in FPSR, which is in the HOB's of GP/GBR...
Maybe a crappy design in retrospect that may need to be changed.

-----------------------

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.

This whole project has mostly involved a whole lot of working on my compiler...
But, support for the RV64G target is newer, and I only very recently got around to making Quake work on it.
But, the generated FPU code for the RV64 target is still kinda trash...
Well, along with it haphazardly thrashing FPU values between GPR and FPR space due to not yet re-implementing the concept of FPU registers (and, the original SH-4 FPU path is too stale to really be worth bothering with).
In XG1/XG2/XG3, there is an FMOV.S instruction that does the load/store and format conversion at the same time.
But, RV64G doesn't have this; and this is a weak case for BGBCC's assumption that FPU values are always in Binary64 form in registers.
Somehow still performs OK despite the terrible FPU code.
Had noted that the fallback code for my newer "PMULT" instruction would also be particularly bad for RV64G.
   PMULT:  Can twiddle the signs or zero out SIMD elements.
Fallback:
Well, we can turn it into an AND and XOR with some 64-bit constants.
RV64G (and its lack of 64-bit constants):
Oh, oh dear...
Then again, it also lacks a good way to do shuffles, or SIMD instructions for that matter (each vector op turns into a function call), so it may not be too bad in comparison.
Mostly just a matter of me wanting the compiler to still support the relevant language extensions regardless of whether there is native ISA level support (nevermind if the performance is a bit lacking in this case).
...