From: cr88192@gmail.com   
      
   On 9/17/2025 1:53 PM, MitchAlsup wrote:   
   >   
   > BGB  posted:   
   >   
   >> On 9/17/2025 8:57 AM, Scott Lurndal wrote:   
   >>> BGB  writes:   
   >>>> On 9/16/2025 12:50 PM, Scott Lurndal wrote:   
   >>>>> BGB  writes:   
   >>>>>> On 9/14/2025 9:06 AM, Michael S wrote:   
   >>>>>   
   >>>>>>   
   >>>>>> Also there was another related bug where FPU instructions in interrupt   
   >>>>>> handlers could effect the FPU flags visible in userland.   
   >>>>>   
   >>>>> Why on earth would you use floating point instructions   
   >>>>> in an interrupt handler?   
   >>>>>   
   >>>>   
   >>>>   
   >>>> I didn't go and track down which code was using FPU instructions, but   
   >>>> seemingly something was, in any case. I didn't see any particular reason   
   >>>> to forbid using the FPU inside of interrupt handlers (they are mostly   
   >>>> still plain C, differing mostly in that there are limited to the   
   >>>> operating in terms of the physical memory map).   
   >>>   
   >>> The standard reasoning for prohibiting floating point in the   
   >>> kernel is to improve system call overhead by not saving floating   
   >>> point registers until and unless there is a context switch (and   
   >>> even then, x86 has features that allow the OS to forgo saving   
   >>> the floating point registers if they weren't used in the last   
   >>> scheduling quantum).   
   >>>   
   >>   
   >> In my case, this wasn't x86, and on my ISA the FPU stuff is done in   
   >> GPRs, which typically need to be saved/restored either way. Well, except   
   >> when running RISC-V code, which effectively splits the register space in   
   >> half (32+32 rather than 64).   
   >>   
   >>   
   >> The issue was that the FPSR is (now) aliased to SP(63:48), but there was   
   >> only a single SP; and the CPU core handles interrupts by causing SP and   
   >> SSP to switch places in decode.   
   >   
   > Switching SP with SSP does not work (fundamentally) when there are   
   > 4 privilege levels--as each privilege level needs its own unique SP.   
   >   
      
   In this case, there are 3 major modes:   
      user, Supervisor, and ISR   
      
   But only 2 levels:   
      User|Supervisor, ISR   
   So User and Supervisor get their own SP, but in this case it is handled   
   by using a context switch.   
      
      
   >> The likely more proper solution would have been to have another FPSR   
   >> aliased to SSP(63:48) which also re-routes; where as-is SSP is currently   
   >> only a 48 bit register internally.   
   >   
   > So, when one does a::   
   >   
   >       ADD   SP,SP,#big-number   
   >   
   > do the HoBs of SP get changed (like any other GPR or do you special   
   > case SP ?!?   
   >   
      
   In premise, if you add a big enough value to SP, then it will stomp the   
   FPU state (at least as far as this sort of thing goes, it behaves like a   
   GPR).   
      
   In normal use, it wont matter, since SP only ever covers a small range   
   of values.   
      
   Granted, maybe this is a stupid way to do it...   
      
      
   Similarly, modifying the HOBs of SP can be used to modify the FPU state.   
      
   This does still pose a non-zero risk of breaking stuff in RISC-V mode,   
   where GCC is likely to be unaware of the wonk in the high order bits of SP.   
      
   Most likely case is special-casing the ADD and ADDI instructions in the   
   RISC-V decoder when working with SP (the high bits always being read a 0   
   and ignored on write).   
      
   In this case though, "ORI" or similar could be used to access the full   
   register.   
      
      
      
   >> But, for now, easier was to disable the updates if inside an ISR.   
   >   
   > My 66000 code does not even know it is in an ISR--as ISRs do not   
   > disable interrupts, disable exceptions, and are re-entrant from   
   > the very first ISR instruction.   
   >   
   > Thus, ISRs can do FP if they desire, Vectorize loops as needed,   
   > and are not limited in their use of ISA.   
   >   
      
   In my case, as noted, they can still use the FPU, but it is now   
   hard-wired to DAZ/FTZ mode. They also operate in physical memory addressing.   
      
   Likewise, no support for re-entrant interrupt handling.   
      
      
   For now, main way to do more than this is to perform a context-switch to   
   a supervisor mode task.   
      
      
   >> This issue wouldn't have existed if still using GBR/GP for this, but GBR   
   >> has the disadvantage that it gets stomped whenever a reload occurs; so   
   >> it was either tweak the GBR reload mechanism to not stomp FPSR, or move   
   >> FPSR somewhere where it doesn't get stomped (the high bits of SP being   
   >> the most obvious choice).   
   >   
   > My ISA does not have this problem as it does not need a GBR, universal   
   > constants (this time as a displacement) eliminated the need.   
      
      
   FWIW: I could have used PC-rel, but this doesn't work well with NoMMU.   
   And, a shared address space following NoMMU rules has less overhead than   
   multi-mapping pages or CoW.   
      
   Likewise, absolute addressing doesn't appeal to me (if anything, it is   
   worse than PC-rel).   
      
      
   The main other option (besides putting it in the HOB's of SP or similar)   
   would have been to create a new CR for it, but then would need to   
   save/restore this CR on context switch and similar (and adding a new CR   
   would have been more logic than shoving it into the HOB's of SP or similar).   
      
   Another option would have been the HOBs of SR, but as-is SR(63:32) is   
   currently assumed to hold global system-level state; whereas FPSR is   
   clearly task-local.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)