From: nowhere@nevernet.at   
      
   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 ?   
   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.   
      
   > Furthermore, the access to FS:0 also works without crashing. No   
   > exception is generated.   
      
   yes because it is still not modified after set PE.   
      
   > 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   
      
   ...   
   >> it would crash for sure if run in PM (0007 isn't valid).   
      
   > Why would it crash? (As above, it doesn't.) The /selector/ is not used   
   > to access memory. The selector is only used to load the important parts   
   > of a descriptor (BASE, LIMIT and ATTRIBUTES) into the CPU. Once they are   
   > loaded future memory accesses can proceed without referring to the   
   > selector at all.   
      
   OK, not much sense to do it except to use FS as a temporary scratch pad   
   ...   
      
   >> 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.   
      
   > ...   
      
   >>>> not quite accurate, AMD-docs tell explicit that privileged instructions   
   >>>> work only in PM and not in UNREAL mode.   
   >>   
   >>> I'd like to see that. I've only been looking at Intel so far. Do you   
   >>> have a reference (manual and section)?   
   >>   
   >> I remember it well but forgot where I read it,   
   >> .. started to scan my docs ... >600 PDFs may take a while...   
   >> You might find this sentence in Intel-docs as well (not older than 486+)   
   >   
   > The word "unreal" doesn't appear anywhere in my full 7-volume set of   
   > Intel manuals. That's unsurprising as it's not really a separate mode,   
   > just Real mode with unusual limits in the segment descriptors. Maybe AMD   
   > is the same.   
   >   
   > To be clear, though, what's called "unreal mode" is really Real mode   
   > (PE=0) with unusual segment settings. No PM instructions should work.   
      
   Yes, UNreal starts with reset of PE and a far jump. So what I remembered   
   to read was right and privileged PM code wont run in (un)RealMode.   
      
      
   > But the state after setting PE and before reloading CS is not unreal   
   > mode. I suggest it's Protected mode but with D=0 hence 16-bit Pmode.   
      
   >>>> I didn't try by intention, but I remember some hard  crashes during   
   >>>> my first attempts (>30 years ago) on making mixed modes work.   
      
   >  From what I've seen, interrupts, in particular, could be 'challenging'   
   > with mixed segreg sizes.   
      
   Not that much of a challenge if you use my way:   
   all INT and IRQ use the same stacks the same variables and do exactly   
   the same in both RM, Unreal, P16M, PM32 and LM.   
   also all Exceptions from all modes were linked to a single debugger.   
      
   [...]   
   > 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 :)   
      
   > 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"   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)