Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!pesnta!amd!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.arch,net.micro,net.micro.pc,net.micro.68k
Subject: Re: Re: Re: Re: Re: Need 286 "C" benchmark
Message-ID: <608@intelca.UUCP>
Date: Mon, 10-Jun-85 16:16:26 EDT
Article-I.D.: intelca.608
Posted: Mon Jun 10 16:16:26 1985
Date-Received: Tue, 11-Jun-85 08:28:02 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> <433@oakhill.UUCP> <588@intelca.UUCP> <296@tilt.FUN> <5 <1005@peora.10 Jun 85 20:16:26 GMT
Organization: Intel, Santa Clara, Ca.
Lines: 23
Xref: watmath net.arch:1359 net.micro:10732 net.micro.pc:4210 net.micro.68k:894

> A major problem with the 286 (and I guess the 386 too, though I haven't
> seen it yet, only the fragmentary descriptions in this newsgroup) is in the
> number of bits available in the instructions themselves for addressing
> data.  This is the primary addressing problem.  The 8086 family has a
> maximum of 16 bits of address for most instructions.  Even with the

This is not true with the 386, you get 32-bit offsets into segments.

> which is one of the major improvements in the 286, doesn't help this
> problem at all.  Certainly having memory-management on-chip doesn't.

I didn't say that it did; rather, I said that NOT having memory protection
in a multi-user system is the kiss of death, and tacking it onto a 68k
both slows down the system, and adds significantly to the cost of the
processor subsystem.  These costs are not present in a system designed
around a 286.
-- 
It looks so easy, but looks sometimes deceive...

Ken Shoemaker, 386 Design Team, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of Intel.