From: nowhere@nevernet.at   
      
   On 12/02/2022 17:35, James Harris wrote:   
   > On 12/02/2022 12:01, wolfgang kern wrote:   
   >> On 12/02/2022 12:08, James Harris wrote:   
   >> ...   
   >>>> 2. setting PE does nothing on its own, the CPU remain in real mode   
   >>>> until   
   >>>>     the far jump which changes interpretation from segment to   
   >>>> descriptor.   
   >>>>     and its a 16:16 code without prefix   
   >>   
   >>> I am not sure that's right, Wolfgang. I am beginning to think that   
   >>> once PE is set the processor will be in 16-bit Protected Mode (PM16);   
   >>> in that mode the encoding of instructions will be identical to RM;   
   >>> and the main differences will be when loading segment registers.   
   >>> There may also be some differences when /using/ segment registers but   
   >>> see below.   
   >> ...   
   >>>    mov ds, ax   
   >>>    ... DS now has base, limit and protections as loaded from GDT   
   >>>   
   >>> That's it. Feel free to disagree.   
   >>   
   >> Yeah you're partly right :) the CPU isn't in PM unless you alter CS.   
   >   
   > Why could it not be in PM running a 16-bit code segment?   
   >   
   > Remember the isolated nibble in the IA32 descriptor just after   
   > Base31::24. Its bits can be seen as   
   >   
   >    GWZA   
   >   
   > where   
   >    G = Granularity   
   >    W = Wide (0 means a 16-bit segment - yes, even in Pmode)   
   >    Z = Zero   
   >    A = Available for system programmer to use   
   >   
   > That bit must be zero on the 286. Even on 386+, however, with W = 0 you   
   > would still have a 16-bit segment. The default size of addresses and   
   > operations would be 16-bit and I gather it would operate just as Real   
   > Mode does except when segment registers are written to.   
      
   I could not see any protection on Data-ranges while in UnReal mode.   
   address beyond limits just wrap around (as it does within RM).   
   My Unreal DS is flat 4GB, but my stack is only 64K to match RM stack.   
      
      
   >> but write to a data segment register invokes UNREAL mode.   
   > OK.   
   >> the only thing which is different with a set PE-bit is interpretation   
   >> changes from segment to descriptor but only when segreg is written to.   
   > Yes, that's what I was suggesting. And it would only matter when a   
   > segreg is loaded.   
      
   >> As long CS remain untouched there are no privilege checks, so it acts   
   >> like in real mode for ALL "otherwise protected" instructions.   
   >> That's why I said the change occur only on write CS.   
   >> OK I forgot the UNREAL exception here even I use that a lot.   
   >   
   > Even with no change to CS wouldn't there be protection checks on data   
   > accesses which have had their segment registers loaded? For example,   
   > consider loading just ES as in   
   >   
   >    lmsw ax   ;Switch to Pmode   
   >    jmp $ + 2   
   >    mov ax, 16   
   >    mov es, ax   
   >   
   > After that I'd suggest that even though CS has not been reloaded   
   >   
   >    mov al, [es: val]   
   >   
   > would include protection and range checks.   
      
   I can't confirm this, but to be honest I never tried by intention,   
   and I figured a typo with DS==0x2B instead of 0x28 after many years   
   w/o causing any access restrictions.   
      
   > Furthermore, you could consider that accesses off DS would also include   
   > checks but that the internal descriptor would have the limit set to   
   > 0xffff so nothing would be out of range.   
      
   You could setup smaller than 64K limits on Unreal Data segments.   
   this might raise a real mode exception because still in RM  :)   
      
   > Put another way, PM16 would look very like RM but it would not be RM   
   > because loads of segment registers would have a different meaning; and   
   > the only difference between RM and PM16 would be in how loads of segment   
   > registers are carried out.   
   >   
   > You say the CPU would still be operating in Rmode. I am putting forward   
   > a suggestion that it would, in fact, be operating in Pm16 but that the   
   > two are so similar that a lot of code would operate as though the CPU   
   > were still in Rmode.   
      
   try forcing exceptions in Unreal mode to see which handlers react.   
      
   > It makes sense! :-)   
      
   OK, some very old stuff may work different...   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)