The Museum of HP Calculators

HP Forum Archive 16

 exponents in 14-nybble BCD floating-point representationsMessage #1 Posted by Cameron Paine on 12 Apr 2006, 8:16 a.m. I need to come out of lurk mode and ask you all a couple of questions about the 56-bit BCD values that many HP calculators work with. I considered emailing Eric, Hugh, Luiz or Valentin but on reflection I decided that the answers might be of interest to the wider community at MoHPC. If you find the esoteria of calculator implmentation as stimulating as drying paint you'd best skip to the next topic now. ;-) First the assumption. If I've got this wrong then all is lost and someone should shame me into silence. The 14-nybble FP encoding reserves nybbles 0-2 for the exponent. +ve exponents : 0 <= e <= 99 are encoded directly as BCD-000 through BCD-099. -ve exponents : -99 <= e <= -1 are encoded using a 3-digit, 10's complement form which uses BCD-901 through BCD-999. Now the questions: 1. Why did the designers not go the whole hog and fully commit to a 10's complement exponent offering values -500 <= e < 500? 2. Given that they decided to expose a signed, 2-digit exponent to the user, why complement it at all? I've been pondering question 2 for several weeks now. I'm guessing that by pre-complementing the negative exponents, the processing time was paid back in the future. This appears to advantage multiplication over division. In theory, division requires that the exponent be complemented a second time, thereby ensuring that there would never be a pay back. Is there a theory (or an analysis) which shows that within the target application domain(s) of the pre-1990's calculators, multiplication is performed more frequently? Cameron PS: since I don't post too often I'll remind you that I can barely spell mathematics. ;-) PPS: to the users of my 16C simulation, yes this does mean that the 14-nybble BCD FP implementation is moving forward. I have two quite different implementations that I'm playing with: a brute force one and another that is so "clever" that debugging it is becoming a pain. I'm leaning towards the brute force one. It's much more fun to watch while stepping through it with the debugger.

 Re: exponents in 14-nybble BCD floating-point representationsMessage #2 Posted by Thomas Okken on 12 Apr 2006, 10:35 a.m.,in response to message #1 by Cameron Paine 2. Given that they decided to expose a signed, 2-digit exponent to the user, why complement it at all? As you suggested yourself, it saves CPU cycles, and it also reduces code size. The advantage of the "complement" representation over the "signed" representation is that you can perform addition and subtraction without having to code separate cases for positive and negative values. When performing a floating-point multiplication, you simply add the exponents; when performing a division, you subtract them; finally, you perform a range check, and you're done. When using "signed" representations, the logic becomes much more complicated. The drawback of using the "complement" notation is that the conversion to "signed" has to be performed every time the number is rendered on the display, but for a programmable calculator, that's less important than the time saved on EVERY floating-point instruction. - Thomas Edited: 12 Apr 2006, 11:12 a.m.