From: james.harris.1@gmail.com   
      
   On 19/07/2021 11:30, muta...@gmail.com wrote:   
   > 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.   
      
   That's good. It separates specification (the source code) from   
   implementation (various CPU modes). But it should give you all kinds of   
   possibilities and I don't think you are exploiting the options it gives.   
   See below for examples.   
      
    >   
   > I'm even happy to have separate compilations   
   > for each of the 8086 memory models.   
      
   OK.   
      
   >   
   > 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,   
   You maybe think that's a lot but I don't see why you would want to limit   
   programs like that. For example, why can you not keep to the 16-bit   
   integers you want to be part of the 16-bit ecosystem but use 32-bit   
   pointers so that programs can address 4G?   
      
   There are at least three ways to do that:   
      * unreal   
      * 16-bit operations in 32-bit mode   
      * soft CPU   
      
    >   
   > 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 a good goal but /compiled/ code can have two paths along the   
   lines of   
      
      if I am running on a real 8086   
           
      else if I am running on a 32-bit machine   
           
      
   IOW the 8086 and ia-32 paths could both be in the same executable file.   
      
   Then the lowest common denominator of that exe file would be 1M 8086 but   
   the code in it could also address a lot more if it happened to run on a   
   CPU which was capable of it.   
      
   To be clear, the ia-32 code I mentioned above can still behave as   
   16-bit, if that's what you want, or you can have it behave as a 32-bit   
   version of the program. It would be up to you.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)