From: rick.c.hodgin@gmail.com   
      
   On 9/19/2019 2:21 AM, Terje Mathisen wrote:   
   > Rick C. Hodgin wrote:   
   >> On 9/18/2019 7:50 PM, Bart wrote:   
   >>> On 18/09/2019 13:05, Rick C. Hodgin wrote:   
   >>>> I searched for it but couldn't find it.  There used to be an 8087.asm   
   >>>> app that worked with DOS.  It would install a software emulator for   
   >>>> the 8086/8088 CPUs so it would work with native x87 FPU instructions.   
   >>>> I may still have it on one of my Programmer's Heaven CDs from back in   
   >>>> the BBS days.   
   >>>>   
   >>>> It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,   
   >>>> a version of that program was used to find the famous Pentium FDIV   
   >>>> bug, as the software version was reporting correctly, and the Pentium   
   >>>> was reporting incorrectly, over a particular range of inputs.   
   >>>   
   >>> If emulating 8087 then that puts extra demands on the emulation library,   
   >>> especially if emulating its internal 64-bit calculations.   
   >>   
   >> Yes.  The x86 CPU has a feature to allow software emulation of the   
   >> full x87 instruction set.  Whenever an x87 instruction is encountered   
   >> in x87 emulation mode, it signals an interrupt which dispatches to a   
   >> handler.  There the software simulates the operation, and then iret   
   >> back and it keeps going.  Slow, but it provides an easy x87 operation   
   >> when all you have is an 8086 or 8088.   
   >   
   > The faster option was to compile the program so that each 8087 instruction   
   > was compiled into a CALL to the emulator routine:   
   >   
   > If the 8087 hw was available, the emulator would patch the call site into the   
   > actual 8087 opcodes plus any NOPs needed to fill up the typically 3-byte   
   > call. If the opcode was in fact longer than the call, then the call would in   
   > fact be padded so that it could be replaced.   
   >   
   > Since all this code was always single-threading there was no issue with   
   > patching running code, no risk of overwriting stuff that was currently   
   > running somewhere.   
      
   In re-reading the OP, I think he's not looking to create an emulator,   
   but rather to write his OS + toolset and run it on real 8086/8 hardware.   
      
   If I were going to approach the OP's task, I would provide both the   
   hardware emulator, and the link-in support libraries to my compiler,   
   that way apps can run natively on the CPU if they don't have support   
   from a link-in support library (though it's arguable if it's his OS,   
   and the Pascal compiler is the only one available, what else would   
   there be?), but for those that do they can take advantage both ways.   
      
   I'm a "let's go all in" kind of guy (to use a phrase).   
      
   --   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)