Why did decimal arithmetic slow down VisiCalc?

Question

There is an excellent article about VisiCalc that goes into all the details about what happened and why, highly recommended if you are interested in that part of computing history. I was reading this section:

At its heart, VisiCalc is about numbers. One of the early decisions we made was to use decimal arithmetic so that the errors would be the same one that an accountant would see using a decimal calculator. In retrospect this was a bad decision because people turn out to not care and it made calculations much slower than they would have been in binary.

And nodding, yes, VisiCalc's successors backslid in this regard; to this day, the Internet is full of questions and answers about why Excel exhibits anomalies with numbers like 0.1 and binary floating point not rounding the way people expect. VisiCalc should really have launched an advertising campaign at the time pointing out the...

... Wait a minute. Fridge logic.

Made calculations much slower?

VisiCalc was written on the 6502, which supports BCD arithmetic. You just have to turn on decimal mode, and the CPU will add BCD bytes at exactly the same speed as it would add binary bytes.

But most numbers in a spreadsheet are simple when expressed in decimal. A number like 1234.56 takes three bytes in BCD where it would've taken eight bytes in double precision binary floating point. That not only saves memory but, if your calculation routines (which have to be done in software – the machine had no FPU) take the opportunity for early exit, also saves time. So calculation of numbers that typically occur in spreadsheets should be faster in decimal.

And small spreadsheets spend a lot of their time updating the display. Converting a number from internal representation to ASCII for display is quite a bit faster when the internal representation was decimal.

So why did he say decimal made calculations slower?

Answer 1

A number like 1234.56 takes three bytes in BCD where it would've taken eight bytes in double precision binary floating point.

Generally speaking, that is not the case. If you have a database field definition of 6 digits total, 4 before the decimal, 2 after, positive numbers only, then yes you can have 1234.56 represented in 3 8-bit BCD bytes. But if, as is more typically the case:

• You allow any number to have many more digits - e.g., 8 digits is a minimum just to allow up to (but not including) $1,000,000 specified to the penny. More typical would be 10 or 12 or more.
• You allow varying numbers of digits past the decimal place in different fields - e.g., 2 for US (and many other) currency values, but 6 or more for unit costs (e.g., cost of kWh for utility bills)
• You allow negative numbers.

Then you very quickly go beyond 3 bytes. 8 bytes becomes a reasonable minimum.

Even for storage (ignoring calculation), 3 bytes doesn't work for the 6-digit number because something somewhere has to define that this cell has a 3-byte positive number with the decimal point before the last 2 digits. That takes a byte, so now we are at 4 bytes.

In addition, the code needed for the extra manipulations (code/decode different length numeric formats) eats into the very limited 64k code + data available on typical 8-bit systems. It could easily be the case that the space saved for values by varying size (and hopefully on average much smaller) of numeric cells in a spreadsheet would typically be outweighed by the extra code needed in memory to support display, manipulation and calculation of those numbers.

Answer 2

6502 supported SIMPLE BCD arithmetic. I would bet that the VisiCalc guys in the end didn't even use that feature and wrote the whole thing from scratch. There's not just addition and subtraction, there's also multiplication and division, plus VisiCalc was floating point (just decimal floating point).

The reason the decimal math is slower is simply the same reason "nobody" uses decimal math today, they use binary math. With binary math, each bit is a digit. With decimal math, 4 bits is a digit. More memory for less precision, the math is just slower, its just a lot more work for the computer, even the 6502 with nascent support for it.

(And, yes, decimal math is used all over the place in different places, but it's the exception not the rule.)

Answer 3

Because decimal operations are slower, even on the 6502. There is processor support for 8-bit BCD addition and subtraction, but that's it.

Code for decimal multiplication, division, shifting, floating point normalization, and maybe even comparison, will be somewhat larger and slower than with binary.

For example, shift-and-subtract division routines require a subroutine to halve the value. In binary this is trivial. Using an 8 bit value as an example:

        LSR

In decimal mode, it'll be something like this (courtesy of "Multiplying and Dividing in Decimal Mode"):

        ROR
N08     PHP
        BPL HALF2
        SEC
        SBC #$30
HALF2   BIT N08
        BEQ HALF3
        SEC
        SBC #3
HALF3   PLP

Code like this would be in the inner loop of a decimal divide routine. The speed penalty is significant.

Answer 4

Using binary floating-point math would have made some kinds of computations much faster, but would have made many other tasks slower, and using BCD math was a reasonble engineering decision. Nowadays a screen full of binary-format numbers can be converted to text format so fast that the speed of such conversions is a non-issue, but in the 8-bit era that wasn't the case. Using binary floating-point computations would likely have doubled screen-redraw times in many realistic scenarios, causing the program to appear much slower.

While some kinds of computations might be an order of magnitude slower when using binary floating-point than when using BCD, and such computations may have stood out in the mind of developers far more than the vastly more frequent situations where using BCD made things faster, many spreadsheets were used for addition and subtraction far more than they were used for more complicated operations. If there were sufficient memory to cache both representations, invalidating the binary representation when a cell receives a decimal value or the sum or difference of two such values, computing the binary representation when a cell is used as a multipilcand, divisor, or dividend, and invalidating the decimal representation when storing a product or quotient, that might offer better performance than would be achieved by using either format exclusively, but I doubt the memory cost would have been tolerable.