Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hao!nbires!isis!udenva!ssds!tommy
From: tommy@ssds.UUCP
Newsgroups: comp.arch
Subject: Re: Ideas for coprocessor protocol(s)/interface
Message-ID: <208@ssds.UUCP>
Date: Mon, 11-May-87 13:27:03 EDT
Article-I.D.: ssds.208
Posted: Mon May 11 13:27:03 1987
Date-Received: Thu, 14-May-87 06:13:19 EDT
References: <411@psueea.UUCP> <1458@drivax.UUCP>
Reply-To: tommy@ssds.UUCP (Tommy Phillips)
Distribution: na
Organization: SSDS, Inc., Littleton, CO
Lines: 22

In article <1458@drivax.UUCP> socha@drivax.UUCP (Henri J. Socha (x6251)) writes:
>>3) What coprocessors are going to be needed?  This would get away from
>>rehashing FPU, MMU and the like.
>Graphics:  if you can't fit it on chip like the TI 34010
Whatever happened to the 6845?  didn't it have a very clean i/f to the 6809?
Why didn't Big M create some 68k-series descendants for it?
>I/O:  8089(sp?) is one.  How about one for the new IBM PS/2 micro-channel?
This would be a big win in multi-user systems.
>String: Grep, search, block transfer, translate, etc.
Wouldn't this be useful in compilers and interpreters?
>O.S. primitives: select next process, queuing, (see the Intel 432)
This is usually taken care of in some sort of kernel.  If kernel routines
could reasonably be reduced to a few instructions we might see a big win in
multi-tasking systems.

Has anybody done any research on an extremely RISCy CPU with some fairly large
number of special coprocessors?  If each was fairly simple then you could
select your instruction set by what chips you plugged in.  You would want s/w
emulation code for all the ones you didn't have room for, maybe.
-- 
Tommy Phillips
{hao,nbires}!isis!ssds!tommy