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