Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!astroatc!prairie!dan
From: dan@prairie.UUCP
Newsgroups: comp.sys.nsc.32k,comp.sys.intel,comp.sys.m68k
Subject: Re: Coprocessor protocol(s)/interface
Message-ID: <451@prairie.UUCP>
Date: Thu, 7-May-87 12:13:49 EDT
Article-I.D.: prairie.451
Posted: Thu May  7 12:13:49 1987
Date-Received: Sat, 9-May-87 08:11:38 EDT
References: <413@psueea.UUCP>
Reply-To: dan@prairie.UUCP (Daniel M. Frank)
Distribution: na
Organization: Prairie Computing, Madison, Wisconsin
Lines: 19
Xref: utgpu comp.sys.nsc.32k:130 comp.sys.intel:212 comp.sys.m68k:435

In article <413@psueea.UUCP> daasch@psueea.UUCP (Robert Daasch) writes:
>I think it is fair to say that it is based on a notion that a coprocessor 
>is a special purpose peripheral that shares code.  I don't know 
>details but I believe Intel doesn't use this scheme with the 386.  

   It doesn't for the MMU (since that's on chip), but the whole 8086 series
uses exactly that approach with the 80x87 arithmetic coprocessor and the 
8089 (?) I/O coprocessor, and perhaps others.  There are dedicated 
instructions for each coprocessor function, for which the co-p watches the 
bus.  The main processor does address operand decoding and fetching, and
the coprocessor steps in to actually receive or store operands at the
appropriate time in instruction execution.  There are only two lines
that explicitly connect the processors, and they are used for timing.

-- 
      Dan Frank (w9nk)
	ARPA: dan@db.wisc.edu			ATT: (608) 255-0002 (home)
	UUCP: ... uwvax!prairie!dan		     (608) 262-4196 (office)
	SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006