From: james.harris.1@gmail.com   
      
   On 26/02/2022 22:13, wolfgang kern wrote:   
   > On 26/02/2022 18:04, 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   
   >>   
   >>    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.   
      
   The thing to bear in mind that segment registers have multiple fields,   
   most of which are hidden in Rmode. One could consider ES as having these   
   parts:   
      
      ES.selector   
      ES.base   
      ES.limit   
      ES.attributes   
      
   The only part we normally see is the selector.   
      
   Given that model of a segment register, the code   
      
      mov ax, 7   
      mov es, ax   
      
   when run in Rmode would have the following effect   
      
      ES.selector = 7   
      ES.base     = 112 (7 times 16)   
      
   and, importantly, _nothing else_. It would only change the selector and   
   the base. It would not alter the other parts of ES. Hence they would   
   retain the values they had before, i.e.   
      
      ES.limit      = whatever was there from before   
      ES.attributes = whatever was there from before   
      
   Therefore, if ES.limit was large enough and ES.attributes allowed the   
   access then   
      
      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?   
      
   Remember that although the CPU powers up in Real mode and is typically   
   in Real mode when we get control it has probably taken a trip to Pmode   
   and back since being booted. If nothing else, the BIOS has to change to   
   Pmode (set PE = 1) so it can check the RAM.   
      
   In Pmode, the BIOS will have been able to control what is loaded into   
   base, limit and attributes of the segment registers. We don't know what   
   that will have been but we can guess at what's likely. When it changes   
   back to RM to boot our code it will probably have set   
      
      limit      = 64k   
      attributes = writable, present, expand up, byte granularity, etc   
      
   With those values the segment register's hidden parts will be correctly   
   set for Rmode operation. In Rmode, loads of segment registers will only   
   have to change selector and base.   
      
   >   
   > if the base would be 0000 or 07C0 then non of my switches would work.   
   > and why should it be 07c0 ?  my switches aren't in this region.   
      
   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.   
      
      
   >   
   >>>> Yes, and Unreal Mode shows that CPUs use PM mechanisms AT ALL TIMES,   
   >>>> even when they are running in what we call "Real Mode".   
   >>>   
   >>> If it would be in PM then all the PM instructions I listed earlier   
   >>> would not crash or raise exceptions. Go figure :)   
   >>   
   >> AIUI - at least on Intel - the instructions you listed should all   
   >> execute if PE = 1 and raise exception 6 if PE = 0. Is that not what   
   >> happens on your hardware?   
   >   
   > 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 didn't try by intention, but I remember some hard  crashes during my   
   > first attempts (>30 years ago) on making mixed modes work.   
   >   
   > 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?   
      
   I could see a chip manufacturer /adding/ limitations on what can be done   
   in each mode (as Intel have done, e.g. in detecting invalid opcodes) but   
   they would had had to add those on top of the basic mechanisms.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)