From: muta...@gmail.com   
      
   On Monday, July 19, 2021 at 2:57:20 AM UTC+10, James Harris wrote:   
      
   > > No. On a real 8086. The x'66' will be ignored. So a real   
   > > 8086 and PM32 will both work, right?   
   >   
   > Forgive me for being critical but if I understand what you mean by the   
   > above (which is by no means certain) I think you are going about this in   
   > the wrong way and could cause yourself all kinds of problems down the line.   
   >   
   > I thought you were writing your code in C (C90 specifically). Well, C is   
   > designed to be portable so it should let you write code which will run   
   > on 8086, 80286 and 80386 machines - but the C approach to such   
   > portability is compilation for the different targets. C provides   
   > source-code portability, not object-code portability. It is normal with   
   > C to recompile a piece of source for different targets. An 8086 is a   
   > different target from 80386, just as it is from 68000.   
   >   
   > If you want /binary/ compatibility you might be better writing in Java   
   > or Pascal.   
      
   I am happy to have a separate compilation for 8086   
   vs 80386. I'm even happy to have separate compilations   
   for each of the 8086 memory models.   
      
   But if there are a variety of CPUs that can run 8086   
   executables, and some of them address 1 MiB max,   
   and some of them address 512 MiB max, I would   
   like to write code to the lowest common denominator   
   if possible, rather than have 27 sort-of-8086 large   
   memory model variants.   
      
   That's what people do with the x64 too - with AMD and   
   Intel being slightly different.   
      
   If people have a problem with my approach, and they   
   really want to have an NEC-8086 which is slightly   
   different from an Intel-8086, the main difference being   
   the NEC version has one super-duper instruction, and   
   they're willing to get their compiler to generate that   
   single instruction, meaning they are tied down to the   
   NEC, but that gives them a market advantage of 5%,   
   I say - go for it!   
      
   But at the moment I'm only actually willing to generate   
   a single executable for free for any of my products and   
   that is a Win32 executable that works on PDOS/386   
   and basically everywhere else (MSDOS with HX,   
   Linux with Wine, etc).   
      
   So I guess what I look for is whether I can find a VIABLE   
   lowest common denominator. When it comes to 16-bit   
   executables, I don't actually know of anything lower than   
   the 8086, so one large-model executable that works with   
   the 8086 in 1 MiB and 512 MiB on the 80386 is fine with me.   
      
   On the mainframe I produce a single executable that works   
   in AM24 on the S/370, AM31 on the S/390, and AM32 on   
   the S/380. I used to have separate compiles for 24 vs 31   
   until I figured a technique - without kludging which is all   
   I had been informed about prior to that - that enabled   
   one binary to handle all modes. I have considered   
   dropping down one more level and targeting the S/360.   
   The GCC i370 target targets the S/370, and that is what   
   I inherited, so that is what my starting point was.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)