From: johnl@taugh.com   
      
   According to BGB  :   
   >On 12/15/2025 1:37 PM, John Dallman wrote:   
   >> ] * "Trap and Emulate” is an illusion of compatibility"   
   >> ]   * Performance differential is too great for most applications   
   >>   
   >> This is inevitably true nowadays, but wasn't when the idea was invented.   
   >   
   >IME, it depends:   
   >If the scenario is semi-common, it doesn't work out so well;   
   >If it is rare enough, it can be OK.   
      
   I think it's always been iffy.   
      
   S/360 required strict boundary alignment, floats on 4 byte boundaries, doubles   
   on   
   8 byte boundaries. Normally the Fortran compiler aligned data correctly but you   
   could use an EQUIVALENCE statement to create misaligned doubles, something that   
   occasionally happened in code ported from 709x where it wasn't a problem. There   
   was a library trap routine to fix it but it was stupendously slow, so IBM added   
   the "byte oriented operand" feature to the 360/85 and later models.   
      
   The high end 360/91 did not have most of the decimal instructions, on the   
   reasonable theory that few people would run the kind of programs that used them   
   on a high end scientific machine. The operating system simulated them slowly,   
   so   
   the programs did still work. But the subsequent 360/195 had the full   
   instruction   
   set.   
      
   On the other hand, back when PCs were young, Intel CPUs had a separate optional   
   fairly expensive floating point coprocessor. Most PCs didn't have them, and   
   programs that did arithmetic all had software floating point libraries. If you   
   didn't have the FPU, instructions didn't trap, they just did nothing.  The C   
   compiler we used had a clever hack that emitted floating point instructions   
   with the first byte changed to a trap instruction.  If the computer had   
   hardware floating point, the trap handler patched the instruction to the   
   real floating point one and returned to it, otherwise used the software   
   floating point.  This got pretty good performance either way.  It helped   
   that the PC had no hardware protection so the C library could just install   
   its own trap handler that went directly to the float stuff.   
      
      
      
   --   
   Regards,   
   John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for   
   Dummies",   
   Please consider the environment before reading this e-mail. https://jl.ly   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)