home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,103 of 4,255   
   James Harris to wolfgang kern   
   Re: The EA jump immediately after enabli   
   21 Feb 22 18:35:22   
   
   From: james.harris.1@gmail.com   
      
   On 21/02/2022 17:18, wolfgang kern wrote:   
   > On 21/02/2022 15:33, wolfgang kern wrote:   
   >   
   >>> If so, can you think of an instruction or sequence which would   
   >>> distinguish between the two?   
   >   
   >> give me some time to check in deep detail, I'll be back on this soon.   
   >   
   > here we go:   
   > this works in RM as long it points to an far RETURN:   
   > you can test this yourself   
   > 9A xxxx 0000 call far 0000:xxxx ;raise exception if PM   
   >   
   > PM only (raise invalid opcode exception in RM):   
   > 63 xx        ARPL  (seems obsolete)   
   > 0F 00 /1     STR   an easy test possibility ie:   
   > 0F 00 c8     STR ax |eax |rax   
   > 0F 00 08 xx  STR [mem16] ; all except RM   
   >   
   > 0F 00 /0     SLDT r16/r32/r64/m16   
   > 0F 00 /2     LLDT rm16   
   >   
   > 0F 00 /3     LTR   
   > 0F 02 /r     LAR   
   > 0F 03 /r,[m] LSL   
   >   
   > these work in UNreal after correct loaded   
   > 0F 00 /4     VERR   
   > 0F 00 /5     VERW   
      
   Sorry, I wasn't clear enough. What I was thinking about was a legitimate   
   instruction or sequence thereof which would work differently in RM and   
   PM16. ARPL and similar are not RM instructions.   
      
   For example, here's an instruction which is legitimate in both modes but   
   executes differently:   
      
      mov ds, ax   
      
   In PM16 it loads the hidden part of DS from the appropriate descriptor   
   table. In RM it doesn't.   
      
   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.   
      
   AISI the different behaviour of MOV DS, AX shows that the processor /is/   
   in Protected Mode, not Real Mode, even if it's PM16 rather than PM32.   
      
   IIRC you thought the processor would still be in RM. If I'm wrong,   
   therefore, perhaps you can think of another instruction (a legitimate   
   one) or sequence which could be executed after setting CR0.PE but before   
   loading CS which would tell whether the CPU was in RM or PM.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca