Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site orca.UUCP
Path: utzoo!linus!decvax!tektronix!orca!brucec
From: brucec@orca.UUCP (Master of the Belvedere)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Warty Intel co-processor interface
Message-ID: <987@orca.UUCP>
Date: Mon, 6-Aug-84 16:35:48 EDT
Article-I.D.: orca.987
Posted: Mon Aug  6 16:35:48 1984
Date-Received: Wed, 8-Aug-84 00:48:55 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP> <4134@utzoo.UUCP>
Organization: Tektronix, Wilsonville OR
Lines: 43



The whole subject of coprocesser interfaces is more complicated than it looks
at first.  The reason Intel backed away from the 8087-style interface was
the complexity caused by the tight-coupling of the cpu to fpu.  The fpu had
to duplicate the cpu's instruction prefetch pipeline and operate in parallel
in order to know when the fpu instruction was actually being decoded by the
cpu so it could trap the address of the data which the cpu generated (since
the fpu didn't have all the segment registers, etc., it had to get the
physical address off the bus as the cpu generated it).

The 286/287 interface is nasty too, since it requires the cpu to have all the
microcode required for loading the data into the fpu, running the fpu, then
storing the data.  The more microcode you use for things like this, the less
there is for the main cpu functions.  Also, the fpu loads and stores take
longer, since the cpu has to do them.

There's another way, which, oddly enough, Intel uses also. That is to loosely
couple the cpu and coprocessor, and allow them to operate in parallel (anyone
who has really tried to program the 8086 & 8087 to run in parallel will tell
you just how useless the ability is, given their architecture).  This implies
a lot more capability on the part of the coprocessor, though, since it has to
be able to decode its instructions out of memory, just like a cpu.  The 8089
would be an excellent example of this technique if the instruction set
weren't so screwed up.  The 82730 text display chip shows how nicely the
technique can work.  The nice thing about this "channel processor" technique
of operation is that the cpu doesn't need any special hardware to use it;
all the special stuff is on the coprocessor (like a pin to wake the
coprocessor up and have it read its channel control block).

Of course, this approach doesn't work well when you only want to perform a a
single floating point operation on two operands, but typically you want to do
a sequence of operations on many sets of two or more operations (graphics
transforms, or FFTs are good examples).

				Bruce Cohen
				UUCP:	...!tektronix!orca!brucec
				CSNET:	orca!brucec@tektronix
				ARPA:	orca!brucec.tektronix@rand-relay
				USMail: M/S 61-183
					Tektronix, Inc.
					P.O. Box 1000
					Wilsonville, OR 97070