Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!spar!kissell From: kissell@spar.UUCP (Kevin Kissell) Newsgroups: net.micro Subject: Re: Intel 286 microprocessor problems Message-ID: <3@spar.UUCP> Date: Thu, 13-Dec-84 16:08:42 EST Article-I.D.: spar.3 Posted: Thu Dec 13 16:08:42 1984 Date-Received: Sat, 15-Dec-84 02:06:57 EST References: <2672@cornell.UUCP> <20300017@okstate.UUCP> Organization: Schlumberger Palo Alto Research, CA Lines: 25 > The word is that the 386 will > operate in 2 modes. The first being segmented and compatible with the > rest of the family, and the second being a direct access mode allowing > non segmented operation throughout the addressing space. Well, I attended a seminar in Santa Clara on future intel products some months ago, and the story *then* was that the 386 would have 3 modes of operation: An unmapped, vanilla 8086 mode, a 286 mode, and a 386 mode, each selected by mode control bits in the PSW. In 386 mode, it was still to be a segmented machine, BUT the segment offsets specified in an instruction were to be 32 bits instead of the traditional 16 bits. Thus each segment is effectively 4 Gigabytes, which is pretty reasonable. The segment registers themselves add even more bits to each virtual address, and they talk of multi-terabyte virtual address spaces, but the physical address space will be smaller. Of course, it'll be a tough job just building a machine with the performance characteristics that they are promising for the 386 without carrying all that compatibility baggage around. It won't surprise me in the least if they have to back off somewhat. Kevin D. Kissell Fairchild Advanced Processor Development uucp: {ihnp4 decvax}!decwrl!\ >spar!kissell {ucbvax sdcrdcf}!hplabs!/