Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcsri!utegc!utai!anton From: anton@utai.UUCP Newsgroups: comp.arch Subject: Re: 64 Vs 32 (386 addressing) Message-ID: <3804@utai.UUCP> Date: Sun, 22-Mar-87 22:12:13 EST Article-I.D.: utai.3804 Posted: Sun Mar 22 22:12:13 1987 Date-Received: Sat, 28-Mar-87 09:47:09 EST References: <3810013@nucsrl.UUCP> <28200016@ccvaxa> <4372@utcsri.UUCP> <390@nvanbc.UUCP> Reply-To: anton@utai.UUCP (Anton Geshelin) Distribution: world Organization: CSRI, University of Toronto Lines: 50 Summary: 386 segment desriptors In article <390@nvanbc.UUCP> lawrenc@nvanbc.UUCP (Lawrence Harris) writes: >In article <4372@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >>In article <28200016@ccvaxa> aglew@ccvaxa.UUCP writes: >> >>An inference: from the description in the article, I have to conclude >>that the 386 has its own instruction set ( the 286 opcode space is too >>full, and does not contain the kind of instructions that you would want >>in a 32-bit machine, or the addressing modes described in the article). >>Thus the 386 has two instruction modes (386/286 opcodes). I imagine the >>286 instructions are available with different encoding (and probably >>different addressing) within the 386 set. Maybe they'll make one that >>runs 6502 code too so we can make Apple-compatible PC's. >> >No, the 386 uses the same binary instruction encoding as the 286. It >adds a new mode byte for extended addressing modes, and a bit in the >segment descriptor for a code segment which tells the processor whether >the code in this segment is to be 16 or 32 bit integer. There is also >a prefix byte to switch an individual instruction to the opposite size. Intel was planning ahead when they designed the 286, or perhaps the 286 was just a temporary measure before the 386 arrived. Intel reserved an extra word(16 bits) and a few more bits in the segment descriptors of the 286. In the 386 the first 16 bits go to extend the offset of the segment to 32 bits (this is ignored, forced to 0, in the 286). There is also a reserved bit elsewhere in the descriptor. It becomes the granularity bit. Hence, you can calculate the segment size in bytes or pages. There are extra 4 bits for segment size. >I am told that XENIX V/286 runs on the Compaq 386 right out of the box >so the cpu's must be very compatable at the binary level. > XENIX V/286 uses a subset of 386 segment desriptors, precisely the 286 subset (with all Intel reserved bits set to 0). >Also there is another bit which says whether the segment size is in bytes >or increments of (I think) 16 bytes, this is how you can have segments up >to 1Mb now. > We can have segments of 1M units (16 bits from 286 and 4 new bits in 386 = 20 bits total). With granularity bit set to 0 (as in 286) this becomes 1Mb. Otherwise, it is 1M pages or 1M * 4096b/page = 4Gb for full 32 bit addressing. This is very clever, since it allows to have the natural memory protection mechanism (segmentation) sitting on top of paged virtual memory. >I believe there was a recent article in byte magazine on the 386. I am posting this because I have not seen a single correct description of 386 memory management mechanism on the net, yet. However, I wrote this from memory without consulting my 386 book.