Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.arch Subject: Re: un-normalized floating point etc Message-ID: <5875@goanna.cs.rmit.oz.au> Date: 21 May 91 09:53:22 GMT References: <9105210333.AA09960@ucbvax.Berkeley.EDU> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 75 In article <9105210333.AA09960@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes: > Herman Rubin also writes: > So why not have increased integer accuracy? It is no harder to do this, and > the same units can be used. > > I believe there is a good argument for 64 bit integers. > However as someone already pointed out 64x64 bit multiplies can > not be done with a 53x53 bit floating point multiplier. Given that the same posting has already beaten Herman Rubin over the head with the IEEE standard, this doesn't go down well. IEEE extended precision (and the IEEE standard does recommend that it be provided) uses 64-bit signifcands, so a "full" implementation of IEEE 754 would include a 64x64 multiplier, not a 53x53 one. Don't the 80387 and the 68882 chips offer extended precision? What size of multiplier do they use? > Well when a architect leaves something out he is not say- > ing it is useless, he is saying its benefits do not match its > costs. Btw I suspect to be a good designer you need a bit of arrogance. Good architects these days may be like that. But a lot of older machines seem to have been designed on the "we want to take customers from Brand X and the Brand X has a Y instruction, so we'd better have one too" principle. Does anyone know the real story behind the IBM Series/1? I once heard a talk by an Amdahl architect about the way IBM move OS functionality in and out of "370" hardware/microcode. The theme of the talk was "what they keep doing to us! But we're better than good enough to overcome!" How many chips had run-time byte sexing before MIPS? Did MIPS judge wrong about costs and benefits, or was it everyone else? Just because an architect leaves something out, we don't have to _believe_ him that its benefits do not match its costs, until he shows us his data. As far as I am concerned, there is only really one major problem with Herman Rubin's requests: without considering what the rest of the hardware already has, it's hard to assess the costs, and it's next door to impossible to assess the benefits. That's not really his fault; how _do_ you go about measuring the possible benefits of a class of instructions which are so rare that benchmark programs have already been written to avoid the situations where they would have paid off? There's a data base project here which would _love_ high-speed bit-string operations. A C compiler wouldn't recognise an opportunity to use them. An Ada compiler probably would, and so would a Lisp compiler, because those languages can express operations on entire bit strings. Indeed, Lisp can express "find next set bit" directly. (declare (type fixnum n) (type simple-bit-vector b)) (let ((next-bit (position 1 b :start (1+ n)))) (if next-bit #| next-bit is the number of the next bit |# #| else there is no next set bit |#)) so we can process all the set bits thus: (do ((n -1)) ((setf n (position 1 b :start (1+ n)))) (declare (type fixnum n)) #| n is the number of a bit in b which is set |#) My own experience of helping to port a compiler to about a dozen machines was that I often ended up cursing architects for things that they could have provided at low cost, the absence of which made life painful for us (fast dispatch on bits in a register, for example. Why were they omitted? Because the architects only examined C (and possibly Fortran) programs. Bah. (_Love_ the 88k.) This is just a suggestion, but I wonder whether Herman Rubin would consider writing an article "Lost Beauties of Computer Architecture" (I've imitated the title of "Lost Beauties of the English Language") describing some of the things he has occasion to do in his algorithms and what kinds of hardware support used to be available or would be useful for helping him. I'm sure ACM's SigArch publication would take it, and it would keep net bandwidth down if we could keep pointing to a paper. -- There is no such thing as a balanced ecology; ecosystems are chaotic.