From: muta...@gmail.com   
      
   On Saturday, July 17, 2021 at 1:21:38 PM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
      
   > > Would you like to see some C code that does a p++   
   > > with the proposed arbitrary segment shifts?   
      
   > No, I would like to see _assembler_ generated with support   
   > for arbitrary segment shifts.   
      
   I don't understand this. We may be talking cross-purposes.   
   Assembler generated ... from what? A C90 program   
   compiled in huge memory model using Watcom C?   
      
   That generated C doesn't change one iota.   
      
   Nor does the code generated from any other memory   
   model.   
      
   > I know how to handle   
   > normal 4 bit shift, I know to implement what you want.   
   > But that is slow code. I do not know if you can produce   
   > better code or just did not realize how bad is resulting   
   > code.   
      
   I have never actually produced a huge memory model   
   program in my life. Everything I have wanted to do,   
   starting with hello world and moving up, can be done   
   in large memory model max.   
      
   If only large memory model programs and below work   
   with 512 MiB of memory, so be it. It doesn't actually   
   affect any code I have already written.   
      
   It does affect a future program though, for which I   
   wish to use huge memory model, now that I know it   
   exists. That program is not performance-critical. I   
   don't care if the entire application is 3 times slower.   
   I bet it isn't even 1% slower though, but it will be   
   impossible to measure either way. At least by   
   observance.   
      
   Getting huge memory model to work at all with   
   512 MiB is icing on the cake.   
      
   > > I think we're probably in a semantic debate now.   
   > > If you want to call everything a VM, it doesn't affect   
   > > my design. Just a few months ago someone told   
   > > me that PDOS/386 wasn't an operating system, it   
   > > was a file manager and API or something like that.   
      
   > Well, PDOS/386 is not an operating system, at best is   
   > just part of operating system. But I know that   
   > you really want to call it operating system, so I am   
   > simply ready to translate form your terminolgy to   
   > accepted one.   
      
   Wow. Ok, the last person who made that claim didn't   
   actually answer me when I asked him what definition   
   of "operating system" he was using. So maybe you   
   can answer.   
      
   1. Was MSDOS an operating system, and if so, why?   
      
   2. Why is PDOS/386 not an operating system?   
      
   > > I now know that I can avoid the prefixes, in PM32,   
   > > simply by setting the D bit appropriately in all the   
   > > segments. Why would I bother learning how to   
   > > get into PM16?   
      
   > If you want to do anyting (as opposed to asking other folks   
   > to do coding for you)   
      
   What are you talking about? I've been working on   
   PDOS for 27 years. This is not a future tense   
   situation.   
      
   > you need to look up descriptor   
   > format in Intel docs. You will see that each descriptor   
      
   I already consulted that something like 24 years ago.   
   The knowledge is now encapsulated in public domain   
   code, and I no longer have any interest in it except   
   just now when I started thinking about PDOS/86   
   again.   
      
   > has type field. There are several types, but only two   
   > are relevant here: 16-bit code descriptor and 32-bit code   
   > descriptor. If you do far control transfer to descriptor   
   > marked as 32-bit code, then processor switches to 32-bit   
   > mode. If you do far control transfer to descriptor   
   > marked as 16-bit code, then processor switches to 16-bit   
   > mode. If you really know how to get into PM32, you   
   > should also know how to get into PM16.   
      
   It's more "knew" than "know". And I only focused on   
   getting into PM32, not stopping to think whether I   
   had just passed PM16 and whether that would be   
   useful for anything. I wanted a flat 32-bit address   
   space as priority. I had very little interest in 16-bit   
   coding until just recently.   
      
   > > Most C programs are full of crap. They won't even   
   > > compile, nevermind run. They will do an unconditional   
   > > #include of the non-existent sys/types.h   
      
   > Well, switch to better system/compiler which provides   
   > sys/types.h   
      
   No, I will switch to better applications, that don't   
   include sys/types.h and actually follow the C90   
   rules.   
      
   I'm not expecting you to follow my route. But don't   
   expect me to follow yours either.   
      
   > On my current system support for running 32-bit and 16-bit   
   > executables is not installed, so there are only 64-bit   
   > one. I am happy to recompile if needed. In fact, for   
   > rarely used programs I keep only sources and no binaries,   
   > and compile when needed. And "hello world" is more   
   > often compiled than run.   
      
   Again, you are free to do whatever you like. Me, I want   
   my 16-bit programs to be clean, meaning no hardcoding   
   of the number 4.   
      
   I also want my S/3X0 programs to be clean, ie no   
   messing with the top address bit, so that they can   
   run as AM32.   
      
   > > But I would also like to have the   
   > > option of coding the hello world as 16-bit, produce   
   > > a single executable, and have it work everywhere.   
      
   > There are various "solutions" to "work everywhere", but   
   > in modern times "everywhere" does not include 16-bit   
   > systems.   
      
   Not everyone shares that opinion, even in modern   
   times. I cater for people who like the idea of clean   
   16-bit 8086 programs running on both an 8086   
   and addressing 512 MiB on an 80386.   
      
   > > I was surprised to wake up one day and find that   
   > > my programs in c:\dospath stopped working.   
   > > For decades I had had no reason to recompile them.   
   > > It would have been far better if I had woken up and   
   > > I could suddenly edit 512 MiB files with them. Or   
   > > whatever the application was that just allocated   
   > > memory in chunks as required. Like maybe   
   > > Turbo C++ can suddenly start building 50 MB   
   > > executables.   
      
   > Dreams are nicer than reality. My modern 16-bit coding   
   > was for machines with small memory, between 512 byte RAM   
   > and 2K RAM (there was also flash, 512 byte RAM machine   
   > also had 16k flash). I am not worried that old 16-bit   
   > programs would not run on those machines and that I need   
   > to recompile.   
      
   That's fine. I don't care if you're not worried. I care, and   
   I'm interested in a technical discussion. I'm not trying   
   to get you to buy current PDOS/86 or future PDOS/86.   
      
   > > > > 2. The 8086 silicon was perfect.   
   > >   
   > > > Here you are making things up. 8086 was a compromise, it   
   > > > worked and won against several competitors. But "won" does   
   > > > not mean it was better then existing competitors, and almost   
   > > > surely it was possible to make better processor.   
   > >   
   > > Not when the requirement is to run 8080 CP/M   
   > > programs in a memory-restricted environment.   
      
   > Note that 8086 was _not_ binary compatible with 8080.   
      
   Yes, I didn't say they were. I said it was a requirement.   
   And Intel had the correct technical solution to that   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)