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