Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!vsi1!daver!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: ZISC computers Keywords: ZISC Message-ID: <8939@winchester.mips.COM> Date: 29 Nov 88 05:44:00 GMT References: <22115@sgi.SGI.COM> <278@antares.UUCP> <2958@ima.ima.isc.com> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 28 In article <2958@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes: >>[re ZISC computer] It's called the Weitek WTL 1167 >>Math Coprocessor Board. You store one operand in the chip by writing to a >>magic location.... >This is an ancient hack. The optional multiply/divide option for the original >PDP-11 worked in exactly that way, by storing operands into pseudo-locations >that told it what operation to perform. >More recently, and apropos of another discussion here, the original optional >floating point board for the RT PC worked the same way, with address bits >on stores to the FPU being decoded to command the National floating point >chip that did the work. Note, of course, that this is a model of the world likely to go away, for anybody who is serious about scalar floating point. The structure is only likely to happen when you have a long-cycle-count FP device, which is still fast enough to be desirable, but where the addition of a few cycles' overhead doesn't clobber the performance. As micros with tight-coupled FPUs (MIPS R3000/R3010, Moto 88K, Cypress SPARC + TI 8847) and low-cycle count operations (2-10 cycles for 64-bit add & mult) become more common, you just lose too much performance moving data around to afford that kind of interface, at least in a scalar unit. -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086