From: james.harris.1@gmail.com   
      
   On 07/03/2022 09:57, wolfgang kern wrote:   
   > On 05/03/2022 16:41, 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?   
      
   >   
   >>>>    mov ax, es   
   >>>> then that should put a 7 into AX even though the CPU is in Pmode.   
   >>>> Just for fun. :)   
   >>>   
   >>> yes of course, even a first attempt to access with ES would crash.   
   >>> I ask again what you assume to be: base limit and PL of this pre-PM.   
   >>   
   >> Well, I wouldn't /recommend/ writing code with such an access. It   
   >> would probably go against the specs and might be inconsistent between   
   >> processors. But if one did then here's what I think the basic   
   >> mechanism would be - as may be implemented by the CPU's engineers.   
   >   
   > A selector value 7 can't be accesses in PM (will raise an exception).   
      
   Be careful not to confuse loading with storing or using. A selector   
   value of 7 cannot be /loaded/ when in PM but it can be loaded before   
   switching to Pmode. Take this code:   
      
      mov ax, 7   
      mov fs, ax   
      
      mov eax, cr0   
      or al, 1   
      mov cr0, eax   
      jmp $ + 2   
      
      mov dx, fs   
      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.   
      
   Furthermore, the access to FS:0 also works without crashing. No   
   exception is generated.   
      
   Try it. What do you get?   
      
      
   > my question was about what you think is CS RM or PM limited ?   
      
   If I understood the question I'd try to answer it but I cannot parse it. :(   
      
   ...   
      
   >>    mov ax, [es:0]   
   >>   
   >> would, in the model, load AX with the contents of address 112 (the   
   >> base). But you say it would crash. Could that be because the limit   
   >> and/or the attributes did not permit the access?   
   >   
   > 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.   
      
   The memory address accessed is BASE + OFFSET where BASE is in the hidden   
   portion of the descriptor and OFFSET is in the instruction (0 in this case).   
      
   In Protected mode a load sets BASE and the other fields to whatever   
   values are read from the descriptor table.   
      
   In Real mode a load sets BASE to 16 * the segment and leaves the other   
   fields alone.   
      
   But once the fields of a descriptor have been set, memory accesses can   
   be carried out in the same way in either mode.   
      
   This is a remarkably simple model. And it's clean. There's no need to   
   make it complicated. Segreg loads operate differently in RM and PM but   
   once the load has taken place then the descriptor has all the info it   
   needs to handle future memory accesses without using the   
   segment/selector value as part of the access.   
      
   ...   
      
   > Yes, find tombstones in RAM of what the BIOS left behind after power up.   
   > I once copied first 128MB RAM to disk before loading all of my OS...   
      
   That's the kind of thing I would do. :)   
      
   ...   
      
   >> In Rmode moving 7 into ES would set the base to 112, AIUI, not   
   >> anything like 0x7c0.   
   >   
   >> By contrast, in Real mode loading ES with 0x07c0 would set the base to   
   >> 0x7c00 - exactly as required for RM operation.   
   >   
   > 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?!   
      
   ...   
      
   >>> 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.   
      
   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.   
      
   >   
   >>> So between setting PE and loading CS there is the UNREAL story where   
   >>> the CPU behave partly as PM (seg-regs) but wont execute PM only code.   
   >   
   >> Well, AIUI what's called "unreal" is the opposite: being in Real mode   
   >> (PE=0) but with unusual settings for the segments - typically a 4G   
   >> limit rather than 64k.   
   >   
   >> What specifically do you mean by 'PM-only code' that the CPU won't   
   >> execute?   
   >   
   > again:   
   > PM only (raise invalid opcode exception in RM):   
   > 63 xx        ARPL  (seems obsolete now)   
   >   
   > 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   
      
   OK. I haven't tested them all but as above, STR executes. Further, so   
   does LSL. And Intel is very clear:   
      
      "The LSL instruction is not recognized in real-address mode"   
      
   Again, that backs up my thesis: PM is defined by PE=1 and nothing else.   
   Nothing else had been changed.   
      
   Are you expecting those instructions to execute differently in PM16   
   compared with what they would do after setting PE=1 and before reloading CS?   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)