BCD calculators

11042020, 12:41 AM
Post: #1




BCD calculators
Hello all, first post here. By the way they handle arithmetic, physical calculators can (maybe?) be classified in broadly three groups:
* 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 32bit or 64bit general purpose processors. 

11042020, 04:01 PM
Post: #2




RE: BCD calculators
(11042020 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: 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. 

11042020, 04:22 PM
Post: #3




RE: BCD calculators  
11052020, 03:34 PM
(This post was last modified: 11192020 08:04 AM by firai.)
Post: #4




RE: BCD calculators
I'm not sure where you're drawing the line with hardwarebased 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 binarycoded decimal (BCD) format.) I think the reality is that there are shades of gray between the classification that you presented, and the kind of DFPcentric 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 midend calculators (such as the HP 35S or the TI 36X) are made with microcontroller ICs that operate on around 4 or 8bits, with addon glue logic to work with the offtheshelf 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 highend 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 overgeneralization 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 DFPcentric 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 DFPcentric. For example, I currently use the SwissMicros DM42 (HP42S clone of sorts) as my workhorse. It uses softwarebased 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 coincell 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. (11042020 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). 

11182020, 09:08 PM
Post: #5




RE: BCD calculators
(11042020 04:22 PM)Wes Loewer Wrote:(11042020 04:01 PM)Claudio L. Wrote: The HP Prime uses binary for HOME, and decimal for the CAS on an ARM Yes I did. I stand corrected. (11052020 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 7542008 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). 

08192021, 12:04 AM
(This post was last modified: 08192021 12:11 AM by jte.)
Post: #6




RE: BCD calculators
(11182020 09:08 PM)Claudio L. Wrote:(11042020 04:22 PM)Wes Loewer Wrote:(11042020 04:01 PM)Claudio L. Wrote: The HP Prime uses binary for HOME, and decimal for the CAS on an ARM As first shipped, the Prime employed, in the main, three floatingpoint formats:


08192021, 12:36 AM
(This post was last modified: 08192021 12:38 AM by jte.)
Post: #7




RE: BCD calculators
(11042020 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: Myself, I’d place a bunch of BCD calculators in the “softwarebased” 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 floatingpoint calculations fit into this classification scheme? I’d generally place them more into a “hardwarebased” class (depending, somewhat, on how much of the floatingpoint calculations are being handled directly by FPGA elements). Note that ARM / FPGA hybrids are currently available. 

08192021, 02:05 AM
Post: #8




RE: BCD calculators
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 

08252021, 12:26 AM
Post: #9




RE: BCD calculators
(08192021 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 (nonancient, binary) FPUs do punt when encountering some of the lesscommon floatingpoint 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 spaceefficient 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). 

08252021, 05:03 AM
Post: #10




RE: BCD calculators
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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)