From: james.harris.1@gmail.com   
      
   On 12/06/2021 20:23, James Harris wrote:   
   > On 12/06/2021 20:06, James Harris wrote:   
   >> On Sunday, 26 April 2015 at 19:54:07 UTC+1, James Harris wrote:   
      
   >>> You know that, per Intel's directions, after setting the CR0 PE flag   
   >>> with   
   >>>   
   >>> mov eax, cr0   
   >>> or al, 1   
   >>> mov cr0, eax   
   >>>   
   >>> we are expected to have something like   
   >>>   
   >>> jmp seg:pmode_running   
   >>>   
   >>> I had taken that jump instruction for granted but the recent Qemu/GDT   
   >>> thread has brought up some issues about the jump, as follows.   
   >   
   > ...   
   >   
   >>>   
   >>> 3. That jump instruction has a 16-bit form and a 32-bit form. It is   
   >>> encoded in hex as   
   >>>   
   >>> EA oo oo ss ss (16-bit form)   
   >>> EA oo oo oo oo ss ss (32-bit form)   
   >>>   
   >>> where the Ss are the selector and the Os are the offset as hex bytes.   
   >>   
   >> The above info implies that it's the /short/ version of the jump which   
   >> is required.   
   >   
   > I found some code from AMD which confirms it.   
      
   A further point about the machine's state just after setting CR0 bit 0   
   and some queries which can be taken as rhetorical as they are somewhat   
   academic but may be of note nonetheless if you are interested in the detail.   
      
   It boils down to how instructions are decoded after setting CR0.PE.   
      
    From memory, it is advised to put a jump immediately after enabling   
   Pmode so as to flush the instruction pipeline on early processors 386,   
   486, and possibly Pentium before Pentium Pro. But is the pipeline   
   flushed before or after the jump is executed? IOW, is the jump itself   
   decoded in real mode or in PMode16 (the state the processor is put in by   
   the load of CR0)?   
      
   Perhaps all jump instructions assemble to the same bytes so it wouldn't   
   matter. Certainly a jump to the next instruction will be coded as EB00   
   in either 16-bit or 32-bit mode.   
      
   In fact, as the assembler (Nasm, in this case but the point is   
   presumably generally applicable) recognises only "bits 16" or "bits 32"   
   and not Rmode and Pmode perhaps instructions in PM16 decode exactly as   
   they do in Real mode.   
      
   But then if the encodings are the same then why would flushing the   
   instruction queue be necessary?   
      
   To be clear, where I believe a "bits 32" directive sits is /after/ the   
   far jump as in   
      
        mov cr0, eax ;Set bit 0   
        ... (potentially a large number of instructions)   
        jmp seg:offset   
      bits 32   
      offset:   
      
   It seems a bit of a conundrum and leads to the obvious question: exactly   
   what differences are there between instruction decoding in real mode and   
   in PM16 (the mode immediately after setting CR0 bit 0?   
      
   As I say, this is all largely academic but if you happen to know the   
   answer without doing any research do say as the details look interesting.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)