From: james.harris.1@gmail.com   
      
   On 13/03/2022 20:18, wolfgang kern wrote:   
   > On 11/03/2022 12:45, James Harris wrote:   
   >   
   >>>>>> For example, starting in real mode   
   >>>>>>   
   >>>>>>    mov ax, 7   
   >>>>>>    mov es, ax  <--- ok in real mode, sets ES /selector and base/   
   >>>>>>   
   >>>>>>    mov eax, cr0   
   >>>>>>    or eax, 1   
   >>>>>>    mov cr0, eax  <--- enter protected mode   
   >>>>>>    jmp $ + 2   
   >   
   >>> try this here:   
   >>> 0F 00 c8     STR ax   
   >>> You win this dispute if it doesn't crash :)   
   >   
   >> That's kind of you, Wolfgang, ... since it doesn't crash! :)   
   >>   
   >> When I tested it it set AX to 0 which is what one would expect to be   
   >> in TR's selector at reset.   
   >>   
   >> Why did you think it would crash?   
   >   
   > It would crash if in RM. So you're right and it is already in PM then.   
   > Interesting, which CPU have you tried on ?   
      
   I tried in VirtualBox first but as that's emulated I dug out an old test   
   machine which has an Intel Atom. Same behaviour on both.   
      
      
   > my notes for exactly this code on AMD 486 say: EXC_06 due to RM (~1994).   
   >   
   > [about data selector 07]   
   > ...   
   >>    mov cx, [fs:0]   
   >>   
   >> I tried that, too, and it works. The value copied from FS to DX is 7,   
   >> FS's selector which was the segment value loaded in RM and which   
   >> cannot be loaded in PM.   
   >   
   > you can load a data selector with 0000 also in PM   
   > but better never us it for any access.   
      
   I realised after posting that 7 was a poor choice of value in one way   
   but it turned out to be good in another.   
      
   It was a poor choice as it's a valid selector in Pmode. I should have   
   chosen 0 to 3 which are always invalid (in the sense of being inaccessible).   
      
   On the other hand it was a good choice as in Pmode it refers to the LDT.   
   There was no LDT so access via it would have failed in Pmode.   
      
   Either way, it shows that the processor was still using the segreg   
   settings (Base, Limit, Attributes) carried over from Rmode.   
      
   But I think we need to go a little further and say that once PE is set   
   the CPU will use the settings the BIOS left in the descriptor of that   
   segreg. Remember the model that in Pmode all four parts of the segreg   
   are loaded (selector, base, limit, attributes) whereas in Rmode only   
   selector and base are changed. If that's the case then when we get   
   control the hidden parts of the descriptor will not necessarily be   
   pristine as they would have been on reset but they will be whatever the   
   BIOS left there. All the more reason, then, to reload all segment   
   registers after setting PE=1.   
      
   >   
   >> Furthermore, the access to FS:0 also works without crashing. No   
   >> exception is generated.   
   >   
   > yes because it is still not modified after set PE.   
      
   Yes.   
      
   >   
   >> Try it. What do you get?   
   >   
   > no need, I know that. why I said it will crash:   
   > try your line after the final transition to PM.   
   >   
   >    mov cx, [fs:0]   ; if FS is 0007 then it will crash   
      
   You seem to agree elsewhere in your post that the CPU is in Pmode when   
   PE=1 so by "the final transition to PM" I presume you mean loading   
   segment registers to switch to /32-bit/ PM.   
      
   Primarily:   
     CS.B (aka "D") says whether the PM mode is 16-bit or 32-bit   
     SS.B says whether to use SP or ESP   
      
   the B bits in the other segment registers don't seem to matter much   
   unless the segment is expand down. Though it makes sense to fully reload   
   all segment registers if only to ensure we are starting from a clean   
   state with nothing left over from the BIOS.   
      
   ...   
      
   >>> you said that for CS earlier in this thread...   
   >>> and that's what I see unanswered.   
   >   
   >> I'll answer if I can but what is the question?!   
   >   
   > :) it was about: If it's in PM after setting PE then CS remain RM ?   
   > I can answer this now myself:   
   > all segment registers keep their base/limit as long not altered   
   > regardless of the PE-bit status.   
      
   Yes, I think that's the key to understanding this. For each segment   
   register the CPU uses Base, Limit and Attributes at all times and a   
   segreg load does:   
      
      if PE == 0 (* real mode *)   
        selector = segment value   
        base = segment value * 16   
      else if PE == 1 (* protected mode *)   
        selector = selector value   
        base, limit, attributes = from the descriptor   
      endif   
      
   To reiterate, AIUI in Real mode loading a segreg sets only Selector and   
   Base whereas in Protected mode it also sets Limit and Attributes.   
      
   For Intel and probably AMD it looks as though one can get the CPU to   
   report the Limit with an LSL instruction and the Attributes with LAR but   
   I don't know a way to get the base.   
      
   On Cyrix there's SVDC to write the entire Descriptor to ten bytes of memory.   
      
   ...   
      
   >> Again, that backs up my thesis: PM is defined by PE=1 and nothing   
   >> else. Nothing else had been changed.   
   >   
   > YOU WON. It took a while to convince myself to see it different yet :)   
      
   Thanks, though it wasn't a competition. Just an exploration of the topic.   
      
   >   
   >> Are you expecting those instructions to execute differently in PM16   
   >> compared with what they would do after setting PE=1 and before   
   >> reloading CS?   
   >   
   > I had some bad experience with featured switches back then, so finally   
   > every switch became less smart aka simple and was easier to handle too.   
   > Seems an old wiki note were burned into my brain:   
   > "the transition from RM to PM occur only on the final far jump"   
      
   I've heard similar. Perhaps whoever wrote that didn't know about PM16 -   
   which I also didn't until a few weeks ago.   
      
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)