Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ur-tut!ur-cvsvax!srs!dan
From: dan@srs.UUCP (Dan Kegel)
Newsgroups: comp.arch
Subject: Re: Ideas for coprocessor protocol(s)/interface
Message-ID: <155@srs.UUCP>
Date: Sun, 3-May-87 12:03:00 EDT
Article-I.D.: srs.155
Posted: Sun May  3 12:03:00 1987
Date-Received: Tue, 5-May-87 00:42:10 EDT
References: <411@psueea.UUCP> <1458@drivax.UUCP>
Distribution: na
Organization: S.R.Systems
Lines: 14

In article <1458@drivax.UUCP> socha writes:
> > What new kinds of coprocessors might be needed in the future?
> Some of the more obvious co-processors that were discussed included:
> ...
> 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.

Don't forget digital signal processing; there are chips out by Zoran which
are essentially vector signal coprocessors with a generic interface.
I'd love to hear if giving them a tighter (68020-style) coupling with the
main processor would be worthwhile.
- Dan Kegel ({seismo,rutgers}!rochester!srs!dan)