From: muta...@gmail.com   
      
   On Tuesday, July 20, 2021 at 9:30:58 PM UTC+10, James Harris wrote:   
      
   > > 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 not attempting to exploit every option. What I am   
   trying to do is, with the benefit of hindsight (not sure   
   if it was possible to determine this the moment the   
   8086 came out) - restrict my assembler code, my C   
   library, and my C compiler, and threaten Gates with   
   NATO air strikes to provide the required MSDOS API,   
   to write 8086 executables such that the number "4"   
   was not hardcoded anywhere, and that in the future,   
   chip manufacturers would potentially provide a chip   
   that runs those 8086 executables with anything up   
   to 16-bit segment shift.   
      
   I see no advantage to hardcoding the number 4 in my   
   executables, and it offends my sensibilities to see it.   
      
   Note that AmigaOS hardcodes *address* 4 too.   
      
   In my own AmigaOS executables I also have the   
   number 4 (no real choice), but I provide a peer-reviewed   
   way for the caller of my executables (e.g. some alternate   
   OS) to provide an alternative to the number 4. Done in a   
   manner that provides no disadvantage whatsoever,   
   unless you count a few extra instructions at executable   
   startup time.   
      
   > > 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?   
      
   It is not me who is limiting it, it is the 80386 not providing   
   sufficient descriptors to map out the entire 4 GiB.   
      
   And regardless, 512 MiB for 8086 executables that run   
   under a slight variation of MSDOS, or even, real MSDOS,   
   is a hell of a lot more than anyone else is doing.   
      
   And they are 32-bit pointers anyway (large memory model).   
   They're just not flat. Well they are in fact flat when the   
   segment shift becomes 16 bits, but the executable is not   
   aware of that, as it has been built with segmented pointers.   
      
   > There are at least three ways to do that:   
   > * unreal   
      
   That won't work on an 8086.   
      
   > * 16-bit operations in 32-bit mode   
      
   That's what I was originally trying to do, hence the question   
   about what x'66' does on a real 8086. Thanks to Joe, this   
   technique has since been improved such that I don't need   
   to know about x'66'.   
      
   Regardless, my new technique is still PM32, depending on   
   what you're calling "32-bit mode".   
      
   > * soft CPU   
      
   I don't know what that is. If it's not 8086 instructions it isn't   
   what I'm trying to achieve. If it is some sort of emulation,   
   that's not what I'm trying to achieve either.   
      
   > > 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.   
      
   Even if I did the above, I still want to decide how the   
   "8086 version of the code" looks like.   
      
   How many different 8086-like processors are out there?   
   Note that I consider an 80386 in PM32 with descriptors   
   with the D-bit indicating 16-bit defaults to be "8086-like".   
   It doesn't necessarily need to be built by NEC. The lowest   
   common denominator between two Intel processors is   
   also interesting.   
      
   It depends how many "real 8086" instructions I will lose   
   on this non-real-8086 (from NEC or Intel or the Norks).   
   If I just lose one unimportant instruction, I'm happy to   
   just never use that instruction. If someone else doesn't   
   like the idea of crippling executables, even by taking   
   out one sort-of-useful instruction, they are free to   
   recompile from source code.   
      
   > 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.   
      
   If I was going to do the above, I would have a 32-bit version   
   of the program.   
      
   In principle I have no objection to people bundling 8086,   
   80386, 68000 and S/370 executables into a single   
   executable.   
      
   But I also want the option of separating them out.   
      
   And also having the option of making the 8086 version   
   of the above run on not just Intel's original 8086.   
      
   > I'd suggest /compiling/ your 16-bit programs to run in PM32. You can   
   > still keep them doing what they do in 16-bit mode with all the 16-bit   
   > limitations, if you like, but they would have access to more memory via   
   > bigger pointers. I know you already plan to use bigger pointers so I   
   > don't see why those pointers cannot be flat. Instead of segmented 16:16   
   > why not use flat 32?   
      
   Personally once you go with flat 32-bit pointers, I don't   
   see any point in having 16-bit programs.   
      
   > Is there something about your C source code which   
   > requires the presence of near and explicitly far pointers? Does   
   > something in your source code explicitly manipulate segment registers?   
      
   No and no.   
      
   > If so, maybe it's not your preferred language C90.   
      
   I'm only interested in C90. At least for now.   
      
   > Watcom C, IIRC, had explicit support for segmented pointers but I'd say   
   > Watcom C was C-like; it was not C.   
      
   I'm not interested in the "far" and "near" keywords.   
   I am interested in every memory model available   
   though.   
      
   > C is a brilliant programming language. It should be enough to do the   
   > Turing-complete stuff you want to do in great and /native/ ways.   
      
   It can do both native AND lowest common denominator.   
   Or even medium common denominator.   
      
   > If it's building a lowest common denominator exe file that's the issue   
   > your build tools can create a dual-mode executable which runs   
   > 8086-native code if it finds itself on an 8086, and runs 80386-native   
   > code if it finds itself in PMode. You could even have it run AMD64-mode   
   > code if it finds itself in an LMode environment.   
      
   That can be an option TOO, not INSTEAD OF.   
      
   > In all environments the   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)