Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!rutgers!ames!ptsfa!ihnp4!homxb!houxm!hjuxa!catnip!ben
From: ben@catnip.UUCP (Bennett Broder)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Serious math-coprocessor on the 80386 (80387 ?)
Message-ID: <478@catnip.UUCP>
Date: Mon, 18-May-87 18:46:35 EDT
Article-I.D.: catnip.478
Posted: Mon May 18 18:46:35 1987
Date-Received: Wed, 20-May-87 02:35:50 EDT
References: <3477@jade.BERKELEY.EDU> <579@neoucom.UUCP> <11502@aero.ARPA> <88@bernina.UUCP>
Reply-To: ben@catnip.UUCP (Bennett Broder)
Organization: The Broder Residence, Holmdel, NJ  07733
Lines: 20
Keywords: 80287 8087 Floating Point Numeric Co-Processor

In article <88@bernina.UUCP> zu@bernina.UUCP (Urs Zurbuchen) writes:
>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 think it's more likely that they didn't want to duplicate all the memory
management hardware the 80286 needs for protected mode operation.

-- 

Ben Broder
{ihnp4,decvax} !hjuxa!catnip!ben
{houxm,clyde}/