From: user5857@newsgrouper.org.invalid   
      
   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.   
      
   > 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 ?!?   
      
   > 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.   
      
   > 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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)