muta...@gmail.com  wrote:   
   > On Thursday, August 12, 2021 at 1:25:04 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
   > > muta...@gmail.com  wrote:   
   >   
   > > > > 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.   
      
   Cyber 6600 had it.   
      
   > 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.   
      
   x86 and S/370 have no relocation registers.  In case   
   of 360 it is not clear why.  One guess is that   
   IBM thought that "more is better" and assumed that   
   base registers will be more flexible than relocation   
   register.  Or they underestimated need to relocate   
   code.  8086 probably was intended to run single   
   program, so no need for relocation.  In case   
   of 8086 they added segmentation, and having   
   _both_ segmention and relocation  would be   
   a bit odd.   
      
   > 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.   
      
   In case of IBM there was a decree that basicaly forced   
   IBM to share technology with competitors.  And after   
   that a lot of compatible hardware.  Most notable   
   was Amdhal, but IIRC RCA and Siemens also had   
   compatible machine.  Eastern block build compatible   
   machines (architecture was copied, by hardware   
   design was original, to match available manufacutring   
   capabilities).   
      
   Cloners who diverged were loosing, "fully compatible"   
   ones winning.  For me it means either faitfuly clone   
   (including all known bugs), or go for completely   
   different design.   
      
   > > > > > 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.   
      
   Nobody puts arbitrary restriction for no reason.   
   But there are various more or less natural edge   
   cases.  Going from 16-bit addresses to 32-bit   
   doubles space taken by pointers, and either needs   
   extra hardware (wider buses and functional units)   
   or more clocks.  So there is substantial cost.   
   At hardware level wider bus means more cost.   
   So kludges to get more address bit at lower cost   
   looked attractive.  Similar thing partially   
   happended during 32 to 64 bit transition:   
   Intel machines for some time had PAE, which   
   allosed IIRC 36 physical address bits while   
   keeping application level at 32-bits.  And   
   basicaly Intel and ARM switched to 64-bit   
   at last possible time (Intel beted on   
   Itanium and was essentially forced by AMD   
   to current direction).   
      
   You may look at thread about 6502 in   
   comp.arch.  People speculate how 6502   
   could be improved, but given semiconductor   
   technology at that time it was hard to do   
   better.  And being late allowed use of   
   better (later) technology, but also meant   
   significant market disadvantage.   
      
   > > 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.   
      
   Sorry, I am not the right guy to explain advantages or   
   disadvantages of early Microsoft technology.  I simply   
   say that technology existed.  There were a lot of literature   
   so if you are interested you can dig relevant documentaion   
   and explanantions.   
      
   > > and program size, then you do not need PC relative   
   > > addressing. Igonring such issue may get you TSS-360.   
   >   
   > Ok, my interest is in placing the 3 MB GCC executable   
   > on unpaged memory and running it directly on the   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)