Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site intelca.UUCP
Path: utzoo!linus!decvax!decwrl!sun!idi!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: 68020 production samples announced
Message-ID: <337@intelca.UUCP>
Date: Tue, 17-Jul-84 15:21:19 EDT
Article-I.D.: intelca.337
Posted: Tue Jul 17 15:21:19 1984
Date-Received: Wed, 18-Jul-84 07:00:15 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 22

>   ....... as well as a truly general coprocessor interface, unlike the
>   warts put out by Intel and National that hook up their float chip
>   and nothing else....
>
>No argument about Intel... but National's slave-processor interface is
>general enough that many people use the National floating-point chip on
>non-National cpus like the 68000.  And as far as warts go, has Motorola

I do SO love it when people spout off about things they seem to know little
about.  I do suppose, however, that all of this really matters in how you
define "coprocessor."  WRT the 8086, I'm kinda at a loss how it could
be made much more general in that all the processor supplies is the data
address.  It is the coprocessor's responsibility to decode the instruction,
and run any required data cycles.  Thus, anyone if they wanted to could make
a special function coprocessor to do anything they wanted to.  That the
8087 connects specifically to the 8086 is a function that the processor
really does little work for the coprocessor, adding to the generality of
functionality possible in the coprocessor.
-- 
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
---the above views are personal.  They may not represent those of Intel.