Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!aplcen!haven!wam!walrus From: walrus@wam.umd.edu (Udo Karl Schuermann) Newsgroups: comp.sys.ibm.pc Subject: Re: 32-bit addressing on the 80386 in real mode?!? Summary: Real mode registers are 16 bit Keywords: 80386, 32-bit, Real mode Message-ID: <1990Jan18.055726.20604@wam.umd.edu> Date: 18 Jan 90 05:57:26 GMT References: <8342@portia.Stanford.EDU> Sender: usenet@wam.umd.edu (USENET Posting) Reply-To: walrus@cscwam.umd.edu (Udo Karl Schuermann) Organization: University of Maryland at College Park Lines: 49 In article <8342@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: > > I think I might have found a trick for allowing 32-bit addressing >in real mode on the 80386. According to a book I have on the 80386, >real mode address calculations pass through the same memory management >hardware as in protected mode. When the 80386 is reset, it loads the >segment descriptor cache registers with sets of attributes that make >all the segment registers behave as if they were 8086-type segments. >When switching from protected mode BACK to real mode, the book says >that the descriptor cache registers all have to be re-loaded with >attributes appropriate for real mode - i.e., the 80386 does not reset >the attributes on its own. These attributes include the 64K segment >limit. So, I thought, it should be possible to switch to protected mode >for a moment, set up the segment descriptor cache to look like real mode >EXCEPT that the limit fields are set to 4 Gbytes, then pop back into real >mode. The descriptor cache should be locked in real mode, so from that >point on, big offsets should work without causing protection violations. >However, I haven't been able to get it to work. I can switch into and >out of protected mode OK, and initialize the segment descriptors OK, but >the 64K offset limit still seems to be enforced when I get back to real >mode. So... is the book wrong? Am I missing anything trivial? Do some >real-mode events cause the descriptor cache to be re-initialized, like >interrupts or far jumps? Or am I just wasting my time? > >- David Hinds > dhinds@portia.stanford.edu I don't have any literature on the '386 but let me take a shot at this. In protected mode, segment and offset registers are 32 bits long. This produces a 4 GByte address range. In real mode, the registers are only 16 bits long, and in addition, the segment and offset registers overlap such that the total number of bits used is not the sum of 16 + 16 being 32 bits but only 20. This has the unfortunate (and often confusing) side-effect of giving you 16 different addresses for each byte in the real mode address space. That aside, any existing real mode programs would be utterly unprepared to have their addresses suddenly interpreted in ways that their authors didn't intend. I'm sure I'm not quite right in some of my reasoning, but this is probably close enough, especially since I've got no docs on the '386 :) Any gurus to set the record straight(er)? -------------------------------------------------------------------------- Udo Schuermann // "The power to destroy a thing is the walrus@cscwam.umd.edu \X/ absolute control over it." -- Frank Herbert --------------------------------------------------------------------------