Path: utzoo!attcan!ncrcan!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 80860 as a math processor
Keywords: Super bit belching
Message-ID: <1989May3.143715.9386@ziebmef.uucp>
Date: 3 May 89 18:37:13 GMT
References: <15147@gryphon.COM>
Reply-To: mcp@ziebmef.UUCP (Colin Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 24

In article <15147@gryphon.COM> richard@gryphon.COM (Richard Sexton) writes:
>The stupid thing is memory mapped. You write the operands into
>memory addresses, then give it an operation, then poll it for
>completion. Some co-processor.

Well, it still counts as a coprocessor.  The coprocessor instructions
it ises aren't the F-line ones, they're loads and stores with magic
values, but there are bytes you can stick in the instruction stream
to make the thing compute.  Isn't that the point?

It is true that dedicated instructions can be decoded faster *if you
really work at it*, but have you ever looked at the 68020 coporcessor
protocol?  Nice and general, but *slow*.  The 6888[12] is also memory
mapped, albeit in a separate address space (FC = 111), and the processor
writes the instruction word to a certain place, then reads another to
see what needs doing, and generally keeps polling the coprocessor until
it tells the 020 it can go away.  Generally disgusting.

The only difference is the FC bits (that's why a 68010 helps a lot - it
lets you control them explicitly) and the fact that the load/store sequence
is done by microcode, not user code.  And I'll bet long odds Weitek's
protocol is more efficient.
-- 
	-Colin