On these early CPUs, conversion from binary to decimal could be very expensive. It required an integer division by 10, and the division must be done in software

On these early CPUs, conversion from binary to decimal could be very expensive. It required an integer division by 10, and the division must be done in software. Replacing it with shift-and-add calculations is not a solution, since fast bitshifts was only possible with a barrel shifter, which was also nonexistent on an early 8-bit CPU. If the integer is a fixed-width data type, say a 16-bit integer, a common algorithm was repeatedly subtracting 10000, 1000, 100, 10, etc., from the number. Not very efficient in terms of algorithm, but it can be implemented in a few lines of fast assembly. Still, if the number is frequently updated (perhaps a spreadsheet, or an on-screen score in a game), the fastest solution was storing it in BCD and avoiding the conversion. So native support of BCD arithmetic was not just a legacy due to desk calculators or compatibility, but also necessity. Earlier discrete logic circuits and calculators used BCD for the same reason. Conversion from BCD to readable formats like a 7-segment display or ASCII output was simple and only requires simple combinational logic. It's fortunate that computers are advanced enough today that we usually don't need to worry about the overhead of printf("%d", integer) anymore.