From: james.harris.1@gmail.com   
      
   On 25/02/2022 15:31, James Harris wrote:   
      
   ...   
      
   > Yes, and Unreal Mode shows that CPUs use PM mechanisms AT ALL TIMES,   
   > even when they are running in what we call "Real Mode".   
      
      
   This has been a very revealing foray into what has to go on inside a CPU   
   in each step of enabling PMode. The surprising thing is how simple each   
   step is.   
      
   Here's a summary of where I've got to:   
      
      lgdt   
      
   That loads one register, the GDTR, and so tells the CPU where to look   
   for the Global Descriptor Table when we load a segment register in PMode.   
      
      cli   
      
   That sets a single bit in EFLAGS. It's recommended because we are about   
   to change /how interrupts are handled/ and so don't want an interrupt to   
   fire asynchronously mid change.   
      
      or eax, 1   
      mov cr0, eax   
      
   That sets a single bit in CR0 (the PE bit). Setting that bit _fully_   
   enables PMode. What magic does it do? What else does the CPU do at this   
   point other than set the bit? AFAICS, absolutely nothing! Zilch! Nada!   
      
   What that bit being set does, however, is affect future behaviour. Once   
   the bit is set the processor will respond differently in certain cases   
   such as loading a segment register or responding to an interrupt. But   
   nothing other than the bit changes immediately, and that bit being set   
   means the CPU /is/ in PMode.   
      
      jmp flushed   
      
   That jump (typically to the next instruction) changes no architectural   
   state and it's not even needed on modern CPUs. All it does is flush the   
   prefetch queue on early processors which don't do so automatically. Most   
   decodes are the same in either mode so it would likely only matter if a   
   segment register were to be loaded in the next few instructions. (But a   
   jump is, of course, still right to include in all cases for portability.)   
      
   As said, we will already be in PMode but it will be PM16 and we   
   typically want to use 32-bit accesses.   
      
      mov ds, bx   
      
   That would load DS with whatever base, limit and control bits we have   
   put in the selected descriptor - typically changing the limit field of   
   the segment from 0xffff to 0xffff_ffff although if we update DS before   
   CS then accesses to the segment would still, by default, use 16-bit   
   offsets: it doesn't make a lot of sense to load DS only but I put it   
   first, here, to emphasise that it is possible.   
      
      jmp codeseg:pm32start   
      
   That would load CS with whatever base, limit and control bits we have   
   put in the selected descriptor. (IOW essentially the same as loading a   
   data segment register.)   
      
      bits 32   
      pm32start:   
      
   I add those just to emphasise that although we would be in PMode as soon   
   as PE is set it would be PM16 and it's only from the label that the   
   instruction stream would be 32-bit PM32.   
      
      
   While in PMode we can switch in either direction between 16-bit and   
   32-bit code (both still in PMode, i.e. we can switch between PM16 and   
   PM32) simply by loading CS (using jump, call or task switch) with a   
   descriptor which has the D bit clear or set, as required.   
      
   CS.D sets the default address and operand sizes. SS.B sets whether SP or   
   ESP is used in stack operations such as pushes, calls, returns and pops.   
   And the B bit on other segment registers (such as DS.B) is ignored.   
      
      
   The above all comes with disclaimers but it's simple and flexible,   
   consistent with documentation, and it makes sense because as per Occam's   
   Razor there's no need to make things any more complex. So I offer it as,   
   if nothing else, a potential way to understand the internals of the   
   transition to PM32.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)