Re: Why I've Dropped In

On Thu, 12 Jun 2025 21:30:39 +0000, BGB wrote:

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

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

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

It is ISA that directly supports 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.

I want a system where .data and .bss can be > 1TB away from each other.
So, that .data grows when ld.so loads another dynamic library, and .bss
grows for the same reasons.

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.

RM is "just 3-bits" that get read from control register and piped
through instruction queue to function unit. Think of the problem
one would have if a hyperthreaded core had to stutter step through
changing RM ...

>
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

Setting RM to a constant (known) value::
     HRW  rd,RM,#imm3    // rd gets old value

Or, use an encoding with an explicit (static) rounding mode:
   FADD R11, R12, 1, R10
>