From: cr88192@gmail.com   
      
   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).   
      
   But, yeah, in any case, the partial workaround was that interrupt   
   handlers don't update FPU flags. It was either this or give interrupt   
   handlers their own version of FPSR, but cheaper/easier to not bother and   
   have interrupt handlers behave as if FPSR were hard wired to all 0's.   
      
      
   Most likely possibilities:   
      MIDI / FM update ticks;   
        Tick causes FM instruments to update and similar;   
      PCM / WAVE update ticks.   
        Ticks for transferring audio from software to hardware loop buffers.   
      
   Both use some amount of floating point math internally.   
      
   Where, say:   
   Software loop buffer is mostly Binary16;   
   Audio hardware uses a small A-Law loop buffer;   
   Programs mostly submit audio as 16-bit PCM or similar, rate not   
   necessarily tied to hardware sample rate.   
      
   Didn't seem too unreasonable.   
      
   But, in any case, using FP instructions in an interrupt handler   
   shouldn't leave state changes that are visible in userland.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)