From: james.harris.1@gmail.com   
      
   On 12/02/2022 21:31, wolfgang kern wrote:   
   > 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:   
      
   ...   
      
   >> Why could it not be in PM running a 16-bit code segment?   
      
   ...   
      
   >>    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.   
      
   Not sure what you mean but AIUI the B bit (big bit) of the SS descriptor   
   selects the size of stack pointer (32-bit ESP or 16-bit SP) used for   
   implicit stack references.   
      
   Rather than having all segments 32-bit or all segments 16-bit it is   
   looking more and more likely that a programmer could use any arbitrary   
   mix of 16-bit and 32-bit segments - even on current processors - so   
   having a 'big' code segment would make operands and addresses default to   
   32-bit while simultaneously having a 'small' stack segment would make   
   implicit stack references use SP rather than ESP.   
      
   Further, loading CS with a selector for a 32-bit ('big') descriptor will   
   only affect the code segment. One or more data segments could still be   
   16-bit.   
      
   All this would make Real mode little more than a subset of Protected   
   mode. Or, put another way, one could say that Real mode *is* Protected   
   mode with:   
      
   1. certain values in the segment descriptors   
   2. different rules as to what it means to load a segment register   
      
   and very little else.   
      
   ...   
      
   >>    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.   
      
   OK. Using 2B rather than 28 (and I can see why they might be confused   
   visually!) would set the bottom two bits which I think would give that   
   selector user privilege rather than supervisor privilege.   
      
   >   
   >> 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  :)   
      
   Or PM16. :-)   
      
   Whoever wrote the Wikipedia article on Unreal mode seems to back up my   
   supposition. After saying that Unreal mode is not really a separate   
   addressing mode it says:   
      
   ... the 80286 and all later x86 processors use the base address, size   
   and other attributes stored in their internal segment descriptor cache   
   whenever computing effective memory addresses, even in real mode.   
      
   https://en.wikipedia.org/wiki/Unreal_mode   
      
      
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)