home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,076 of 4,255   
   wolfgang kern to James Harris   
   Re: The EA jump immediately after enabli   
   13 Feb 22 22:14:11   
   
   From: nowhere@nevernet.at   
      
   On 13/02/2022 16:50, 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?   
   while trueRM is limited to FFFF:FFFF (aka HMA minus 16),   
   PM16 blocks can reside anywhere within 4GB.   
   ...   
   >> I could not see any protection on Data-ranges while in UnReal mode.   
   >> address beyond limits just wrap around (as it does within RM).   
   >> My Unreal DS is flat 4GB, but my stack is only 64K to match RM stack.   
      
   > Not sure what you mean but AIUI the B bit (big bit) of the SS descriptor   
   > selects the size of stack pointer (32-bit ESP or 16-bit SP) used for   
   > implicit stack references.   
      
   I use esp with upper half zeroed and 64k limit in the HMA for both RM   
   and PM32 because all my code in all modes share one single stack.   
      
   > Rather than having all segments 32-bit or all segments 16-bit it is   
   > looking more and more likely that a programmer could use any arbitrary   
   > mix of 16-bit and 32-bit segments - even on current processors - so   
   > having a 'big' code segment would make operands and addresses default to   
   > 32-bit while simultaneously having a 'small' stack segment would make   
   > implicit stack references use SP rather than ESP.   
      
   I have 16 bit RM code alive beside PM16, PM32 and LM64.   
   *true RM for BIOS calls and fastest hardware needs.   
   *UnReal during startup and mode switches   
   *PM16 as intermediate links and one protected core   
   *PM32 all OS specific   
   *LM64 except for the switches only used for user data.   
      
   > Further, loading CS with a selector for a 32-bit ('big') descriptor will   
   > only affect the code segment. One or more data segments could still be   
   > 16-bit.   
      
   been there :) it crashed if you leave data selectors RM styled.   
      
   > 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 ?   
   ....   
   >>>    mov al, [es: val]   
   >>> would include protection and range checks.   
      
   >> I can't confirm this, but to be honest I never tried by intention,   
   >> and I figured a typo with DS==0x2B instead of 0x28 after many years   
   >> w/o causing any access restrictions.   
      
   > OK. Using 2B rather than 28 (and I can see why they might be confused   
   > visually!) would set the bottom two bits which I think would give that   
   > selector user privilege rather than supervisor privilege.   
      
   >>> 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.   
      
   > Whoever wrote the Wikipedia article on Unreal mode seems to back up my   
   > supposition. After saying that Unreal mode is not really a separate   
   > addressing mode it says:   
      
   > ... the 80286 and all later x86 processors use the base address, size   
   > and other attributes stored in their internal segment descriptor cache   
   > whenever computing effective memory addresses, even in real mode.   
   >   
   > https://en.wikipedia.org/wiki/Unreal_mode   
      
   sure, this internal descriptors defaults to RM limits.   
   But too many gadgeteers and wannabees made wiki no more trustworthy,   
   all is pretty dated there anyway.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca