From: muta...@gmail.com   
      
   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.   
      
   > 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.   
      
   > 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.   
      
   > If I was in business of correcting history, I would probably   
   > add "VM86" mode to 286. Of course, big point of VM86 is   
   > ability to use paging. But even limited mode allowing to   
   > run 8086 programs in first 1M of memory while keeping   
   > everything under control of protected mode OS could   
   > speed up transition to protected mode.   
      
   You can do both. Provide the technical ability to do   
   various options, give your recommendation, and let   
   individuals decide.   
      
   Roll on Zhaoxin.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|