Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.micro.68k,net.micro.16k Subject: Re: Warty Intel co-processor interface Message-ID: <4134@utzoo.UUCP> Date: Tue, 24-Jul-84 13:30:47 EDT Article-I.D.: utzoo.4134 Posted: Tue Jul 24 13:30:47 1984 Date-Received: Tue, 24-Jul-84 13:30:47 EDT References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP> Organization: U of Toronto Zoology Lines: 28 John Gilmore comments, in part: > This is not a terrible way to attach a float chip. However, it does > not let you add arbitrary instructions to the instruction set, which is > the whole point of a general coprocessor interface. Nor does it let > you have two coprocessors even if the wired-in EA and operand size > decoding could be worked around -- so if you build a graphics > coprocessor you'll have to give up floating point. The 68020 provides > all these capabilities. Then Motorola may have goofed, and they'll find out the hard way. What I was told, by a fellow who consulted for Intel, was that Intel now regrets the "general coprocessor" interface on the 8087, and thinks it a serious mistake. The trouble is that it adds a great deal of complexity on the coprocessor chip for very little gain, compared to the slave-processor approach of having the cpu do most of the work. Intel's abandoning of the coprocessor interface for the 8028[67] tends to confirm this report. It sounds like Motorola was taken in by Intel's early coprocessor rhetoric, even as Intel was (internally) backpedalling furiously. There's no denying that the slave-processor approach makes it difficult to add arbitrary customer-designed auxiliaries. But it would seem to be the right way to add a floating-point chip, which is (I would speculate) a much more important consideration from the manufacturer's viewpoint. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry