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: 43The 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