muta...@gmail.com  wrote:   
   > On Wednesday, October 12, 2022 at 9:33:38 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   > > muta...@gmail.com  wrote:   
   > > > On Monday, October 10, 2022 at 6:18:47 PM UTC+8, Joe Monk wrote:   
   > > > > > Not sure what you're talking about.   
   > > > > >   
   > > > > > This is a once-off instruction to be executed.   
   > > > > >   
   > > > > Says who? What will stop me from executing it any time I want?   
   > > >   
   > > > Nothing will stop you, but I doubt it will do   
   > > > anything useful when the os has loaded all it's   
   > > > content with a particular shift   
   > > > value in effect and you choose   
   > > > to switch it.   
   > >   
   > > Hmm, you said you do not want mode bits (to switch between   
   > > real/protected, etc). But now you what you propose is   
   > > mode bit. So, do you like mode bits or no?   
   >   
   > This is not a mode bit, it is a value (from 0-16).   
   > Not much different from setting a segment   
   > register to a value (and suddenly indexes using   
   > dx or whatever goes to a different address).   
   >   
   > Regardless, if you wish to have a semantic debate -   
   > you win - I was a complete dickhead for previous   
   > comments about modes, and I actually love modes.   
   >   
   > > Intel did not do that, and at least part of this was politics:   
   > > they did _not_ want 32-bit capable real mode. Instead   
   > > they wanted people to switch to protected mode.   
   >   
   > I'm not interested in politics, and I don't care what   
   > Intel do with their duopoly - I'll work with the   
   > Chicoms on Zhaoxin instead.   
   >   
   > > Coming back to modes: main problem with modes is that various   
   > > applications "live in different words", you can not simply   
   > > call function in binary library compiled for different mode,   
   > > you need to recompile or have some wrapper code handling   
   > > mode switching.   
   >   
   > Not correct. C-generated code doesn't manipulate the   
   > segments at all - and even in huge memory model the   
   > manipulation can be done by an OS-provided routine   
   > so that it works in protected mode too.   
   >   
   > It will be completely unaware that a shift value of 5 is in effect.   
      
   I do not think so.  Note that I wrote "binary".  If you have   
   source you can recompile and machine architecture does not   
   matter.  If you have binary, even output of a C compiler you   
   can not make assumptions about output, AFAIK all C compilers   
   allow programmer enough freedom to break rules.  Now, look at   
   a C string "Hello" : at machine level in large mode it is   
   represented by segment and offset pair, say 4a86:8086.  In   
   function using segment shift 4 it points to different memory   
   area than say segment shift 5 would give.  So, to have ability   
   to call you need single value of segment shift.  But if you   
   try to run binary created for one segment shift value, Murphy   
   law says that it will not run with different value, unless   
   programmer did extensive testing with both value.  To put   
   it differently, single bad spot can break program and you need   
   enough testing to ensure that no such bad spot.   
      
   Concerning huge mode: having function call for array indexing   
   is performance killer, people who care about performance   
   issues would not accept this.  Of course, if you are willing   
   to run your programs under Bochs, then performance loss due   
   to function call is relatively speaking "small issue".   
      
   > > emulation. Basically world is ready to remove real mode   
   > > from processors.   
   >   
   > Perhaps most of the world.   
   >   
   > > You say that Intel should keep real mode alive, but most   
   > > people think that we are in better world now.   
   >   
   > Most people have not even bothered to visit   
   > the fundamentals of segmentation.   
   >   
   > Most people watch sport.   
   >   
   > Most people believe in gods.   
   >   
   > Most people are morons.   
   >   
   > You need to challenge my ideas on their merits,   
   > not resort to argumentum ad populum, which   
   > has zero effect on me.   
      
   You do not get it: you say that Intel is monopoly.  But they are   
   commericial company and must look at what customers want.  And   
   in this case they did what majority of customers wanted.   
      
   > > That was   
   > > long transition. And efforts to keep real mode alive probably   
   > > would make it slower and more painful.   
   >   
   > I don't even know what that means. If everyone already   
   > agrees that real mode should die, they can simply stop using it.   
   >   
   > The fact that Intel has to force people, using their monopoly position,   
   > just shows you that monopolies suck.   
      
   Well, my transition was relatively fast: first PC that I owned   
   was a 486.  I installed DJGCC and could you 32-bit mode for   
   my own code.  I also sterted using 386BSD which was pure 32-bit   
   code.  More precisely, boot sector (one for floppies and another   
   one for HDD-s) first switched processor to 32-bit mode and then   
   rest of boot and all OS-work was 32-bit.  After switching to   
   32-bit mode BIOS was unused (ignored).  A bit later I switched   
   to Linux.  Linux compromise a bit: boot sector was 16-bit and   
   there was some play to use VGA BIOS to initialize graphic   
   cards.  And there was dosemu which used VM86 to run 16-bit DOS   
   programs.  Basically in 1993 Linux was my main system (but   
   I had dual boot system for long time so I could run DOS   
   programs that did not run in dosemu).   
      
   But most people were in different position.  They had 16-bit   
   real mode binary programs.  They needed to run them.  So for   
   them it was essential to have VM86 to be able to run existing   
   binaries.   
      
   When we speak about monopolies: essentially any software provider   
   is a monoply.  If you have say "Silly Editor Mark II" and you   
   like its key binding and the way it works, than different   
   editor is _not_ a full replacement.  You need _exactly_ the   
   same behaviour.  Replicating behaviour with high accuracy   
   is large effort, larger than writing software first time.   
   So normally it is not done and vendor has monopoly.  Intel   
   monopoly is really just consequence of those many software   
   monopolies and unwillingness of monopolists to support   
   other platforms.  And concerning "forcing", one thing is   
   providing clear migration path.  Intel at first did the same   
   mistake that you are doing: they assumed that programs will   
   be well-written and that vendors would do adaptions to   
   segmented protected mode.  With 386 thay saw that this is   
   not working as hoped and they introduced VM86 and paging.   
   VM86 gave much better compatiblity.  Paging is more efficient   
   than segmentation and _simpler_ to implement without   
   excessive waste.  Namely, unmovable segments lead to memory   
   fragmentation and inefficient allocation (segments must be   
   big enough to handle maximal possible demend as opposed to   
   actual demand).  Movable segments (possible in 286 protected   
   mode, impossible with your "segment shift") require code in   
   OS to move them (and presumably some care to avoid excesive   
   movement).  Pages allow very simple allocation/deallocation.   
   So Intel provided all what was needed for smooth transition.   
   Now, why _not_ providing alternatives was helpful?  Part is   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)