On 2018-12-12 18:59, Dennis Lee Bieber wrote:
On Wed, 12 Dec 2018 00:46:03 -0500, "Avi Gross" <avigr...@verizon.net>
declaimed the following:
All kidding aside, I note that some data that is stored in a fixed width has
zeroes padding it all the way to the right. If you store the number 3 in binary
as a byte, it tends to look like 00000011. Depending on how integers are
stored, something similar can happen for longer stretches. But with decimals,
we tend to not bother showing the empty areas that represent 0 times ever
higher powers of 10.
Original COBOL implementation performs arithmetic on BCD (more likely,
packed BCD). With two decimal digits per byte (packed BCD), a common
32-digit number requires 16 bytes, or 4 longwords (given the size of
processors in 1960). Since arithmetic is basically an array operation in
BCD (process least significant digit, process next digit..., etc.) numbers
required storage of the filler zeros.
Furthermore, of more significance, formatting of a BCD number for
output merely required taking each BCD digit (unpacked) or nybble (packed)
and ADDING the value of (ASCII) "0". Conversely, input of (ASCII) fixed
width/filled numbers simply requires subtracting "0" from each digit to get
the BCD value for it (followed by packing the right-side nybbles to get
packed BCD)
The Intel 8080 includes a DAA (decimal adjust accumulator) instruction
to "correct" an 8-bit value back to packed BCD. Adding two 2-digit BCD
values using normal binary ADD/ADC would result in an incorrect binary
value (the source wasn't binary, but the result isn't BCD), DAA would
adjust that back to BCD, using a "half carry" flag to handle the internal
digit split.
Later processors have a DAS instruction, which is used after BCD
subtraction.
The humble 6502 doesn't have DAA/DAS, but instead has a decimal mode flag.
There's a clever way to perform BCD addition on long BCD numbers
(32-bit, 64-bit, whatever) without having to do it 1 digit (or 1 byte)
at a time.
--
https://mail.python.org/mailman/listinfo/python-list
