BCD calculators

[neyuru]

Hello all, first post here. By the way they handle arithmetic, physical calculators can (maybe?) be classified in broadly three groups:

1. Hardware based BCD
2. Software based BCD* (emulation)
3. All binary arithmetic (converting only to decimal for display)
   

* although I'm not even sure if this is actually implemented, but is a possibility.

Having an ASIC is not something a manufacturer usually conveys in its marketing, but I do appreciate a chip specifically designed to handle math operations in the way *most* humans do math. Some calculator models are known to have a BCD compliant microprocessor. Information on HP models is the easiest to find. Some modern calculators are based on ARM (or similar) processors (which I think excludes them from BCD, as they are basically tiny, power efficient "32bit or 64bit computers"- as in PCs with processors with binary arithmetic). Although they might be fast on benchmarks, they lack the soul of a calculator: as a device specifically engineered to do math fast and with as little resources as possible.

For my tastes, a "real" calculator* should have hardware based BCD. What are your thoughts on this? Does anyone know of any source that gives information on calculators falling in one of these groups? (there is at least one page with information on processors used for models but you would have to then investigate this chip and even if you find information about it, non technical users like me would most likely won't find anything useful in layman's terms.)
* by real I mean a device that is specifically designed to handle and give us answers in the language we are most familiar with: decimal.

I would love to know if modern calculators are still being made with ASICs instead of the ever present 32-bit or 64-bit general purpose processors.

[Claudio L.]

(11-04-2020 12:41 AM)neyuru Wrote:  Hello all, first post here. By the way they handle arithmetic, physical calculators can (maybe?) be classified in broadly three groups:

1. Hardware based BCD
2. Software based BCD* (emulation)
3. All binary arithmetic (converting only to decimal for display)
   

* although I'm not even sure if this is actually implemented, but is a possibility.

Having an ASIC is not something a manufacturer usually conveys in its marketing, but I do appreciate a chip specifically designed to handle math operations in the way *most* humans do math. Some calculator models are known to have a BCD compliant microprocessor. Information on HP models is the easiest to find. Some modern calculators are based on ARM (or similar) processors (which I think excludes them from BCD, as they are basically tiny, power efficient "32bit or 64bit computers"- as in PCs with processors with binary arithmetic). Although they might be fast on benchmarks, they lack the soul of a calculator: as a device specifically engineered to do math fast and with as little resources as possible.

For my tastes, a "real" calculator* should have hardware based BCD. What are your thoughts on this? Does anyone know of any source that gives information on calculators falling in one of these groups? (there is at least one page with information on processors used for models but you would have to then investigate this chip and even if you find information about it, non technical users like me would most likely won't find anything useful in layman's terms.)
* by real I mean a device that is specifically designed to handle and give us answers in the language we are most familiar with: decimal.

I would love to know if modern calculators are still being made with ASICs instead of the ever present 32-bit or 64-bit general purpose processors.

First I'd like to make a distinction between decimal math and BCD. BCD uses a particular encoding, you can do decimal math with other ways to encode the number, it's still decimal but not BCD. Libraries like decNumber, mpdecimal, etc. fall in this category: it's decimal but not exactly BCD.

All HP calculators based in the Saturn chip (HP28, 39g, 40g, 48s & 48g, 49g), have hardware decimal support (actual BCD). Newer ones running on emulated Saturn run emulated decimal (39gs, 40gs, 49g+, 48GII, 50g). The HP Prime uses binary for HOME, and decimal for the CAS on an ARM (so it doesn't really fit well on your classification).

Hardware based solutions are nowadays not flexible enough. Hardware is being commoditized, and software needs to be portable, so you can develop software once and just replace the hardware when it breaks. Any software designed for specific hardware is condemned to die with that hardware.

[Wes Loewer]

(11-04-2020 04:01 PM)Claudio L. Wrote:  The HP Prime uses binary for HOME, and decimal for the CAS on an ARM

I think you have those reversed.

[firai]

I'm not sure where you're drawing the line with hardware-based decimal floating point (DFP) arithmetic versus "general purpose processors" or "binary arithmetic processors". (As Claudio noted, there's a distinction between DFP and the specific binary-coded decimal (BCD) format.) I think the reality is that there are shades of gray between the classification that you presented, and the kind of DFP-centric chip that you're thinking of probably hasn't been made for the consumer market for a number of years.

A number of modern low- to mid-end calculators (such as the HP 35S or the TI 36X) are made with microcontroller ICs that operate on around 4 or 8-bits, with add-on glue logic to work with the off-the-shelf microcontroller. It's not like these chips have floating point units (FPUs), so I wouldn't consider them to be "binary math processors", but the IC packages weren't necessarily made to be fit only for DFP arithmetic either. You can consider these somewhere between hardware DFP and software DFP.

ARM processors are really high-end microcontrollers, and they may or may not have FPUs depending on the architecture version and the SoC package. Particularly for the SoCs that don't have FPUs, to say that they are "binary math processors" seems to be an over-generalization in my opinion as well, when even binary floating point arithmetic needs to be handled by software for those chips.

For me, the soul of a calculator is its ability to be used easily and quickly to accomplish numerical operations, so that I can use it to calculate and deliver results to my clients, architects and my boss (usually in meetings), as an overall experience. While I appreciate that there was an era when a lot of R&D resources could (needed to) be poured into the development of a DFP-centric processor to get decent DFP performance, I would take the better speed and smaller power consumption of modern devices even if the CPU isn't DFP-centric. For example, I currently use the SwissMicros DM42 (HP-42S clone of sorts) as my workhorse. It uses software-based decimal floating point arithmetic run on an ARM chip (through Thomas Okken's Free42 simulator, which in turn uses Intel's decimal floating point library). The speed is much faster than the original 42S, but it still sips on power (runs on one coin-cell that lasts a year or two). The parts are selected for the product to be an efficient calculator, and I don't consider it to be less "real" than calculators which have HP Saturn chips. If a calculator like that that runs on a single coin cell doesn't count as a "real" calculator, I'm not sure what really does anymore.

As an aside, even chips for PCs have some (limited) decimal math support. The x86 instruction set contains a small number of instructions for dealing with a particular form of BCD. Certain IBM zSeries mainframe CPUs also have hardware acceleration for DFP operations.

On the other hand, Numworks is the only calculator I know of that uses binary floating point.

(11-04-2020 04:01 PM)Claudio L. Wrote:  First I'd like to make a distinction between decimal math and BCD. BCD uses a particular encoding, you can do decimal math with other ways to encode the number, it's still decimal but not BCD. Libraries like decNumber, mpdecimal, etc. fall in this category: it's decimal but not exactly BCD.

By the way, Claudio, were you thinking of Intel's DFP library instead of decNumber? decNumber uses DPD, which is a compressed version of BCD. Intel's DFP library and .NET's decimal type use BID (or a variant of it for the latter), which as you said achieves decimal math without using the BCD coding scheme (particularly for the significand).

[Claudio L.]

(11-04-2020 04:22 PM)Wes Loewer Wrote:  

(11-04-2020 04:01 PM)Claudio L. Wrote:  The HP Prime uses binary for HOME, and decimal for the CAS on an ARM

I think you have those reversed.

Yes I did. I stand corrected.

(11-05-2020 03:34 PM)firai Wrote:  By the way, Claudio, were you thinking of Intel's DFP library instead of decNumber? decNumber uses DPD, which is a compressed version of BCD. Intel's DFP library and .NET's decimal type use BID (or a variant of it for the latter), which as you said achieves decimal math without using the BCD coding scheme (particularly for the significand).

I was actually thinking of decNumber. The generic decNumber type uses a more generic encoding. I had forgotten that the IEEE 754-2008 decimal packed types are there too and do use DPD as you pointed out (I never used them myself, only decNumber so I overlooked that part of the library).

[jte]

(11-18-2020 09:08 PM)Claudio L. Wrote:  

(11-04-2020 04:22 PM)Wes Loewer Wrote:  

(11-04-2020 04:01 PM)Claudio L. Wrote:  The HP Prime uses binary for HOME, and decimal for the CAS on an ARM

I think you have those reversed.

Yes I did. I stand corrected.

As first shipped, the Prime employed, in the main, three floating-point formats:

• the BCD format of HOME (and PPL, and generally used by the built-in apps / system for evaluating floating-point expressions; 15 digits may be used for portions of calculations, internally; 12 digits are exposed to users),
• the (64-5)-bit binary floating-point format of the CAS (instead of 52 binary digits of explicitly stored mantissa, as in a standard double, 52-5=47 binary digits are explicitly stored; normalized numbers have an implicit leading “1”), and
• the 64-bit binary floating-point format used in the Advanced Graphing app’s interval arithmetic (each interval employing a pair of floating-point numbers, with 52 binary digits explicitly stored in the mantissas of its floating-point numbers, again with an implicit leading “1” for normalized numbers).
  

(The above ignores things like NaNs and infinities. The BCD format above employs 10 as the exponent base while the binary formats above employ 2 as the exponent base.) Now, there is also Python.

[jte]

(11-04-2020 12:41 AM)neyuru Wrote:  Hello all, …

Hello neyuru!

Quote:…first post here. By the way they handle arithmetic, physical calculators can (maybe?) be classified in broadly three groups:

1. Hardware based BCD
2. Software based BCD* (emulation)
3. All binary arithmetic (converting only to decimal for display)
   

* although I’m not even sure if this is actually implemented, but is a possibility.

Myself, I’d place a bunch of BCD calculators in the “software-based” class.

Quote:Having an ASIC is not something a manufacturer usually conveys in its marketing, but I do appreciate a chip specifically designed to handle math operations in the way *most* humans do math. Some calculator models are known to have a BCD compliant microprocessor. Information on HP models is the easiest to find. Some modern calculators are based on ARM…

Where do FPGAs handling the floating-point calculations fit into this classification scheme? I’d generally place them more into a “hardware-based” class (depending, somewhat, on how much of the floating-point calculations are being handled directly by FPGA elements). Note that ARM / FPGA hybrids are currently available.

[Paul Dale]

There has been some movement towards including the IEEE 754 floating point decimals in hardware. Mostly by IBM. It hasn't trickled down to embedded platforms but would be nice if/when it does. The standard defines two representations neither of which is BCD.

Pauli

[jte]

(08-19-2021 02:05 AM)Paul Dale Wrote:  There has been some movement towards including the IEEE 754 floating point decimals in hardware. Mostly by IBM.

Yes… when I was first reading above, one of the first architectures that popped into my mind was the Power ISA. (… and then I experienced the tiniest chagrin when reading “zSeries” )

Even with “hardware support”, some (non-ancient, binary) FPUs do punt when encountering some of the less-common floating-point values (e.g., denormalized numbers) — either through microcode assist or software assist. You can see this by running timing benchmarks. (I haven’t tried running these sorts of tests on the latest CPUs.)

Quote:It hasn’t trickled down to embedded platforms but would be nice if/when it does. The standard defines two representations neither of which is BCD.

It’s interesting seeing the distinction being drawn between BCD and DPD; a detail I’d be prone to overlooking in casual discussions. (Given how efficiently hardware can convert between BCD and DPD. I might throw in something like “more space-efficient encoding” to clarify it’s not exactly BCD.) My guess is that decimal FPU hardware doesn’t directly calculate with DPD. (Even if in DPD in registers, I’d guess it’s converted to and from another format before and after the actual calculation is performed.)

It will be interesting when / if decimal arithmetics arrive in embedded CPUs. I’m guessing the transistor budget considerations are quite different (for embedded CPUs as compared to things like Power CPUs).

[Paul Dale]

The conversion between DPD and BCD isn't trivial. It's actually surprisingly subtle: DPD requires a 1k entry lookup table to convert to BCD and back.

This was something I raised with the author of the decNumber library (Mike Cowlishaw) many years ago. The response was along the lines of "sure, leave out that table but you won't be binary compatible". For the 34S, binary compatibility wasn't important so we left it out and saved many precious bytes of flash.


Pauli