Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mcvax!cernvax!ethz!zu
From: zu@ethz.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Serious math-coprocessor on the 80386 (80387 ?)
Message-ID: <88@bernina.UUCP>
Date: Thu, 14-May-87 06:42:17 EDT
Article-I.D.: bernina.88
Posted: Thu May 14 06:42:17 1987
Date-Received: Sat, 16-May-87 14:46:27 EDT
References: <3477@jade.BERKELEY.EDU> <579@neoucom.UUCP> <11502@aero.ARPA>
Reply-To: zu@bernina.UUCP (Urs Zurbuchen)
Organization: ETH Zuerich, CS Department, Switzerland
Lines: 43
Keywords: 80287 8087 Floating Point Numeric Co-Processor

In article <11502@aero.ARPA> coffee@aero.UUCP (Peter C. Coffee) writes:
>... The 80286 takes the main
>clock signal and divides its frequency by two, so that a 16 MHz crystal
>drives the 286 at 8 MHz. The 80287, on the other hand, does a divide by
>three, and so normally runs at 2/3 the speed of the co-processing 286.
>The 8086 and 8087, on the other hand, both use the incoming clock signal
>directly. According to Intel documents, there is no other functional
>difference between an 8087 and an 80287: they are merely different packages
>for the same basic stack machine. ...
>After normalizing for clock rate (_real_ clock rate) differences, I have
>found the 8087 and 80287 to be effectively identical.

While it may be true that an 80287 divides its incoming clock signal by three,
it's not true that the 80287 is a repackaged 8087.
Their speed difference comes from the method they access RAM (and therefore
their programs opcodes). The 8087 directly monitors it's coprocessors data
bus. If the CPU fetches a floating point instruction, the 8087 recognizes
this opcode at the same moment as the CPU. They are simultaneously decoding
the incoming opcodes. The 8086 doesn't do anything with this opcode but
recognizing how many data bytes will follow. The next action the cpu will take
is fetching the next byte. This goes on until all data for the last (floating
point) opcode are fetched.
In the meantime, the 8087 takes those data bytes from the bus in its internal
parameter memory and then goes processing the command.

In contrast to that method, the 80287 isn't directly hooked to the data bus
anymore but gets its data (opcodes and data) via special interface from the
cpu. This isn't true concurrent processing anymore. The cpu now also has the
task of sending the floating point instructions and their parameters to the
80287 AFTER fetching them from memory. While this overhead to be done by the
80286 isn't that big it lessens the performance gain against an 8086/8087
pair.

I don't know why Intel implemeted that scheme but it may be because of the
prefetch queue of the 80286.
I guess (!) that the 80387 works like the 80287 concerning that subject.


	...urs zurbuchen


UUCP:    ...seismo!mcvax!cernvax!ethz!zu
BITNET:  K261819 @ CZHRZU1A