From: james.harris.1@gmail.com   
      
   On 24/02/2022 17:51, wolfgang kern wrote:   
   > On 22/02/2022 11:12, James Harris wrote:   
   >> On 21/02/2022 20:42, wolfgang kern wrote:   
   >>> On 21/02/2022 19:35, James Harris wrote:   
   >>   
   >> ...   
   >>   
   >>>> What I am trying to prove is that once CR0.PE is set (and prefetch   
   >>>> queues flushed) the processor will be in PM, not RM, even _before_   
   >>>> CS is reloaded.   
   >>   
   >> ...   
   >>   
   >>> assume or make your RM-CS 07c0 before the switch   
   >>> and try this after it:   
   >>>   push cs   
   >>>   pop ax   ;ax show the RM-segment and nothing else   
   >>   
   >> If the /user-visible/ part of CS is 07c0 then wouldn't that end up in   
   >> AX in either mode?   
   >   
   > Only in RM but not within PM, here AX would show a descriptor value.   
      
   Wouldn't AX hold the selector - 16 bits? Descriptors are too wide for AX.   
      
   In fact, there's a diagram for early CPUs which I've not seen for later   
   ones. It sets out the /internal/ structure of segment registers as they   
   were at the time. It shows CS, DS, etc as 64-bit where the top 16 bits   
   are the visible selector. Full contents:   
      
   * 16 bits: selector        <-- the bits we see in the segreg   
   *  8 bits: access rights   
   * 24 bits: base address (24 being all that was needed in days of yore)   
   * 16 bits: segment size (by which I think they mean 'limit')   
      
   That's from Figure 6·8 Memory Management Registers of 80286 AND 80287   
   PROGRAMMER'S REFERENCE MANUAL 1987.   
      
   These days they are a little wider but a "MOV AX,DS" instruction will   
   still copy just the 16-bit selector field to AX.   
      
   The converse "MOV DS,AX" instruction will copy AX to the DS selector   
   field and, in PM, load the other fields from the descriptor table   
   whereas in RM it will load the base with 'selector shl 4' (see below).   
      
   ...   
      
   >> Consider an instruction such as   
   >   
   >>    mov ds, ax   
   >>   
   >> In Protected Mode that would do   
   >>   
   >>      DS.base = from descriptor   
   >>      DS.limit = from descriptor   
   >>      DS.access_rights = from descriptor   
   >>   
   >> Wouldn't it make sense for the same instruction in Real Mode to do as   
   >> follows?   
   >>   
   >>      DS.base = AX shl 4   
   >>      DS.limit = 0xffff   
   >>      DS.access_rights = unrestricted   
      
   It turns out to be even simpler. According to the document below, in   
   Real Mode Intel CPUs load only the base, leaving limit and access_rights   
   unchanged.   
      
   To quote: "In real mode, when a segment register is loaded, only the   
   base field is changed, in particular the value placed into the base is   
   selector*16."   
      
   >>   
   >> Then the same architectural parts (the hidden parts) could be used in   
   >> either RM or PM. That would keep the hardware design simpler and more   
   >> consistent than having two entirely separate modes.   
   >   
   > X86 grew up in large steps, so we see historical remains here and there.   
   >   
   >> In fact, surely the so-called Unreal Mode only works because the CPU   
   >> uses the hidden parts of the segment registers at all times - even   
   >> when in Real Mode (PE=0).   
   >   
   > yes, Unreal may not be designed by intention, but it became handy :)   
      
      
   Yes, and Unreal Mode shows that CPUs use PM mechanisms AT ALL TIMES,   
   even when they are running in what we call "Real Mode".   
      
   I found a great writeup of Unreal Mode at   
      
      http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/   
      
   It includes sources which make clear that in Real Mode only the base   
   address can be changed so, as it says, "8086-compatible  attributes must   
   be loaded into the data segment descriptor registers before switching to   
   real mode".   
      
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)