daasch@psueea.UUCP (04/29/87)
I would be interested in expanding the recent series on "on-chip or off-chip MMU" to the 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
socha@drivax.UUCP (Henri J. Socha (x6251)) (05/02/87)
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
dan@srs.UUCP (Dan Kegel) (05/03/87)
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)
socha@drivax.UUCP (Henri J. Socha (x6251)) (05/04/87)
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. Einstein
tommy@ssds.UUCP (05/11/87)
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