Binary-coded decimal
Binary-coded decimal (BCD) is a method of encoding decimal numbers in binary form, where each individual decimal digit from 0 to 9 is represented by a fixed group of four binary bits corresponding to its pure binary value.[1][2] Developed in the early era of computing to reconcile the binary nature of digital hardware with the decimal system familiar to humans, BCD emerged as a hybrid representation that preserves decimal structure while using binary digits for storage and processing.[3] This approach was particularly prevalent in mid-20th-century mainframe systems, where it facilitated direct decimal arithmetic without the need for complex conversions that could introduce errors in binary-only representations.[4] Key variants include packed BCD, which stores two digits per byte for efficiency, and zoned BCD, often used in character encodings like EBCDIC for compatibility with text processing.[5] One primary advantage of BCD is its simplicity in converting between decimal and binary formats, making it ideal for applications requiring human-readable outputs, such as digital displays and calculators, where each digit can be directly mapped without algorithmic transformation.[5] Additionally, BCD arithmetic avoids the rounding discrepancies common in pure binary floating-point operations, ensuring exact representation of decimal fractions in fields like finance and scientific computation.[6] However, BCD is less storage-efficient than pure binary, as it utilizes only 10 of the 16 possible 4-bit combinations per digit, leading to up to 20% more space for the same numerical range and potentially slower processing due to specialized hardware or software handling.[7] Despite these drawbacks, BCD persists in modern embedded systems, real-time clocks, programmable logic controllers (PLCs), and legacy-compatible environments where decimal precision outweighs efficiency concerns.[6][7]Fundamentals
Definition and Principles
Binary-coded decimal (BCD) is a method of encoding decimal numbers in binary form by representing each individual decimal digit with a fixed group of bits, typically four bits to accommodate the digits 0 through 9.[8] This approach allows computers and digital systems to store and process decimal data directly in a form that mirrors the decimal structure, eliminating the need for repeated binary-to-decimal conversions during arithmetic operations.[3] In the standard BCD scheme, known as the 8421 weighted code, each decimal digit is encoded using four binary bits where the weights correspond to powers of 2 (8, 4, 2, 1).[9] The encodings are as follows: 0000 for 0, 0001 for 1, 0010 for 2, 0011 for 3, 0100 for 4, 0101 for 5, 0110 for 6, 0111 for 7, 1000 for 8, and 1001 for 9, with the remaining combinations (1010 through 1111) left unused to ensure unambiguous decimal representation.[9] This fixed-width encoding preserves the positional significance of each decimal digit, preventing issues like carry propagation from altering higher digits in ways that deviate from decimal arithmetic rules.[10] A key principle of BCD is its ability to maintain exact decimal values without the rounding or approximation errors inherent in binary representations of non-integer decimals, as each digit is handled independently and no fractional binary expansions are required.[3] For instance, the decimal number 29 is encoded in BCD as 0010 1001 (equivalent to hexadecimal 0x29), where the first nibble (0010) represents 2 and the second (1001) represents 9.[3] In terms of storage, BCD is less efficient than pure binary for the same numerical range; for example, decimal 99 requires 8 bits in BCD (1001 1001) but only 7 bits in binary (1100011).[8] This trade-off prioritizes decimal fidelity over compactness, making BCD suitable for applications where precise decimal handling is essential.[9]Historical Background
Binary-coded decimal (BCD) emerged in the context of early computing's need for decimal representation to align with human intuition and existing data processing equipment. In the 1940s, electromechanical machines like the Harvard Mark I utilized decimal mechanisms, such as wheels with ten positions for digits, to ensure outputs were directly readable and compatible with punch card tabulators, prioritizing usability over the emerging binary logic in electronic designs.[11] During the 1950s, IBM advanced BCD as a method to encode individual decimal digits using binary bits, facilitating the transition to electronic computers while preserving decimal accuracy for business applications. This development was integral to punch card systems and early machines like the IBM 1401 (introduced in 1959), which employed 6-bit BCD variants to represent numeric data efficiently in binary hardware.[12][13] Standardization accelerated in the 1960s with IBM's creation of the Extended Binary Coded Decimal Interchange Code (EBCDIC) around 1963–1964, building on prior BCD schemes to incorporate zoned formats for alphanumeric data. The IBM System/360 family, announced in 1964, embedded BCD support in its architecture to ensure compatibility with legacy IBM equipment, solidifying its role in commercial computing.[14] Although BCD waned in general-purpose personal computing from the 1970s onward, supplanted by pure binary for greater efficiency, it endured in financial and mainframe environments due to its precision in decimal operations, preventing errors in monetary computations within COBOL-based systems that process vast transaction volumes.[15]Primary Encodings
Packed BCD
Packed binary-coded decimal (PBCD), also known as packed BCD, encodes decimal numbers by storing two digits per 8-bit byte, with the high-order nibble (bits 7–4) representing the tens digit and the low-order nibble (bits 3–0) representing the units digit. Each nibble uses a 4-bit binary value from 0000 (0) to 1001 (9) to directly correspond to the decimal digit it encodes. This format optimizes storage compared to unpacked BCD by halving the space for digit representation, though it requires conversion for character-based input/output.[5][3] In fixed-point packed decimal, numbers are represented as pure integers without an embedded decimal point, allowing straightforward scaling by powers of 10 for fractional values during computation. Storage allocates full bytes for even-length digit sequences, while odd-length sequences use the high nibble of the final byte for the last digit, leaving the low nibble for the sign. The overall length in bytes is calculated as \lceil (d + 1)/2 \rceil, where d is the number of digits, accounting for the sign nibble. For example, the decimal 1234 (four digits) is stored in the digit portion as0x12 0x34 (binary 0001 0010 0011 0100), with the sign appended in an additional low nibble such as 0x0C for positive in a three-byte field.[16]
The sign in packed BCD is typically stored in a dedicated low-order nibble of the final byte, separate from the digits, using specific 4-bit patterns outside the 0–9 range. In IBM's format, 1100 (hex C) denotes positive, 1101 (hex D) denotes negative, and 1111 (hex F) indicates unsigned or positive-preferred. The hexadecimal values A–F (1010–1111) are generally unused for digit encoding to avoid ambiguity in BCD validity checks, but in the sign position, values like C, D, and F serve as zone or sign indicators, with others reserved for extensions or error detection in some systems.[16][17]
Zoned BCD
Zoned binary-coded decimal (ZBCD), also known as zoned decimal, represents each decimal digit using an 8-bit byte, where the low-order nibble (4 bits) encodes the digit value from 0 to 9, and the high-order nibble (4 bits) serves as a zone field typically set to a fixed value for compatibility with character encoding standards.[18][19] This format facilitates direct input/output operations with character-based peripherals, as the bytes correspond to printable digit characters in the respective code pages.[19] In the EBCDIC zoned decimal format, prevalent in IBM mainframe systems, the zone nibble is uniformly set to 1111 binary (hexadecimal F) for numeric digits, resulting in byte values from F0 to F9 hexadecimal for digits 0 through 9, respectively.[18][20] These encodings align with EBCDIC character codes for the digits, enabling seamless integration with text processing.[21] An ASCII variant of zoned decimal employs a zone nibble of 0011 0000 binary (hexadecimal 30, or decimal 48) for each digit, producing byte values such as 30 to 39 hexadecimal for digits 0 through 9; for instance, the digit 5 is encoded as 35 hexadecimal (0011 0101 binary).[19] This matches the standard ASCII codes for numeric characters, supporting compatibility in systems using 7- or 8-bit ASCII environments.[19] Fixed-point zoned decimal representations store integer numeric strings where each digit occupies a full byte with its zone, and the sign is encoded in the high-order nibble of the least significant (rightmost) byte: hexadecimal F indicates positive, while D indicates negative in EBCDIC, overriding the zone for the final digit.[18][22] Leading digits retain their standard zones (F in EBCDIC), ensuring the entire field can be treated as a character string for display or input.[18] Conversion from zoned decimal to packed BCD involves stripping the zone nibbles from each byte to isolate the digit nibbles, then combining pairs of consecutive digit nibbles into single bytes (high-order digit first), with the sign placed in the low-order nibble of the final byte; the result is right-aligned and may require padding if the digit count is odd.[22] The reverse process unpacks bytes into individual digit nibbles, inserts appropriate zone nibbles for each (F in EBCDIC), and applies the sign to the zone of the last byte.[22] This transformation aligns zoned data, which is I/O-oriented, with the denser packed format used for computation.[22] The following table illustrates EBCDIC zoned decimal encodings for digits 0-9 in unsigned form, along with signed variants in the low-order byte:| Decimal Digit | Unsigned Zoned Byte (Hex) | Positive Signed (Low-Order, Hex) | Negative Signed (Low-Order, Hex) |
|---|---|---|---|
| 0 | F0 | F0 | D0 |
| 1 | F1 | F1 | D1 |
| 2 | F2 | F2 | D2 |
| 3 | F3 | F3 | D3 |
| 4 | F4 | F4 | D4 |
| 5 | F5 | F5 | D5 |
| 6 | F6 | F6 | D6 |
| 7 | F7 | F7 | D7 |
| 8 | F8 | F8 | D8 |
| 9 | F9 | F9 | D9 |
Arithmetic Operations
Addition
Binary-coded decimal (BCD) addition involves processing each decimal digit independently using 4-bit nibbles, ensuring the result remains a valid BCD representation (0-9 per digit) by applying a correction mechanism when the binary sum exceeds 9.[23] The process begins with binary addition of corresponding nibbles from the two operands, followed by detection and adjustment for invalid sums to maintain decimal accuracy without full binary overflow handling.[24] The detailed steps for adding two BCD digits A and B, including an incoming carry C_in (0 or 1), are as follows: first, compute the temporary sum S_temp = A + B + C_in using binary addition; then, check if S_temp > 9 or if a carry-out occurred during the binary addition; if either condition is true, add 6 (binary 0110) to S_temp to produce the corrected digit S and set the outgoing carry C_out to 1; otherwise, C_out is 0 and S = S_temp.[25] This correction works because adding 6 to a value between 10 and 18 (the possible range for two digits plus carry) adjusts it to the range 16-24, which in binary triggers a carry-out of 1 while leaving the low 4 bits as the correct decimal digit (e.g., 10 + 6 = 16, low nibble 0000 with carry 1).[26] The equation for a single digit can be expressed as: S = (A + B + C_{in}) + 6 \cdot \delta, \quad C_{out} = \left\lfloor \frac{A + B + C_{in} + 6 \cdot \delta}{16} \right\rfloor where \delta = 1 if A + B + C_{in} > 9 or if there was a binary carry-out from the low 4 bits, else \delta = 0.[24] Consider the example of adding the BCD digits 9 (binary 1001) and 1 (binary 0001) with no incoming carry: the binary sum is 1010 (10 decimal), which exceeds 9, so add 6 (0110) to get 10000 (16 decimal), yielding a corrected low nibble of 0000 (0) and C_out = 1.[25] If this is the units digit in a multi-digit number, the carry propagates to the next higher digit's addition. For multi-digit addition in packed BCD format, where two digits are stored per byte (low nibble for units, high for tens), the process is repeated digit-by-digit from right to left, propagating the carry from each nibble addition to the next.[23] In systems like early IBM mainframes, this ensures compatibility with decimal-oriented peripherals, though some variants (e.g., certain legacy accounting machines) incorporate end-around carry for specific addition modes to handle sign propagation in signed BCD representations.[26] The final result maintains the packed structure, with the most significant digit potentially generating an overflow carry if needed.[24]Subtraction and Multiplication
Subtraction in binary-coded decimal (BCD) is commonly performed using the 10's complement method, which transforms the operation into an addition by complementing the subtrahend and then applying BCD addition rules to the minuend.[27] This approach avoids direct borrowing across digits, leveraging the same correction mechanisms as BCD addition (adding 6 to each nibble if the sum exceeds 9).[23] To compute the 10's complement of a BCD number, first find the 9's complement by subtracting each decimal digit D from 9 (i.e., $9 - D), then add 1 to the result, propagating any carry to higher digits.[26] The subtraction proceeds as follows: (1) obtain the 9's complement of the subtrahend; (2) add 1 to convert it to the 10's complement; (3) add this complement to the minuend using standard BCD addition with per-nibble corrections. If a carry is generated from the most significant digit, discard it to obtain the positive result (end-around carry may apply for the least significant digit in some implementations); absence of carry indicates a negative result, which can be handled by taking the 10's complement of the outcome.[27] For example, consider subtracting 13 from 25 in two-digit BCD. The subtrahend 13 has a 9's complement of 86 (9-1=8, 9-3=6). Adding 1 yields the 10's complement 87. Adding 25 + 87 = 112 (in binary: 0010 0101 + 1000 0111 = 1010 1100, corrected for BCD by adding 0110 to nibbles exceeding 9, but the decimal sum illustrates the process). Discarding the carry 1 gives the result 12.[23] An alternative direct method involves subtracting digit-by-digit with borrowing, applying a correction by subtracting 6 from the result nibble if a borrow occurs, to maintain valid BCD encoding.[28] Multiplication in BCD is typically implemented using a shift-and-add algorithm analogous to binary multiplication, but with partial products generated and accumulated via BCD addition instead of binary addition.[29] The multiplicand is shifted left by multiples of one digit position (equivalent to multiplying by powers of 10, implemented as left shifts by 4 bits in packed BCD), and added to the accumulator if the corresponding multiplier digit is non-zero, with BCD corrections applied after each addition. For efficiency with single digits, precomputed lookup tables can store the BCD-encoded products of two digits (0-9 × 0-9), reducing computation to table access and accumulation.[30] Division in BCD operates as the reciprocal of multiplication, often using a shift-and-subtract loop: the dividend is repeatedly compared to the shifted divisor, subtracting (via 10's complement addition) when possible and incrementing the quotient digit, akin to long division but with BCD arithmetic for each step.Implementations in Systems
Mainframe and IBM Systems
IBM's System/360 architecture, announced in 1964, pioneered native hardware support for binary-coded decimal (BCD) to address the needs of commercial computing, particularly for accurate decimal handling in business applications. The design incorporated instructions for both packed BCD, which stores two digits per byte, and zoned BCD, which uses one byte per digit with zone bits for character integration. This enabled efficient processing of financial data without the rounding errors common in binary floating-point representations.[31] Key instructions included PACK for converting zoned decimal to packed format, UNPACK for the reverse, and arithmetic operations such as ADD DECIMAL (AP) for addition, SUBTRACT DECIMAL (SP) for subtraction, MULTIPLY DECIMAL (MP), and DIVIDE DECIMAL (DP). These instructions operate on fields up to 31 digits plus a sign, packed into 16 bytes, with the CPU's decimal units performing native BCD addition and subtraction to support languages like COBOL. Hardware decimal adder circuits in the central processing unit directly manipulated BCD digits, ensuring precision for transactional workloads.[32][33] In IBM mainframes, zoned BCD integrates seamlessly with the EBCDIC character encoding, serving as the default representation for numeric character data in files and displays, where each digit occupies the low-order four bits of a byte and the high-order bits encode the zone (typically F for numeric digits). This format facilitated I/O operations and data interchange in early systems.[18] Support for BCD persisted into the IBM System/370 series of the 1970s, where instructions like those in System/360 were enhanced for extended addressing, with decimal arithmetic remaining a core feature for compatibility. By the post-2000 z/Architecture era, BCD instructions continued to be fully implemented for backward compatibility, even as binary operations dominated general-purpose computing, allowing legacy banking and financial software to run unchanged on modern hardware.[34] In contemporary IBM Z systems, BCD usage has declined for new applications but remains vital for precise decimal computations in sectors like banking, where packed BCD ensures exact representation of monetary values in COBOL-based transaction processing. Subsequent processors, including z15 (2019) with Enhanced Vector Facility, z16 (2022) with Advanced Vector Facility for packed decimals, and z17 (2025) with continued decimal support including decimal floating point packed conversion, further enhance BCD performance for AI-integrated workloads. Modern hybrids include hardware acceleration for Java's BigDecimal class, which emulates arbitrary-precision decimals using underlying BCD facilities to match mainframe-native performance. Additionally, the z14 processor introduced the Vector Packed Decimal Facility in 2017, enabling SIMD-style operations on BCD data in 16-byte vector registers to accelerate legacy workloads without code changes.[35][36][37][38]Microprocessors and Other Computers
Binary-coded decimal (BCD) support in microprocessors and other non-mainframe computers has primarily manifested through specialized instructions for adjusting binary arithmetic results to valid BCD representations, reflecting the need for precise decimal computations in early personal and minicomputer systems. The Intel 8086 microprocessor, introduced in 1978, included the Decimal Adjust After Addition (DAA) and Decimal Adjust After Subtraction (DAS) instructions to facilitate packed BCD operations.[39] These instructions operate on the AL register, assuming two unpacked BCD digits (one in the upper nibble and one in the lower nibble), and correct the result of a prior ADD or SUB instruction by adding or subtracting 6 from the affected nibble if it exceeds 9 or if the auxiliary carry flag is set, thereby ensuring the final value remains a valid BCD number. For example, the DAA instruction's pseudocode is as follows:This adjustment mechanism updates the carry flag (CF) and auxiliary carry flag (AF) accordingly, enabling efficient BCD arithmetic without full hardware decimal adders.[40] Similar instructions, such as AAA (ASCII Adjust After Addition) and AAS (ASCII Adjust After Subtraction), extend support to zoned BCD formats using ASCII encoding.[41] In extensions to the x86 architecture, AMD64 maintains compatibility with these BCD instructions but restricts their use to 16-bit and 32-bit modes, excluding them from 64-bit long mode due to performance overhead and the dominance of binary arithmetic in modern computing.[42] ARM architectures, designed as reduced instruction set computing (RISC) processors, do not include dedicated hardware BCD operations as standard features; any BCD handling is implemented via software routines, though some vendor-specific extensions or coprocessor interfaces may offer optional decimal support in embedded contexts. Historical minicomputers like the DEC PDP-11 provided limited BCD support through software libraries for decimal arithmetic, relying on binary instructions for core operations.[43] In contrast, the DEC VAX architecture, evolving from the PDP-11 in the late 1970s, incorporated native instructions for decimal string operations, including packed BCD formats compatible with zoned encodings, such as MOVTC for character translation and addition/subtraction on variable-length decimal strings.[44] These VAX instructions treated BCD data as numeric strings, supporting up to 31 digits with sign, and were optimized for business applications requiring exact decimal precision.[45] Burroughs Corporation's medium and large systems from the 1950s through the 1980s, such as the B5000 (1959) and B6700 (1971), were designed with native BCD arithmetic units using a stack-based architecture to execute COBOL efficiently. These machines performed serial, character-at-a-time decimal operations on BCD-encoded data, storing numbers as alphanumeric strings in memory with each digit occupying six bits (including a zone bit), and utilized a polish notation stack for operand handling without general-purpose registers.[46] This approach minimized conversion overhead for decimal I/O and arithmetic, making Burroughs systems particularly suited for financial and accounting tasks during that era.[47] In contemporary systems lacking hardware BCD support, software emulations prevail, such as Python's decimal module, which implements arbitrary-precision decimal arithmetic using BCD-like internal representations to avoid floating-point rounding errors in financial calculations. Field-programmable gate arrays (FPGAs) also enable custom BCD implementations, where designers replicate decimal adders and adjusters in hardware for specialized applications like legacy system emulation or high-speed transaction processing. The overhead of BCD operations—typically 2-3 times slower than binary due to adjustment steps and larger data widths—has led to sparse hardware support in post-1990s RISC and CISC processors, favoring software libraries for decimal needs in general-purpose computing.[40]if (AL > 9) or (AF == 1) then AL = AL + 6 CF = (CF or (original_AL > 9)) end if if (AH > 9) or (CF == 1) then AH = AH + 6 CF = 1 end ifif (AL > 9) or (AF == 1) then AL = AL + 6 CF = (CF or (original_AL > 9)) end if if (AH > 9) or (CF == 1) then AH = AH + 6 CF = 1 end if
Hardware and Electronics Usage
Digital Circuits for BCD
Binary-coded decimal (BCD) digital circuits are designed to perform arithmetic operations on decimal digits represented in binary form, ensuring that each 4-bit nibble corresponds to a valid decimal value from 0 to 9. These circuits are essential in hardware implementations where decimal accuracy is paramount, such as in financial systems and calculators. A fundamental component is the BCD adder, which adds two BCD digits along with a possible carry-in, producing a BCD sum and carry-out. The design incorporates correction logic to handle cases where the binary sum exceeds 9, preventing invalid BCD representations.[48] The BCD adder circuit typically employs a full adder structure augmented with correction logic implemented using AND gates for detecting invalid sums and a multiplexer (MUX) for adding 6 (binary 0110) when necessary. Specifically, the detection logic identifies conditions where the intermediate binary sum is greater than 9 or generates an auxiliary carry, triggering the addition of 6 to adjust the result back to a valid BCD range. This correction ensures decimal integrity without altering the underlying binary arithmetic hardware. The logic uses gates to compute a correction signal, often defined as K = S3·S2 + S3·S1 + C4, where S3–S0 are the bits of the initial sum and C4 is the carry from the first addition stage.[49][25][48] At the gate level, a 4-bit BCD adder is constructed using two 4-bit binary adders in series. The first binary adder computes the initial sum of the two 4-bit BCD inputs (A3–A0 and B3–B0) plus a carry-in, yielding a 4-bit sum (S3–S0) and an auxiliary carry (C4). If the correction signal K is active (indicating S > 9 or C4 = 1), the second binary adder adds 0110 to this sum, producing the final BCD outputs (final S3–S0) and the overall carry-out. This serial arrangement leverages standard binary full adders, minimizing custom logic while introducing a small delay for correction. The carry-out from the second adder serves as the decimal carry to the next digit.[48] For multi-digit BCD addition, carry propagation is managed through chainable designs analogous to binary adders but adapted for decimal correction at each stage. Ripple-carry BCD adders connect the carry-out of one 4-bit stage to the carry-in of the next, propagating the decimal carry sequentially; this is simple but incurs cumulative delays proportional to the number of digits. In contrast, carry-lookahead BCD adders (CLA) precompute generate and propagate signals across digits, incorporating decimal adjustment logic to reduce propagation delay, making them suitable for high-speed applications despite increased gate complexity. These adaptations ensure efficient handling of carries in decimal contexts, with CLA variants offering logarithmic delay scaling for longer operands.[50] An example schematic for a single-digit 4-bit BCD adder takes inputs A3–A0 and B3–B0 (each representing decimal digits 0–9), along with a carry-in (Cin). The first 4-bit binary adder outputs temporary sum bits T3–T0 and auxiliary carry Caux. The correction logic then evaluates if (T3–T0 > 1001 binary or Caux = 1), activating the MUX to select either 0000 or 0110 for addition in the second 4-bit binary adder, which produces final sum bits S3–S0 and carry-out Cout. This design ensures the output S3–S0 is a valid BCD digit, with Cout indicating a decimal carry of 1.[48] BCD circuits have been integrated into arithmetic logic units (ALUs) of early microprocessors to support decimal operations. For instance, the Intel 4004, released in 1971, featured a 4-bit ALU with a Decimal Adjust Accumulator (DAA) instruction that implemented BCD correction logic post-binary addition, enabling efficient decimal arithmetic in calculator applications. This hardware support for BCD adjustment was crucial for the chip's target use in Busicom's decimal-based systems.[51][52] Due to the additional correction logic and serial adder stages, BCD circuits exhibit higher latency and power consumption compared to pure binary counterparts.[53][54]Displays and Peripherals
Binary-coded decimal (BCD) plays a crucial role in interfacing digital systems with output devices that require direct decimal representation, particularly in visual displays and input peripherals. One prominent application is in seven-segment displays, where BCD-to-seven-segment decoder chips convert 4-bit BCD codes into signals that activate the appropriate LED or LCD segments to form decimal digits. The SN54LS47, a low-power Schottky TTL integrated circuit, exemplifies this by accepting BCD inputs on pins A-D and driving common-anode seven-segment displays via active-low outputs on pins a-g, ensuring efficient segment illumination without binary-to-decimal conversion overhead.[55] The conversion logic maps each BCD digit from 0000 (0) to 1001 (9) to a unique combination of the seven segments (labeled a through g), with invalid BCD codes (1010 to 1111) typically blanking the display to prevent erroneous symbols. For instance, BCD 0000 activates segments a, b, c, d, e, and f while deactivating g to display '0'. The following table illustrates the output states for digits 0-9, where 0 indicates an active (lit) segment and 1 indicates inactive:| BCD Input | a | b | c | d | e | f | g | Digit |
|---|---|---|---|---|---|---|---|---|
| 0000 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
| 0001 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
| 0010 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 2 |
| 0011 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 3 |
| 0100 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 4 |
| 0101 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 5 |
| 0110 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 6 |
| 0111 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 7 |
| 1000 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 8 |
| 1001 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 9 |