From: james.harris.1@gmail.com   
      
   On 16/02/2022 03:01, wolfgang kern wrote:   
   > On 14/02/2022 17:10, James Harris wrote:   
   >   
   >>>>>> Why could it not be in PM running a 16-bit code segment?   
   >   
   >>> at which address would you see such PM16 code?   
   >   
   >> Within range 0 to 64k. See below.   
   >   
   > this would mean starting from 0000:0000   
   > but what value will the CS descriptor have then ?   
      
   Your question may be rhetorical but if not then I'd say that the CS   
   descriptor would have the D bit (the B bit by any other name) as zero.   
      
   >   
   >>> while trueRM is limited to FFFF:FFFF (aka HMA minus 16),   
   >>> PM16 blocks can reside anywhere within 4GB.   
   >   
   >> I don't think so: PM16 is limited to 64k code segments. The following   
   >> is from the 80286 documentation.   
   >   
   >> The programmer views the virtual address space on the 80286 as a   
   >> collection of up to sixteen thousand linear subspaces, each with a   
   >> specified size or length. Each of these linear address spaces is   
   >> called a segment. A segment is a logical unit of contiguous memory.   
   >> Segment sizes may range from one byte up to 64K (65,536) bytes.   
   >   
   > me too owe ye olde 286 manuals.   
      
   If you want to find definitions of ye olde PM16 then ye olde manuals are   
   the place to look. :)   
      
   > but later stuff said:   
   >   
   > Protected Mode.   
   > In this mode, the processor supports virtual-memory and physical-memory   
   > spaces of 4 Gbytes and operand sizes of 16 or 32 bits. All segment   
   > translation, segment protection, and hardware multitasking functions are   
   > available. System software can use segmentation to relocate effective   
   > addresses in virtual-address space. If paging is not enabled, virtual   
   > addresses are equal to physical addresses. Paging can be optionally   
   > enabled to allow translation of virtual addresses to physical addresses   
   > and to use the page-based memory-protection mechanisms.   
      
   I can't see the relevance of that. If it's not clear, the point in what   
   I posted from the 80286 manual was:   
      
      "Segment sizes may range from one byte up to 64K (65,536) bytes."   
      
   IOW PM16 segments cannot be larger than 64k so when you say that PM16   
   blocks can be anywhere in 4GB then I don't think that can be right. It   
   is true of what's called Unreal Mode (386 and above) but not of PM16   
   (286 and above).   
      
   If you mean PM16 "segments" then I think that still cannot be right.   
   PM16 is limited to 24 bits.   
      
   ...   
      
   >>>> All this would make Real mode little more than a subset of Protected   
   >>>> mode. Or, put another way, one could say that Real mode *is*   
   >>>> Protected mode with:   
   >   
   >>>> 1. certain values in the segment descriptors   
   >>>> 2. different rules as to what it means to load a segment register   
   >   
   >>> just a point of view matter ?   
   >   
   > I see it the other way: PM came a long while after RM.   
   >   
   >> To me this is more about gaining an insight into what is likely   
   >> happening inside the processor, and thereby making it easier to   
   >> understand.   
   >   
   > But not much to learn if you're stuck with 286 ...:)   
      
   Well, don't modern CPUs still support the 80286's PM16, and isn't PM16   
   the mode that they are switched in to when CR0.PE is set before any   
   segment register is loaded?   
      
   >   
   >>>>>> Furthermore, you could consider that accesses off DS would also   
   >>>>>> include checks but that the internal descriptor would have the   
   >>>>>> limit set to 0xffff so nothing would be out of range.   
   >   
   >>>>> You could setup smaller than 64K limits on Unreal Data segments.   
   >>>>> this might raise a real mode exception because still in RM  :)   
   >   
   >>>> Or PM16. :-)   
   >   
   >>> :) look at the AMD pages which lists RM<>PM instruction differences,   
   >>> and then check on a few to see if it is in RM or PM16.   
   >>> hint: some instructions are privileged and a few aren't allowed.   
   >   
   >> What about RM code? ISTM that a lot of RM code could work unchanged in   
   >> PM16.   
   > again: look at privileged instructions, work in RM but may fail in PM.   
      
   RM would have to work very hard to have privileged instructions. ;-)   
      
   Everything I've found recently suggests that after CR0.PE is set (and   
   the prefetch queue flushed if necessary) the processor will be in   
   Protected Mode whereas you, IIUC, are sure it would remain in Real Mode   
   until CS is reloaded.   
      
   If so, can you think of an instruction or sequence which would   
   distinguish between the two?   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)