Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdahl!drivax!socha
From: socha@drivax.UUCP (Henri J. Socha (x6251))
Newsgroups: comp.arch
Subject: Re: Ideas for coprocessor protocol(s)/interface
Message-ID: <1458@drivax.UUCP>
Date: Fri, 1-May-87 17:52:09 EDT
Article-I.D.: drivax.1458
Posted: Fri May  1 17:52:09 1987
Date-Received: Sun, 3-May-87 03:51:29 EDT
References: <411@psueea.UUCP>
Reply-To: socha@drivax.UUCP (Henri J. Socha (x6251))
Distribution: na
Organization: Digital Research, Monterey
Lines: 42

In article <411@psueea.UUCP> daasch@psueea.UUCP (Robert Daasch) writes:

>I would be interested in expanding the recent series on "on-chip or 
>off-chip MMU" to the coprocessors and the "ideal protocol?"  

>3) What coprocessors are going to be needed?  This would get away from
>rehashing FPU, MMU and the like.

>Thanks,
>Rob D.
>...!tektronix!psu-cs!psueea!daasch
>daasch@portland.csnet


When at Motorola in the Microprocessor group I remeber working on this issue
(#3).  Some of the more obvious co-processors that were discussed included:

Graphics:  if you can't fit it on chip like the TI 34010

I/O:  8089(sp?) is one.  How about one for the new IBM PS/2 micro-channel?

String: Grep, search, block transfer, translate, etc.

O.S. primitives: select next process, queuing, (see the Intel 432)

Language: APL operators, compiler operators (symbol table), etc.

What can be a co-processor?  Analyse a real system and anything that
takes a large precentage of the time is a candidate (Period)


By the way, be sure to consider some classes of co-processor:
* Those needing lots of bus bandwidth (Graphics, string)
* Those needing relatively little (math, MMU - in some sense)
* Those needing lots of hand holding from the host processor (MMU, String?)
* Those needing relatively little (I/O, String?)


Hope this helps.  Let me (us) know what the replies are.
-- 
UUCP:...!amdahl!drivax!socha                                      WAT Iron'75
"Everything should be made as simple as possible but not simpler."  A. Einsteper