Binary-Coded Decimal stores each decimal digit in its own 4-bit nibble instead of converting the whole number to base 2 — so 1234 becomes 0001 0010 0011 0100, not 0100 1101 0010. Financial systems, HP calculators, IBM mainframes (COMP-3), digital clocks, and every 7-segment driver still lean on it because the digits can be read off directly with no divide-by-10. Convert between decimal and packed, unpacked, Excess-3, and Aiken 2-4-2-1 forms below.
Two decimal digits per byte, sign nibble in the low half of the last byte. Used by IBM z/OS, Oracle NUMBER, and every DB2 COMP-3 column.
One digit per byte (low nibble), zone nibble in the high half. EBCDIC uses F, ASCII uses 3 so digits become '0'–'9'.
Add 3 to every digit before encoding. Self-complementing: nines' complement is bitwise NOT. Used in old TTL adders (74HC163).
Weighted 2-4-2-1 instead of 8-4-2-1. Also self-complementing. Digits 0–4 keep 8421 form, 5–9 use the shifted range.
| digit | 8-4-2-1 (BCD) | Excess-3 | Aiken 2-4-2-1 | Gray |
|---|
Packed BCD is not going away because it solves a problem plain binary cannot: exact base-10 arithmetic. A 64-bit IEEE-754 double cannot represent 0.1 exactly — a US-dollar transaction that adds ten cents ten times drifts away from a dollar. Packed BCD represents each digit exactly, so a COBOL PIC S9(11)V99 field holding 12345678901.23 stores the same 14 nibbles on any machine, byte for byte, with the sign nibble encoding sign (C=+, D=−, F=unsigned). x86 kept a DAA instruction (Decimal Adjust after Addition) through 32-bit long-mode for exactly this. Even modern chips ship a decimal-floating-point (DFP) unit on IBM z16, POWER, and some ARM cores — DFP is packed BCD's grand-nephew. If you ever debug a mainframe hex dump, decode a barcode payload, or read a smart-meter register, you'll meet 4-bit digits again.