Xref: utzoo comp.unix.i386:1115 comp.arch:12323 Path: utzoo!censor!geac!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.unix.i386,comp.arch Subject: Re: Compaq 486 + Weitek 4167 Message-ID: <2558CA55.8978@maccs.dcss.mcmaster.ca> Date: 9 Nov 89 00:52:37 GMT Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Distribution: na Organization: McMaster University, Hamilton, Ontario Lines: 27 Brian Miller writes: $Darryl Richman writes: $ Does this mean that both the 80486 and the 4167 are joined to form $a MIMD machine at least some of the time? This isn't how the old 80x86/80x87 $duo worked, right? Until now I had always thought that the cpu pretty much $idled while the coprocessor did its magic. As I understand it, the 80x86/80x87 pair were quite capable of working simultaneously. It may well be that most of the software written for this combination made the CPU wait for the FPU to finish, but I don't think this is a requirement. The problem is that the instruction streams for the 86 and 87 are mixed into one which must be executed in the order in which it's written, rather than the way the 8089 works (where you feed it the memory address of a program for it to run and it performs its own instruction fetches etc.), so you can issue one 80x87 instruction and continue with the 80x86 code, but then you are responsible for figuring out when to issue the next 80x87 instruction ... if you give the 80x87 too long, you lose performance on its part, and if you don't give it long enough, the 80x86 waits, so you lose performance from your CPU. Therefore, most code is written such that the CPU waits for the FPU to finish each instruction. -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate!!!\n"; **************************************************************************** They say the best in life is free // but if you don't pay then you don't eat