3

Early computers often had hardware support for decimal arithmetic. This was usually in the form of BCD, 1 decimal digit per 4 bits, e.g. the 6502 and Z80, tightly constrained by transistor count as they were, provided BCD support as a matter of course.

It seems to me that you could pack 3 decimal digits into each 10 bits, thereby getting e.g. 9 rather than 8 digits in a 32-bit word, with a couple of bits spare. I'm not sure an 8-bit CPU could implement fast arithmetic for this format, but I don't see any reason a 32-bit CPU shouldn't be able to.

Did any historical CPUs provide hardware support for this format? If not, why not?

  • 1
    I don't think binary floating point is unsuitable for financial applications is a valid statement. Millions of financial applications using binary floating point seem to prove the opposite. – tofro Feb 16 at 8:07
  • 3
    @tofro Are you sure they do? Or are you mixing this with BCD? – Raffzahn Feb 16 at 8:11
  • 4
    @tofro May I remind you of integer? Financial application need (usually) a fixed precision based on 1/100th units (cent, penny, etc.), something integers are perfectly made for. And even more important, rules for number handling in financial applications are not set by scientists, but the tax office. One of the reasons why COBOL is still strong (and mainframes as well, even if emulated today), as it's number handling conforms with usual financial rules. Trying to use binary FP for any accounting will be a sure way to run your application aground when the next audit comes along. – Raffzahn Feb 16 at 8:27
  • 3
    Packing 3 digits into 10 bits and is pointless on a 32-bit CPU. Just use each 32 bit word for 9 digits with no "packing." The advantage of BCD was the combination of quick conversion to and from a human-readable representation of the number with easy-to-implement BCD arithmetic. – alephzero Feb 16 at 10:34
  • 2
    The Z80 actually has the RLD and RRD instructions for working in 4bit chunks for these kind of applications (usually things like COBOL with BCD types). In practice I think they were mostly used for fast screen scrolling in games. – Alan Cox Feb 16 at 11:08
9

Yes; it's called Chen-Ho encoding

Theodore M. Hertz of Rockwell filed for a patent on a similar encoding in 1969. The patent was granted in 1971.

Independently in 1971, IBM researchers Tien Chi Chen and Irving Tze Ho worked on encoding two decimal digits in 7 bits. The company filed for a patent in 1973, citing Hertz' patent as prior art, which was granted in 1974. In 1975, they generalized the technique to more decimal digits (including 10 bits for 3 decimal digits) and published the method in the Communications of the ACM. Starting in 2000, the technique began to be called Chen-Ho encoding.

According to Wikipedia, it was actually used in some hardware:

In 1973, some form of Chen–Ho encoding appears to have been utilized in the address conversion hardware of the optional IBM 7070/7074 emulation feature for the IBM System/370 Model 165 and 370 Model 168 computers.

In 2001, Michael F. Cowlishaw received a patent for a refinement to the method, called Densely-Packed Decimal. It is now part of the IEEE 754-2008 and ISO/IEC/IEEE 60559:2011 floating-point standards.

  • While not exactly retro it might be interesting to note that IBM uses densely-packed decimals in the decimal floating point facility intorduced with their z9 processor. – piet.t Feb 18 at 14:47
  • @piet.t it's not IBM who did that. It's the IEEE-754 committee who used DSD for their decimal formats. When IBM adopted IEEE-754 decimal floating-point types obviously they must also use DSD – phuclv Feb 18 at 15:41
  • @phuclv Yes, I didn't mean to say they invented it - but they did a hardware-implementation of the standard (even though it wasn't an official standard then but still a draft) and yes, so they certainly had to use DPD. – piet.t Feb 19 at 6:58
4

It is well-known that binary floating point is unsuitable for financial applications, because 0.1 is not exactly representable in binary.

It's less the binary part, than floating point in general. Financial application want fixed precision. And they want to have exceptions handled according to established rules - rules not set by scientists, but accountants, and the tax office.

For this reason, early computers often had hardware support for decimal arithmetic. This was usually in the form of BCD, 1 decimal digit per 4 bits, e.g. the 6502 and Z80, tightly constrained by transistor count as they were, provided BCD support as a matter of course.

Historical it is called a packed format when two decimal digits are stored within a byte, as BCD refers to all representations of decimal numbers in a binary format. Of course, packing was made possible only with bytes made up from 8 bits, a combination made popular with the IBM /360 (*1).

Before that bytes where, if present at all, made up from various number of bits, in many cases 6 (*2). For example the IBM 7090 stored six 6-bit characters in one 36 byte word. There was no difference between a BCD number and a character. Similar Univacs 1100 series - here even offering the handling of six 6 bit characters/BCD (called sixth word) or 9 bit ones. The later sound like a candidate for the question, except operations where limited.

It seems to me that you could pack 3 decimal digits into each 10 bits, thereby getting e.g. 9 rather than 8 digits in a 32-bit word, with a couple of bits spare. I'm not sure an 8-bit CPU could implement fast arithmetic for this format, but I don't see any reason a 32-bit CPU shouldn't be able to.

Except, why should they do so? Unlike BCD, where handling is inherent decimal and packed BCD where storage density is increased by a simple shift operation, 9 bit 3 digit bytes do require decimal to binats conversion plus an adder structure made to roll over at 1000. 60 bit machiens like the CDC ones would have been great candidates, but they again did rather support 10 6 bit BCD per word than the 6 10 bit your format would have required.

Did any historical CPUs provide hardware support for this format?

Not that I can remember any. There where several 9 bit per byte machines, including mini computers, but none with an explicit 10 bit 3 decimal digit format.

If not, why not?

As usual, that's not a serious question to be asked.

If at all, it must be seen in context with the development before the 360, BCD operations where done on 6 bit units. This means 54 of 64 combinations are unused (*3). With the introduction of an 8 bit byte and packed BCD, this was reduced by 1/3rd while keeping the simplicity of BCD.

Simplicity here means as well that transfer from decimal (ASCII, EBCDIC or punch card) and back was done in a straight forward fashion, using shift (multiplex) operations, not calculation of any kind.

The same 8 bit byte could now as well hold a 7 bit character and doing away with clumsy 6 bit encoding without wasting much code space. So 8 bit per byte is a great compromize both ways (not to mention the usage of another power of two, which sounds total obvious to us nowadays).


*1 - The /360s packed format, BTW, included a sign, encoded in the least significant nibble. So 4 bytes did not hold 8 digits, but 7 plus sign. All operations on packed numbers did operate signed.

*2 - And that can get prety weired: CDC used for their 6600 series 60 bit words, divided into 12 bit bytes, each able to hold two 6 bit chars :))

*3 - Not entirely correct, as some where used for sign and other special encodings.

2

The IBM floating point representation had a hexadecimal exponent — in other words, it used 4-bit units in the mantissa field. It was widely criticized for its "wobbling precision". What you're proposing — 10 bit wide mantissa units — would be 2.5 times (or, from another point of view, 62.5 times) worse than that.

  • 2
    Nop. You missed the part of the question being about storing 3 decimal digits in 9 bits to save space compared to 4 bit per digit, resulting in 9 decimal digits in a 32 bit word, compared to 8 with packed BCD. It touches FP in no way. – Raffzahn Feb 16 at 9:30
  • @Raffzahn Before downvoting, you should have checked which version of the question I was responding to. The first version mentioned floating point explicitly. – Leo B. Feb 16 at 17:29
  • There is no version that mentioned this 'packing' idea to be used for floatong point - and the edit you may refer to was done way after I commented on your question. Your answer fits neither version. – Raffzahn Feb 16 at 19:08
  • @Raffzahn The mention of the floating point established the context of the question. – Leo B. Feb 16 at 21:24
  • Sure, by establishing that floating point is not usable and thus a different solution is suggested ... you may want to reread it, still available by checkign the edit. – Raffzahn Feb 16 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.