Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!tektronix!reed!psu-cs!psueea!daasch
From: daasch@psueea.UUCP (Robert Daasch)
Newsgroups: comp.sys.nsc.32k,comp.sys.intel,comp.sys.m68k
Subject: Coprocessor protocol(s)/interface
Message-ID: <413@psueea.UUCP>
Date: Tue, 5-May-87 11:48:20 EDT
Article-I.D.: psueea.413
Posted: Tue May  5 11:48:20 1987
Date-Received: Thu, 7-May-87 07:15:27 EDT
Distribution: na
Organization: Dept. of Electrical Engineering, Portland State University; Portland OR
Lines: 29
Xref: mnetor comp.sys.nsc.32k:129 comp.sys.intel:225 comp.sys.m68k:452


As suggested I am reposting this to a broader set of newsgroups;
========

I would be interested in expanding the recent series on "on-chip or 
off-chip MMU" to coprocessors and the "ideal protocol?"  Here at 
PSU we are working on a IC subsystem (MOSIS CMOS etc.) for supporting 
the 020 protocol.  I think it is fair to say that it is based on a 
notion that a coprocessor is a special purpose peripheral that shares code 
(operands etc. are inline with the 020 instructions).  I don't know 
details but I believe Intel doesn't use this scheme with the 386.  
Questions to get started could be: 

1) How is the coprocessor limited (both hardware and software )
by the protocol?

2) Is there a reasonable sized "set of protocols" that would support
a broad spectrum of coprocessors?

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

Reply to ...!tektronix!psu-cs!psueea!daasch or post and I'll gladly
collect an archive.

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