mark@megatek.UUCP (mark thompson) (03/27/91)
Whenever I read architecture manuals for (eg. the Moto 68000 series), they invariably support several coprocessors. Also invariably, one of those coprocessors is for floating point. Often, the other is an MMU or some other silly system controller. Has anyone tried to do something wonderful with one of the undedicated coprocessors, examples of wonderful being I/O channel controllers or a business instruction set? -mark
chased@rbbb.Eng.Sun.COM (David Chase) (03/27/91)
In <2892@megatek.megatek.uucp> mark@megatek.UUCP (mark thompson) writes: >Whenever I read architecture manuals for (eg. the Moto 68000 series), >they invariably support several coprocessors. Also invariably, one of >those coprocessors is for floating point. ... >Has anyone tried to do something wonderful with one of the undedicated >coprocessors, examples of wonderful being I/O channel controllers or a >business instruction set? I know of one company that makes/made special boards containing 68020s with several coprocessors (multiple FPU coPs, I think) for their Special Problems, but last I heard they had decided that this was just a good way to get locked in to old technology, and were porting to mostly-straight Unix on whatever hot boxes they could find. Same story, same moral. Sticking to interchangeable commodity software and hardware is the best way to go fast in the long run (generally speaking, of course, but I think the general case occurs much more often than many people think). David Chase Sun
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (03/28/91)
GE did a business instruction coprocessor in the 60's, but I don't know
of anyone doing it for micros. My recollection is that the Intel 386 has
two pins for coprocessor select, but my manual isn't sitting right here
so that may be wrong.
The discussion of kernel CPU vs smart controller could become more
interesting if someone made a general i/o processor as a coprocessor.
The best of both sides of the discussion.
--
bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"Most of the VAX instructions are in microcode,
but halt and no-op are in hardware for efficiency"dcarr@hobbit.gandalf.ca (Dave Carr) (03/28/91)
In <3299@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >The discussion of kernel CPU vs smart controller could become more >interesting if someone made a general i/o processor as a coprocessor. >The best of both sides of the discussion. Was Intel before its time. The 8089 ?? seems to have died quickly.
crispin@csd.uwo.ca (Crispin Cowan) (03/29/91)
In article <2892@megatek.megatek.uucp> mark@megatek.UUCP (mark thompson) writes: >Whenever I read architecture manuals for (eg. the Moto 68000 series), >they invariably support several coprocessors. Also invariably, one of >those coprocessors is for floating point. >Often, the other is an MMU or some other silly system controller. >Has anyone tried to do something wonderful with one of the undedicated >coprocessors, examples of wonderful being I/O channel controllers or a >business instruction set? In the Sylvan project, we built a tasking coprocessor for 68020s and 68030s for a multiprocessor. The intent was to create a lightweight tasking environment for a tightly-coupled multiprocessor, with tightly-coupled performance and loosely-coupled semantics, so that programs could be scaled up to distributed networks of computers. This achieved a loocal message passing cycle time (approx RPC) of 136 microseconds, relative to about 500-1000 in software-only message passing kernels supporting similar task models. The first two citations below describe Sylvan's implementation and performance. The following two are early proposals describing what Sylvan should look like. Crispin ----- Crispin Cowan, CS grad student, University of Western Ontario Work: MC28-C, x3342 crispin@csd.uwo.ca Home: 890 Elias St., London, Ontario, N5W 3P2 "If you want an operating system that is full of vitality and has a great future, use OS/2." --Andy Tanenbaum @inproceedings ( bur89, author = "F. J. Burkowski and G. V. Cormack and G. D. P. Dueck", title = "{Architectural Support for Synchronous Task Communication}", booktitle = "Proceedings of the Third International Conference on Architectural Support for Programming Languages and Operating Systems", year = 1989, pages = "40-53", address = "Boston, MA", month = "April" ) @inproceedings ( bur91, author = "F. J. Burkowski and Charles L. A. Clarke and Crispin Cowan and Gordon J. Vreugdenhil", title = "{Performance Evaluation of the Sylvan Multiprocessor Architecture}", booktitle = "Proceedings of the Second Symposium on Experiences with Distributed and Multiprocessor Systems", year = 1991, pages = "165-184", address = "Atlanta, GA", month = "March" ) @inproceedings ( bur85:honolulu, author = "F. J. Burkowski and D. Dyment", title = "{Sylvan: A Message-Based Multiprocessor Architecture}", booktitle = "Proc. 18th Hawaii International Conference On Systems Sciences", year = 1985, pages = "31-42", address = "Honolulu", month = "January" ) @inproceedings ( bur85:knoxville, author = "F. J. Burkowski and G. V. Cormack and J. D. Dyment and J. K. Pachl", title = "{A Message-Based Architecture for High Concurrency}", booktitle = "Proc. 1st Conference on Hypercube Multiprocessors", year = 1985, pages = "27-37", address = "Knoxville, Tenessee", month = "August" )
skipper@motaus.sps.mot.com (Skipper Smith) (03/29/91)
In article <1991Mar28.142109.1148@hobbit.gandalf.ca> dcarr@hobbit.gandalf.ca (Dave Carr) writes: >In <3299@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >>The discussion of kernel CPU vs smart controller could become more >>interesting if someone made a general i/o processor as a coprocessor. >>The best of both sides of the discussion. > >Was Intel before its time. The 8089 ?? seems to have died quickly. Well, it doesn't technically qualify as a coprocessor (the origin of this thread), but the Motorola 68020 has been fully documented on how to use it as an 8 channel DMA controller. Since all of the code to run all eight channels fit into the 256 byte onboard instruction cache, it is almost like having it microcoded into the machine. The unfortunate part is the amount of glue logic. It takes quite a bit to turn the '020 into "just" an I/O processor. However, the design is easily upgradable to the 68EC030 (68030 w/o MMU) which would gain you the additional speed of burst or the 68EC040 (68040 without a lot of stuff :-) which would give you bursts on writes as well as another 2792 bytes of instruction cache to do other things (like be an interrupt processor, too). Just ask for DC003 at your friendly neighborhood Motorola sales office. -- Skipper Smith | skipper@motaus.sps.mot.com Motorola Technical Training | 8945 Guilford Rd Ste 145 All opinions are my own, not my employers | Columbia, MD 21046
rminnich@super.ORG (Ronald G Minnich) (04/03/91)
In article <1991Mar28.142109.1148@hobbit.gandalf.ca> dcarr@hobbit.gandalf.ca (Dave Carr) writes: >Was Intel before its time. The 8089 ?? seems to have died quickly. Well, on one 8086 board i designed (8086 was a management, not technical decision on this one) i looked at the 8089. Turned out all the things i needed to do could be done by a few 20R8 pals faster, cheaper, and more simply. The 8089 was full of bells and whistles none of which I needed (well, only a small subset). And it was slow-- i guess those things don't come cheap. This seems to be a still-followed rule with the DMA control chip world. Exit 8089. ron -- "Socialism is the road from capitalism to communism, but we never promised to feed you on the way!"-- old Russian saying "Socialism is the torturous road from capitalism to capitalism" -- new Russian saying (Wash. Post 9/16)
jerry@TALOS.UUCP (Jerry Gitomer) (04/03/91)
mark@megatek.UUCP (mark thompson) writes: |Whenever I read architecture manuals for (eg. the Moto 68000 series), they invariably |support several coprocessors. Also invariably, one of those coprocessors is for |floating point. |Often, the other is an MMU or some other silly system controller. |Has anyone tried to do something wonderful with one of the undedicated coprocessors, |examples of wonderful being I/O channel controllers or a business instruction set? Looking at the ratio of I/O to computation for most business applications leads to the conclusion that a coprocessor for a business system doesn't buy much (if anything) in the way of additional performance. It also leads to the conclusion that the best business coprocessor is probably an intelligent disk controller with built-in caching. Jerry -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: (until 4/15) ...uupsi!pbs!npri6!jerry
dahl@SRC.Honeywell.COM (Peter Dahl) (04/05/91)
In article <2892@megatek.megatek.uucp> mark@megatek.UUCP (mark thompson) writes: >Has anyone tried to do something wonderful with one of the undedicated >coprocessors, examples of wonderful being I/O channel controllers or a >business instruction set? >-mark Well I don't know about wonderful, but... For my master's thesis I studied this interface with the intent of using it for an operating system coprocessor. The idea is that a coprocessor would take over running the OS kernel. It would have an independent instruction memory and would basically offload user processes to the main processor. Coprocessor instructions would be analogous to system calls in the user code. The thesis explores issues relating to interrupts, passing code back and forth, control, context switching, etc. ("An Operating System Coprocessor Interface", Peter Dahl, University of Minnesota, 1988) The main problem with this particular interface is that there is no way for the coprocessor to interrupt the main CPU using the interface, the coprocessor must generate an external interrupt. The overhead becomes significant. I tried variants on the same theme like making the main CPU run the OS and the coprocessor run user tasks, but the same problem keeps occurring. What needs to be done is expand the interface so that the coprocessor can efficiently interrupt the main CPU. This is a problem even if you have a FPU, the difference is that you don't have real-time constraints so you can afford to catch the problem later. peter dahl@src.honeywell.com I had fun once, and it wasn't anything like this