From: muta...@gmail.com   
      
   On Friday, July 16, 2021 at 1:11:09 AM UTC+10, anti...@math.uni.wroc.pl wrote:   
      
   > Depends very much what "works" mean. Running unmodified   
   > 86 binaries: AFAICS no.   
      
   Do you mean running ALL unmodified 8086 binaries?   
      
   If so, you are correct.   
      
   But all C-generated code, other than huge memory   
   model, doesn't manipulate the segment registers   
   as far as hardcoding a 4-bit shift.   
      
   So. It depends. Some 8086 binaries will work, some   
   won't.   
      
   I can ensure that all of my C90-compliant programs   
   work, since even in huge memory model I have control   
   of the C library with PDPCLIB.   
      
   > You are creating a virtual machine   
      
   Why are you calling it a virtual machine??? By what   
   definition? Because it doesn't use the full capability   
   of the 80386?   
      
   > which with little care (and assuming divisor 16) will run the   
   > same binary on 86 and 386.   
      
   Why am I assuming a divisor of 16?   
      
   > Hmm. On 86 multiply and divide take time comparable to tens   
   > of simpler instructions. You also have problem of finding   
   > place to keep your divisor. If you keep divisor in register,   
   > that alone will blow up your 10% budget (losing a register on   
   > 86 is closer to 20% drop in performace) and introduce seroius   
   > incompatiblity with traditional 86 code. If you keep divisor in   
   > memory there will be extra segment manipulations to fetch   
   > divisor.   
      
   I'm not worried at all about performance of huge memory   
   model programs, which are the only ones that need to do   
   the divide and multiply.   
      
   That's the price you pay when you exceed 64k in a single   
   data structure on a machine that was only designed to   
   run 16-bit programs. There comes a point when you're   
   supposed to be recompiling as 32-bit. If you insist on   
   maintaining 8086 compatibility, then you will take a   
   performance hit.   
      
   All other memory models will run full speed, other than   
   any x'66' that are being skipped.   
      
   > Well, if you have C source, then there is obvious way   
   > to get good speed: recompile for newer machine.   
      
   Sure. But I'm trying to construct the best 16-bit   
   machine at the moment, using existing tools.   
      
   Ideally I can have EFFECTIVE 16-bit segment shifts   
   and address an entire 4 GiB, but they didn't provide   
   enough selectors for that, and I can only get 512   
   MiB, so the equivalent of an 8086 with a 13-bit   
   segment shift instead of a 4-bit segment shift.   
      
   > Note that fancy "binary translation" schemes claim   
   > speed comparable to native speed. Even less fancy   
   > schemes should be not much worse than 3 times slower   
   > compared to native. Your scheme for huge model   
   > programs is likely to lead to much more significant   
   > slowdown.   
      
   Huge memory model is rare - I'm not worried about that.   
   Even if it is 3 times slower (the whole application). It   
   would be good if other memory models ran at full speed   
   though, but I don't know how many of the instructions   
   disappear in PM32.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)