mslater@cup.portal.com (Michael Z Slater) (08/31/89)
(This is a continuation of an earlier posting, which was truncated by accident just as it was getting to the heart of the matter) Two questions: 1. Is there a formal definition of a coprocessor? Was the term used prior to the 8087? 2. If a coprocessor is something like an 8087 that executes from the same instruction stream as the main processor, then what is a good name for an independent processor that works with another processor? Attached processor? Slave processor? Michael Slater, Microprocessor Report, mslater@cup.portal.com 415/494-2677 fax: 415/494-3718
mbutts@mentor.com (Mike Butts) (08/31/89)
From article <21709@cup.portal.com>, by mslater@cup.portal.com (Michael Z Slater): > 2. If a coprocessor is something like an 8087 that executes from the > same instruction stream as the main processor, then what is a good name > for an independent processor that works with another processor? > Attached processor? Slave processor? > Some history, for what it's worth... From the late 1970's thru to the present, FPS built array processors with architectures very much like the i860, only with small memories (4K to 32K words) where the i860s have caches. These were attached to PDP-11s and VAXes and the like thru a high-bandwidth interface and were used as "subroutine boxes." A FORTRAN program running on the host that needed a dot product or an FFT would call a subroutine, which would DMA the data into the FPS AP120-B's memory, cause it to execute a routine which had been previously loaded into the instruction RAM, and then ship the results back. You would code the 120B in assembler, which was tricky since it had 64-bit instructions with multiple parallel operation fields, or, later, there was a FORTRAN compiler. FPS and the industry called this an "attached processor." Then in 1981, FPS came out with the 164, which had a host connection much like the 120B's and could not stand alone, but which had a very large main memory for code and data, an instruction cache, facilities to allow multiple users to share the machine (although it did stop short of virtual memory), and was built to run entire large applications, like ANSYS and NASTRAN. It depended primarily on the host VAX for I/O, but did have its own high-speed disk, file system and OS. It had an excellent optimizing FORTRAN compiler that could schedule multiple operations into the parallel, pipelined instructions. FPS initially called this an "attached processor" as well, but later called the 164 a "scientific computer," as it was being used as a "baby Cray." Indeed, don't most scientific computers, like the Crays, depend on a host GP system for much of their I/O? Where do you draw the line? To summarize, I would call a machine which has its own instruction stream, but which is slaved to a host's instruction stream, an "attached processor." In a broad sense such a machine is not that different from a co-processor, except that its "instruction set" is programmable and its "operands" may be entire matrices. I would call a machine which executes entire numeric-intensive applications, such as an FPS-164, a Cray, or an i860 with a large main memory, a "scientific computer." -- Michael Butts, Research Engineer KC7IT 503-626-1302 Mentor Graphics Corp., 8500 SW Creekside Place, Beaverton, OR 97005 ...!{sequent,tessi,apollo}!mntgfx!mbutts OR mbutts@pdx.MENTOR.COM Opinions are my own, not necessarily those of Mentor Graphics Corp.
daveh@cbmvax.UUCP (Dave Haynie) (09/06/89)
in article <21709@cup.portal.com>, mslater@cup.portal.com (Michael Z Slater) says: > (This is a continuation of an earlier posting, which was truncated by > accident just as it was getting to the heart of the matter) > 2. If a coprocessor is something like an 8087 that executes from the > same instruction stream as the main processor, then what is a good name > for an independent processor that works with another processor? > Attached processor? Slave processor? I've never seen any formalism on the names myself, but I question whether the term "coprocessor" is the appropriate one for something like an 8087. At least if the 8087 works anything like Motorola "coprocessors", such devices become basic extensions to the CPU model you're working with, and at least from the programming prespective, there's no way you can tell that they are at all distinct from the main CPU. The term "coprocessor" for such a device never worked for me; maybe it's appropriate, but not specific enough. I'd guess that there are really three different things that might be called coprocessors. The CPU-extension processor, like a 68882, is one kind. The second would be a helper processor of some kind. In the Amiga system we have a thing like this, a video coprocessor called the "Copper" for short. This thing executes it's own instruction stream and does video operations to free up the CPU from having to deal with some of the drudgery of managing a video display. This is really a slave device -- it couldn't do anything useful without a main CPU to help it out. The third kind of coprocessor might exist as a helper or an equal in a multiple CPU system, but it's a full fledged CPU in it's own right. As for the Intel 80860, it sure seems to me that the device fits this last category. It might be put into a system as a slave to the main CPU, perhaps managing a video display or something similar. But it's a full fledged CPU in it's own right, it'll apparently even run UNIX, albeit poorly. I kind of wonder if this was the original design goal for the part, but that's apparently what it turned out to be. > Michael Slater, Microprocessor Report, mslater@cup.portal.com > 415/494-2677 fax: 415/494-3718 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough