From: muta...@gmail.com   
      
   On Thursday, August 12, 2021 at 1:25:04 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
   > muta...@gmail.com  wrote:   
      
   Hi Waldek. Thanks so much for the really interesting   
   conversation. I've been in a lot of conversations in   
   the last more than 3 decades, but you are the first   
   person to provide wall-to-wall theory/philosophy.   
      
   > > > relocation register is set up by operating system, so you can   
   > > > enlarge it without change to application (of course operating   
   > > > system must know (possibly compute) size of relocation register).   
   > > > For many years paging is preferred method to run multiple   
   > > > applications.   
   > >   
   > > Ok. But that wasn't available on the 8086. Maybe there was   
   > > some way "fake paging" could have been created. Regardless,   
   > > we ended up with the "relocation (base) register" option, which   
   > > is presumably what a segment register is considered to be.   
      
   > There is important difference: segment registers on 8086   
   > can be treated as "just another register", in particular   
   > program may use them to store arbitrary 16-bit numbers   
   > (and some did so).   
      
   This I understand.   
      
   > Relocation register is handled by   
   > OS. Since relocation register is managed by OS, OS   
   > can reliably more programs, swap them and load in   
   > different place, etc. This is not possible on 8086.   
      
   I think I don't know what you are calling a "relocation   
   register". I'm mainly familiar with x86 and S/370.   
      
   The 8086 segment registers you have described   
   above, but I'm not sure if you have classified them   
   as "relocation registers".   
      
   The S/370 has "base registers". These are under   
   application control - not managed by the OS. I   
   had previously thought you meant that segment   
   registers and base registers are classified as   
   "relocation registers" but now I'm not sure.   
      
   My interest is in breaking Microsoft and IBM's   
   respective monopolies, so I'm really only interested   
   in 80386 and S/3X0. Although it is true that I took   
   a diversion through the 680x0 Amiga and Atari to   
   better prepare for the above battle.   
      
   So if you can bring things back to these architectures   
   it will help me understand.   
      
   > > > > As opposed to what alternative for large memory model   
   > > > > 8086 programs? There's some advantage to restricting   
   > > > > them to 1 MiB instead of letting them fly on an 80386?   
   > >   
   > > > Simple fact is that program which has more than 1M of code   
   > > > will not run on 1M machine.   
   > >   
   > > This is true, but I would have stopped right here. There is   
   > > nothing special about 1 M. The problem could be restated   
   > > as 2 M instead. The proper thing to do is abstract the   
   > > situation right here.   
      
   > The abstract result is: to address M locations in memory   
   > you need at least n bits, when n is such that 2 to power   
   > n is bigger or equal to M. There is no way to avoid   
   > this limitaition. What you can do is to hide extra bits   
   > in some place. Polish K-202 micro used 16 "normal"   
   > address bits, but had extra register providing 8 upper   
   > bits. The advantage was that creator of K-202 could   
   > boast about addressing 16M of memory, otherwise this   
   > was basically usesless (base configuratin had 4k memory).   
   >   
   > PC-s for many years used 16-bit DMA chips. That is, DMA   
   > chip managed 16 low address lines. Upper bits where   
   > provided by separate register (4-bit for 8086, 8-bit   
   > for 286, possibly bigger for later). This was major   
   > pain in OS, as OS had to allocate buffer avoiding   
   > crossing 64k boundaries. For example, to have   
   > decent floppy support Linux at startup allocated   
   > buffer for single track (later it would be tricky   
   > to find suitable piece of memory). Those problem   
   > were resolved by better DMA in PCI era...   
      
   Nothing you said above ties anything down to 1 MiB   
   as a magic figure instead of 2 MiB.   
      
   The correct thing to do, when programming on a   
   1 MiB machine, is to think about a 2 MiB machine.   
      
   The correct thing to do when programming on a   
   2 MiB machine is to think about a 1 MiB machine.   
      
   The correct thing to do when reading text files on   
   MSDOS is to think about the BDW and RDW on   
   mainframe RECFM=V datasets.   
      
   The correct thing to do when reading text files   
   on a mainframe RECFM=V dataset is to think   
   about the CRLF MSDOS line endings.   
      
   If you do the above, your programs will work on   
   any arbitrary C90-compliant platform, which is my   
   user requirement.   
      
   > > > So you deal with small class of programs. And apparently   
   > > > you did not realize that if you _have to_ deal with   
   > > > segments (say for compatibility with 8086), then what   
   > > > 286 and 386 did is much better.   
   > >   
   > > I don't know what you are talking about. The usage of   
   > > segments that I described seems to be the most   
   > > appropriate solution.   
   > >   
   > > Are you talking about effectively having two executables   
   > > combined into one? I don't consider that to be superior   
   > > to the design I outlined.   
      
   > No. I mean that 286 gets rid of concept of "segment shift"   
   > and allows to place segment origin at arbitrary place.   
      
   This doesn't help me at all. I'm after a linear, unpaged   
   address space.   
      
   > Concernig "two executables combined into one", actual   
   > application code was one. But clearly, some low-level   
   > issues depended on processor. In ideal world such   
   > dependencies would be handled by OS. But DOS did not   
   > handle them.   
      
   I don't wish to be tied down by what MSDOS did. I'm   
   writing a competitor to MSDOS. I'm not going to change   
   anything arbitrarily, e.g. the INT 21H call that does a   
   write to a file, but if I need to change, I will.   
      
   > So programs bundled extention providing   
   > need OS support. Or if you prefer you can say that   
   > program bundled its own OS.   
      
   This is a good way of putting it, and something that   
   I wish to avoid, because I consider that to be dirty   
   executables. Even though I have difficulty defining   
   "dirty".   
      
   > Note that "bundling"   
   > was purely for convenience of users and distributors:   
   > instead of loading separate "DOS extender" users   
   > dealt with single program.   
      
   I'm happy to make it a requirement that the user   
   installs an appropriate DOS extender. And the right   
   version of MSDOS too, e.g. not 1.0.   
      
   > And if you go beyond DOS, early Windows contained   
   > appropriate support so the same applicatin could   
   > run in real mode or protected 16-bit mode.   
      
   I'm willing to go beyond DOS, but I'm only familiar   
   with Win32 console mode, not graphics, and not   
   16-bit Windows anything.   
      
   So if there is relevant technology that should interest   
   me here, please spell it out. If it's just another Microsoft   
   kludge, don't bother.   
      
   > > > [S/360]   
   > > > In instruction set, IBM missed PC relative instructions   
   > >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)