jbs@WATSON.IBM.COM (05/21/91)
Herman Rubin writes: The last question first: How about multiple precision floating (or fixed) arithmetic? Considering that there are quite a few papers on this, it is certainly a topic of interest. I do not believe it should be necessary here to go into the full range of situations I can list NOW where this would be useful. Now what is the benefit of allowing only normalized floating point? It eliminates the need for a normalization option in floating instructions, and it provides ONE more bit of accuracy. Is that ONE bit exactly what is needed? This is very unlikely. Now what is the cost of not having forced normalization, besides the one bit? There would have to be a method for indicating which result of the operation is wanted (upper, lower, normalized). There would be little additional hardware other than the decoding, by the floating unit, of this information. Well the main cost of not having forced normalization is that your floating point format becomes incompatible with everybody else's. When a standard becomes as entrenched as the ieee floating point standard has become in recent years its technical merits or lack thereof become almost irrelevant. This is the main reason the IBM Risc System 6000 uses IEEE. (Does anyone know of any recent designs which don't use IEEE?) Also your claim that there is little hardware cost is de- batable. If your multiplier must be able produce the normalized product of two unnormalized numbers, the normalization stage has to be able to handle shifts of 100 bits (instead of 0 or 1 only). As well as adding hardware this may slow you down. Finally regarding multiple precision floating point arithmetic. If you mean twice working precision I fail to see the benefit of having unnormalized floating point operations. The Risc System 6000 is able to provide software quad-precision arith- metic with the current instructions. If you mean more precision than this I believe this is very little used. 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. Herman Rubin also writes: The chicken and the egg again. Anyone who is willing to say that something is not useful is either ignorant, arrogant, or stupid. Nobody can, or should, attempt to ever do this. Even the best people can make big mistakes. 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 arro- gance. James B. Shearer
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/21/91)
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.