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!/