Binary-coded decimal: Difference between revisions

Content deleted Content added
Citation bot (talk | contribs)
Removed URL that duplicated identifier. Removed parameters. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 279/1032
 
(20 intermediate revisions by 12 users not shown)
Line 1:
{{Short description|System of digitally encoding numbers}}
{{redirredirect|BCD code|BCD character sets|BCD (character encoding)||}}
{{Use dmy dates|date=May 2019|cs1-dates=y}}
{{Use list-defined references|date=January 2022}}
Line 6:
[[File:Binary clock.svg|250px|thumbnail|right|A [[binary clock]] might use [[Light-emitting diode|LED]]s to express binary values. In this clock, each column of LEDs shows a binary-coded decimal numeral of the traditional [[sexagesimal]] time.]]
 
In [[computing]] and [[electronics|electronic]] systems, '''binary-coded decimal''' ('''BCD''') is a class of [[Binary numeral systemnumber|binary]] encodings of [[decimal]] numbers where each [[numerical digit|digit]] is represented by a fixed number of [[bit]]s, usually four or eight. Sometimes, special bit patterns are used for a [[Sign (mathematics)|sign]] or other indications (e.g. error or overflow).
 
In [[byte]]-oriented systems (i.e. most modern computers), the term ''unpacked'' BCD<ref name="Intel_IA32"/> usually implies a full byte for each digit (often including a sign), whereas ''packed'' BCD typically encodes two digits within a single byte by taking advantage of the fact that four bits are enough to represent the range 0 to 9. The precise four-bit encoding, however, may vary for technical reasons (e.g. [[Excess-3]]).
 
{{anchor|Pseudo-tetrade}}The ten states representing a BCD digit are sometimes called ''[[tetrade (computing)|tetrade]]s''<ref name="Klar_1970"/><ref name="Klar_1989"/> (the [[nibble]] typically needed to hold them is also known as a tetrade) while the unused, [[don't care]]-states are named {{Interlanguage link multi|pseudo-tetrade|de|3=Pseudotetrade|lt=''pseudo-tetrad(e)s''{{small|{{bracket|[[:de:Pseudotetrade|de]]}}}},<ref name="Schneider_1986"/><ref name="Tafel_1971"/><ref name="Steinbuch-Weber-Heinemann_1974"/><ref name="Tietze-Schenk_2013"/><ref name="Kowalski_1070"/> ''pseudo-decimals'',<ref name="Klar_1989"/> or ''pseudo-decimal digits''.<ref name="Ferretti_2013"/><ref name="Speiser_1965"/><ref group="nb" name="Pseudo-tetrades"/>
 
BCD's main virtue, in comparison to binary [[positional system]]s, is its more accurate representation and rounding of decimal quantities, as well as its ease of conversion into conventional<!-- many among us can read hexidecimal just fine, though we don't ordinarily memorize the hexadecimal times table --> human-readable representations. Its principal drawbacks are a slight increase in the complexity of the circuits needed to implement basic arithmetic as well as slightly less dense storage.
 
BCD was used in many early [[decimal computer]]s, and is implemented in the instruction set of machines such as the [[IBM System/360]] series and its descendants, [[Digital Equipment Corporation]]'s [[VAX]], the [[Burroughs B1700]], and the Motorola [[68000]]-series processors.
 
BCD ''per se'' is not as widely used as in the past, and is unavailable or limited in newer instruction sets (e.g., [[ARM architecture family|ARM]]; [[x86]] in [[long mode]]). However, decimal [[Fixed-point arithmetic|fixed-point]] and decimal [[floating-point]] formats are still important and continue to be used in financial, commercial, and industrial computing, where the subtle conversion and fractional [[round-off error|rounding errors]] that are inherent in binary floating point formats cannot be tolerated.<ref name="Cowlishaw_GDA" />
Line 234:
The following table represents [[decimal]] digits from 0 to 9 in various BCD encoding systems. In the headers, the "<code>8{{thinsp}}4{{thinsp}}2{{thinsp}}1</code>" indicates the weight of each bit. In the fifth column ("BCD&nbsp;8{{thinsp}}4{{thinsp}}−2{{thinsp}}−1"), two of the weights are negative. Both ASCII and EBCDIC character codes for the digits, which are examples of zoned BCD, are also shown.
 
{| borderclass="1" cellpadding="2" cellspacing="0wikitable" style="margin:auto;"
|-
! style="background:#e0e0e0;"| &nbsp;<br />Digit
Line 360:
==Packed BCD==
<!-- Section header used in redirects -->
InSome computers whose words are multiples of an [[Octet (computing)|octet]] (8-bit byte), for example contemporary IBM mainframe systems, support '''packed BCD''' (or '''packed decimal'''<ref name="Dewar-Smosna_1990"/>) numeric representations, in which each [[nibble]] represents either a decimal digit or a sign.<ref group="nb" name="Packed_chars"/> Packed BCD has been in use since at least the 1960s and is implemented in all IBM mainframe hardware since then. Most implementations are [[big endian]], i.e. with the more significant digit in the upper half of each byte, and with the leftmost byte (residing at the lowest memory address) containing the most significant digits of the packed decimal value. The lower nibble of the rightmost byte is usually used as the sign flag, although some unsigned representations lack a sign flag.
 
As an example, a 4-byte value consists of 8 nibbles, wherein the upper 7 nibbles store the digits of a 7-digit decimal value, and the lowest nibble indicates the sign of the decimal integer value. Standard sign values are 1100 ([[hexadecimal|hex]] C) for positive (+) and 1101 (D) for negative (−). This convention comes from the zone field for [[EBCDIC]] characters and the [[signed overpunch]] representation.
 
Other allowed signs are 1010 (A) and 1110 (E) for positive and 1011 (B) for negative. IBM System/360 processors will use the 1010 (A) and 1011 (B) signs if the A bit is set in the PSW, for the ASCII-8 standard that never passed. Most implementations also provide unsigned BCD values with a sign nibble of 1111 (F).<ref name="IBM_1980_POP"/><ref name="DEC_1983_PDP11"/><ref name="DEC_1985_VAX11"/> ILE RPG uses 1111 (F) for positive and 1101 (D) for negative.<ref name="ILE-RPG"/> These match the EBCDIC zone for digits without a sign overpunch. In packed BCD, the number 127 is represented by 0001 0010 0111 1100 (127C) and −127 is represented by 0001 0010 0111 1101 (127D). Burroughs systems used 1101 (D) for negative, and any other value is considered a positive sign value (the processors will normalize a positive sign to 1100 (C)).
Line 403:
|}
 
No matter how many bytes wide a [[Word (datacomputer typearchitecture)|word]] is, there is always an even number of nibbles because each byte has two of them. Therefore, a word of ''n'' bytes can contain up to (2''n'')−1 decimal digits, which is always an odd number of digits. A decimal number with ''d'' digits requires {{sfrac|1|2}}(''d''+1) bytes of storage space.
 
For example, a 4-byte (32-bit) word can hold seven decimal digits plus a sign and can represent values ranging from ±9,999,999. Thus the number −1,234,567 is 7 digits wide and is encoded as:
Line 417:
Packed BCD is supported in the [[COBOL]] programming language as the "COMPUTATIONAL-3" (an IBM extension adopted by many other compiler vendors) or "PACKED-DECIMAL" (part of the 1985 COBOL standard) data type. It is supported in [[PL/I]] as "FIXED DECIMAL". Beside the IBM System/360 and later compatible mainframes, packed BCD is implemented in the native instruction set of the original [[VAX]] processors from [[Digital Equipment Corporation]] and some models of the [[SDS Sigma series]] mainframes, and is the native format for the [[Burroughs Medium Systems]] line of mainframes (descended from the 1950s [[Burroughs 205|Electrodata 200 series]]).
 
[[Ten's complement]] representations for negative numbers offer an alternative approach to encoding the sign of packed (and other) BCD numbers. In this case, positive numbers always have a most significant digit between 0 and 4 (inclusive), while negative numbers are represented by the 10's complement of the corresponding positive number.
 
As a result, this system allows for 32-bit packed BCD numbers to range from −50,000,000 to +49,999,999, and −1 is represented as 99999999. (As with two's complement binary numbers, the range is not symmetric about zero.)
Line 434:
 
=={{anchor|Zoned BCD}}Zoned decimal==
Some implementations, for example [[IBM]] mainframe systems, support '''zoned decimal''' numeric representations. Each decimal digit is stored in one 8-bit<ref group=nb>6-bit for older machines.</ref> byte, with the lower four bits encoding the digit in BCD form. The upper four<ref group=nb>Two for older machines.</ref> bits, called the "zone" bits, are usually set to a fixed value so that the byte holds a character value corresponding to the digit, or to values representing plus or minus. EBCDIC<ref group=nb>The values shown for {{base|C0|16}} and {{base|D0|16}} are for code page 037.</ref> systems use a zone value of {{base|1111|2}} (hex {{base|F|16}});, thisyielding yields{{base|F0|16}}-{{base|F9|16}}, bytesthe incodes thefor range"0" F0through to"9", F9a zone value of {{base|1100|2}} (hex{{base|C|16}}) for positive, whichyielding are{{base|C0|16}}-{{base|C9|16}}, the EBCDICcodes for "{" through "I" and a zone value of {{base|1110|2}} ({{base|D|16}}) for negative, yielding {{base|D0|16}}-{{base|D9|16}}, the codes for the characters "0}" through "9R". Similarly, ASCII systems use a zone value of 0011 (hex 3), giving character codes 30 to 39 (hex).
 
For signed zoned decimal values, the rightmost (least significant) zone nibble holds the sign digit, which is the same set of values that are used for signed packed decimal numbers (see above). Thus a zoned decimal value encoded as the hex bytes F1 F2 D3 represents the signed decimal value −123:
Line 699:
IBM used the terms ''[[Binary-Coded Decimal Interchange Code]]'' (BCDIC, sometimes just called BCD), for 6-bit ''[[alphanumeric]]'' codes that represented numbers, upper-case letters and special characters. Some variation of BCDIC ''alphamerics'' is used in most early IBM computers, including the [[IBM 1620]] (introduced in 1959), [[IBM 1400 series]], and non-[[IBM 700/7000 series#Decimal architecture (7070/7072/7074)|decimal architecture]] members of the [[IBM 700/7000 series]].
 
The IBM 1400 series are character-addressable machines, each ___location being six bits labeled ''B, A, 8, 4, 2'' and ''1,'' plus an odd parity check bit (''C'') and a word mark bit (''M''). For encoding digits ''1'' through ''9'', ''B'' and ''A'' are zero and the digit value represented by standard 4-bit BCD in bits ''8'' through ''1''. For most other characters bits ''B'' and ''A'' are derived simply from the "12", "11", and "0" "zone punches" in the [[punched card]] character code, and bits ''8'' through ''1'' from the ''1'' through ''9'' punches. A "12 zone" punch set both ''B'' and ''A'', an "11 zone" set ''B'', and a "0 zone" (a 0 punch combined with any others) set ''A''. Thus the letter '''A''', which is ''(12,1)'' in the punched card format, is encoded ''(B,A,1)''. The currency symbol '''$''', ''(11,8,3)'' in the punched card, was encoded in memory as ''(B,8,2,1)''. This allows the circuitry to convert between the punched card format and the internal storage format to be very simple with only a few special cases. One important special case is digit ''0'', represented by a lone ''0'' punch in the card, and ''(8,2)'' in core memory.<ref name="Thelen_Van1401Van1401"/>
 
The memory of the IBM 1620 is organized into 6-bit addressable digits, the usual ''8, 4, 2, 1'' plus ''F'', used as a flag bit and ''C'', an odd parity check bit. BCD ''alphamerics'' are encoded using digit pairs, with the "zone" in the even-addressed digit and the "digit" in the odd-addressed digit, the "zone" being related to the ''12'', ''11'', and ''0'' "zone punches" as in the 1400 series. Input/output translation hardware converted between the internal digit pairs and the external standard 6-bit BCD codes.
Line 714:
The Digital Equipment Corporation [[VAX]] series includes [[Instruction set|instructions]] that can perform arithmetic directly on packed BCD data and convert between packed BCD data and other integer representations.<ref name="DEC_1985_VAX11"/> The VAX's packed BCD format is compatible with that on IBM System/360 and IBM's later compatible processors. The MicroVAX and later VAX implementations dropped this ability from the CPU but retained code compatibility with earlier machines by implementing the missing instructions in an operating system-supplied software library. This is invoked automatically via [[exception handling]] when the defunct instructions are encountered, so that programs using them can execute without modification on the newer machines.
 
Many processors have hardware support for BCD-encoded integer arithmetic. For example, the [[6502]],<ref>[{{cite web |url=http://www.masswerk.at/6502/6502_instruction_set.html |title=6502 Instruction Set] {{Webarchive|archive-url=https://web.archive.org/web/20180508053805/http://www.masswerk.at/6502/6502_instruction_set.html |archive-date=2018-05-08 |url-status=live}}.</ref><ref>[{{cite web |url=http://www.6502.org/tutorials/6502opcodes.html |title=NMOS 6502 Opcodes]. {{Webarchive|archive-url=https://web.archive.org/web/20160114001557/http://www.6502.org/tutorials/6502opcodes.html |archive-date=2016-01-14}}.</ref> the [[Motorola 68000 series]],<ref name="Motorola_m68k"/> and the [[x86]] series.<ref>{{cite book|url= http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf|title= Intel 64 and IA-32 Architectures Software Developer's Manual Volume 1: Basic Architecture|at= Section 4.7|publisher= Intel|date= March 2013|access-date= April 23, 2013|archive-date= April 2, 2013|archive-url= https://web.archive.org/web/20130402233513/http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf|url-status= live}}</ref> The [[Intel]] x86 architecture supports a [[Intel BCD opcodes|unique 18-digit (ten-byte) BCD format]] that can be loaded into and stored from the floating point registers, from where computations can be performed.<ref name="Intel_2020_V1"/>
 
In more recent computers such capabilities are almost always implemented in software rather than the CPU's instruction set, but BCD numeric data are still extremely common in commercial and financial applications.
Line 737:
{{Multiple issues|section=true|{{More citations needed section|date=January 2018}}{{Primary sources|section|date=January 2018}}}}
 
BCD is common in electronic systems where a numeric value is to be displayed, especially in systems consisting solely of digital logic, and not containing a microprocessor. By employing BCD, the manipulation of numerical data for display can be greatly simplified by treating each digit as a separate single sub-circuit.
 
This matches much more closely the physical reality of display hardware—a designer might choose to use a series of separate identical [[seven-segment display]]s to build a metering circuit, for example. If the numeric quantity were stored and manipulated as pure binary, interfacing with such a display would require complex circuitry. Therefore, in cases where the calculations are relatively simple, working throughout with BCD can lead to an overall simpler system than converting to and from binary. Most pocket calculators do all their calculations in BCD.
Line 746:
<!-- not at all clear why this needs to be here at all, shouldn't the article just describe BCD? (mfc)-->
<!--as an alternative number system for computing and electronics imo a comparison to the standard one is justified (plugwash)-->
 
=== Advantages ===
* Scaling by a power of 10 is simple.
* [[Rounding]] at a decimal digit boundary is simpler. Addition and subtraction in decimal do not require rounding.{{dubious|Rounding|date=November 2021}}
* The alignment of two decimal numbers (for example 1.3 + 27.08) is a simple, exact shift.
* Conversion to a character form or for display (e.g., to a text-based format such as [[XML]], or to drive signals for a [[seven-segment display]]) is a simple per-digit mapping, and can be done in linear ([[Big-O notation|O]](''n'')) time. Conversion from pure [[binary number|binary]] involves relatively complex logic that spans digits, and for large numbers, no linear-time conversion algorithm is known (see {{see section link|Binary number|Conversion to and from other numeral systems}}).
* Many non-integral values, such as decimal 0.2, have an infinite place-value representation in binary (.001100110011...) but have a finite place-value in binary-coded decimal (0.0010). Consequently, a system based on binary-coded decimal representations of decimal fractions avoids errors representing and calculating such values. This is useful in financial calculations.
 
=== Disadvantages ===
* Practical existing implementations of BCD are typically slower than operations on binary representations, especially on embedded systems, due to limited processor support for native BCD operations.<ref name="Mathur_1989" />
* Some operations are more complex to implement. [[Adder (electronics)|Adder]]s require extra logic to cause them to wrap and generate a carry early. Also, 15 to 20 per cent% more circuitry is needed for BCD add compared to pure binary.{{Citation needed|date=May 2011}} Multiplication requires the use of algorithms that are somewhat more complex than shift-mask-add (a [[Binary numeral system#Multiplication|binary multiplication]], requiring binary shifts and adds or the equivalent, per-digit or group of digits is required).
* Standard BCD requires four bits per digit, roughly 20 per cent% more space than a binary encoding (the ratio of 4 bits to log<sub>2</sub>10 bits is 1.204). When packed so that three digits are encoded in ten bits, the storage overhead is greatly reduced, at the expense of an encoding that is unaligned with the 8-bit byte boundaries common on existing hardware, resulting in slower implementations on these systems.<!-- Could add: encoding or decoding is trivial in software using a table lookup, and fast using direct logic otherwise. In hardware, it requires no more than three gate delays. -->
 
==Representational variations==
Line 791 ⟶ 792:
 
==={{anchor|TBCD}}Telephony binary-coded decimal (TBCD)===
[[3GPP]] developed '''TBCD''',<ref name="3GPP_2013_TS29002"/> an expansion to BCD where the remaining (unused) bit combinations are used to add specific [[telephony]] characterssymbols,<ref name="ETSI_SPS"/><ref name="OpenSS_XMAP"/> with digits similar to those found in [[DTMF|telephone keypad]]s original design.
{| class="wikitable" style="width:30%; text-align:center"
|-
Line 825 ⟶ 826:
Meaning number <code>1234</code>, would become <code>21 43</code> in TBCD.
 
This format is used in modern [[mobile telephony]] to send dialed numbers, as well as [[Mobile country code|operator ID]] (the MCC/MNC tuple), [[International Mobile Equipment Identity|IMEI]], [[International mobile subscriber identity|IMSI]] (SUPI), et.c.<ref>{{cite web|url=https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/16.10.00_60/ts_124501v161000p.pdf|title=Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3. (3GPP TS 24.501 version 16.10.0 Release 16) TS 24.501 release 16.10.0|publisher=[[ETSI]] and [[3GPP]]|access-date=February 26, 2022|archive-date=February 17, 2022|archive-url=https://web.archive.org/web/20220217231615/https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/16.10.00_60/ts_124501v161000p.pdf|url-status=live}} (TS 24.501)</ref><ref>{{cite web|url=https://www.etsi.org/deliver/etsi_ts/123000_123099/123003/16.08.00_60/ts_123003v160800p.pdf|title=Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; Numbering, addressing and identification (3GPP TS 23.003 version 16.8.0 Release 16)|publisher=[[ETSI]] and [[3GPP]]|access-date=February 26, 2022|archive-date=February 26, 2022|archive-url=https://web.archive.org/web/20220226144220/https://www.etsi.org/deliver/etsi_ts/123000_123099/123003/16.08.00_60/ts_123003v160800p.pdf|url-status=live}} (TS 23.003)</ref>
 
==Alternative encodings==
Line 842 ⟶ 843:
 
==Legal history==
In the 1972 case ''[[Gottschalk v. Benson]]'', the [[U.S. Supreme Court]] overturned a [[United States Court of Customs and Patent Appeals|lower court]]'s decision that had allowed a [[patent]] for converting BCD-encoded numbers to binary on a computer.
 
The decision noted that a patent "would wholly pre-empt the mathematical formula and in practical effect would be a patent on the [[algorithm]] itself".<ref name="Gottschalk-Benson_1972" /> This was a landmark judgement that determined the [[Software patents under United States patent law|patentability of software and algorithms]].
Line 889 ⟶ 890:
<ref name="Dewar-Smosna_1990">{{cite book |title=Microprocessors - A Programmer's View |author-first1=Robert Berriedale Keith |author-last1=Dewar |author-link1=Robert Berriedale Keith Dewar |author-first2=Matthew |author-last2=Smosna |date=1990 |edition=1 |publisher=[[McGraw-Hill Publishing Company]] |___location=[[Courant Institute]], [[New York University]], New York, USA |isbn=0-07-016638-2 |lccn=89-77320 |page=14}} (xviii+462 pages)</ref>
<ref name="Savard_2018_Decimal">{{cite web |title=Decimal Representations |author-first=John J. G. |author-last=Savard |date=2018 |orig-date=2006 |work=quadibloc |url=http://www.quadibloc.com/comp/cp0203.htm |access-date=2018-07-16 |url-status=live |archive-url=https://web.archive.org/web/20180716101321/http://www.quadibloc.com/comp/cp0203.htm |archive-date=2018-07-16}}</ref>
<ref name="Yuen_1977">{{cite journal |title=A New Representation for Decimal Numbers |author-first=Chun-Kwong |author-last=Yuen |journal=[[IEEE Transactions on Computers]] |date=December 1977 |volume=C-26 |issue=12 |doi=10.1109/TC.1977.1674792 |s2cid=40879271 |pages=1286–1288 |url=https://dl.acm.org/doi/10.1109/TC.1977.1674792 |access-date=2020-08-08 |url-status=live |archive-url=https://web.archive.org/web/20200808105531/https://dl.acm.org/doi/10.1109/TC.1977.1674792 |archive-date=2020-08-08|url-access=subscription }}</ref>
<ref name="Kautz_1954">{{cite conference |title=Optimized Data Encoding for Digital Computers |chapter=IV. Examples A. Binary Codes for Decimals, n = 4 |author-last=Kautz |author-first=William H. |author-link=William H. Kautz |conference=Convention Record of the I.R.E., 1954 National Convention, Part 4 - Electronic Computers and Information Theory |publisher=[[I.R.E.]] |series=Session 19: Information Theory III - Speed and Computation |date=June 1954 |___location=Stanford Research Institute, Stanford, California, USA |pages=47–57 [49, 51–52, 57] |url=https://worldradiohistory.com/Archive-IRE/50s/IRE-1954-Part-4-Electronic-Computers-&-Information%20pdf |access-date=2020-07-03 |url-status=live |archive-url=https://web.archive.org/web/20200703180632/https://worldradiohistory.com/Archive-IRE/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information%20pdf |archive-date=2020-07-03 |quote-page=52 |quote=[…] The last column [of Table II], labeled "Best," gives the maximum fraction possible with any code—namely 0.60—half again better than any conventional code. This extremal is reached with the ten [heavily-marked vertices of the graph of [[#Kautz|Fig. 4]] for n = 4, or, in fact, with any set of ten code combinations which include all eight with an even (or all eight with an odd) number of "1's." The second and third rows of Table II list the average and peak decimal change per undetected single binary error, and have been derived using the equations of Sec. II for Δ<sub>1</sub> and δ<sub>1</sub>. The confusion index for decimals using the criterion of "decimal change," is taken to be c<sub>ij</sub> = {{!}}i − j{{!}} &nbsp; i,j = 0, 1, … 9. Again, the "Best" arrangement possible (the same for average and peak), one of which is shown in Fig. 4, is substantially better than the conventional codes. […] Fig. 4 [[#Kautz|Minimum-confusion code for decimals]]. […] δ<sub>1</sub>=2 &nbsp; Δ<sub>1</sub>=15 […]}} [https://web.archive.org/web/20200703173707/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0049.pdf] [https://web.archive.org/web/20200703175038/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0050.pdf] [https://web.archive.org/web/20200703175214/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0051.pdf] [https://web.archive.org/web/20200703175243/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0052.pdf] [https://web.archive.org/web/20200703175313/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0053.pdf] [https://web.archive.org/web/20200703175344/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0054.pdf] [https://web.archive.org/web/20200703175425/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0055.pdf] [https://web.archive.org/web/20200703175459/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0056.pdf] [https://web.archive.org/web/20200703175529/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0057.pdf] [https://web.archive.org/web/20200703175606/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0058.pdf] [https://web.archive.org/web/20200703175641/https://worldradiohistory.com/hd2/IDX-Site-Technical/Engineering-General/Archive-IRE-IDX/IDX/50s/IRE-1954-Part-4-Electronic-Computers-%26-Information-OCR-Page-0059.pdf] (11 pages) (NB. Besides the combinatorial set of 4-bit BCD "minimum-confusion codes for decimals", of which the author illustrates only one explicitly (here reproduced as [[#Kautz|code I]]) in form of a 4-bit graph, the author also shows a 16-state 4-bit "binary code for analog data" in form of a code table, which, however, is not discussed here. The [[#Kautz II|code II]] shown here is a modification of code I discussed by {{citeref|Berger|1962|Berger|style=plain}}.)</ref>
<ref name="Lippel_1955">{{cite journal |title=A Decimal Code for Analog-to-Digital Conversion |author-last=Lippel |author-first=Bernhard |journal=[[IRE Transactions on Electronic Computers]] |issn=0367-9950 |volume=EC-4 |issue=4 |date=December 1955 |doi=10.1109/TEC.1955.5219487 |pages=158–159}} (2 pages)</ref>
<ref name="Stopper_1960">{{cite journal |title=Ermittlung des Codes und der logischen Schaltung einer Zähldekade |language=de |author-first=Herbert |author-last=Stopper |editor-first=Wilhelm Tolmé |editor-last=Runge |editor-link=Wilhelm Tolmé Runge |date=March 1960 |journal=Telefunken-Zeitung (TZ) - Technisch-Wissenschaftliche Mitteilungen der Telefunken GMBH |volume=33 |issue=127 |publisher=[[Telefunken]] |publication-place=Berlin, Germany |___location=Litzelstetten, Germany |pages=13–19}} (7 pages<!-- of total pages 1–80 -->)</ref>
Line 898 ⟶ 899:
<ref name="Glixon_1957">{{cite journal |date=March 1957 |title=Can You Take Advantage of the Cyclic Binary-Decimal Code? |author-first=Harry Robert |author-last=Glixon |journal=[[Control Engineering (magazine)|Control Engineering]] |issn=0010-8049 |publisher=[[Technical Publishing Company]], a division of Dun-Donnelley Publishing Corporation, [[Dun & Bradstreet Corp.]] |volume=4 |number=3 |pages=<!-- 3, -->87–91 |url=https://books.google.com/books?id=-_5IAQAAIAAJ}}<!-- https://web.archive.org/web/20180115014809/https://donmooreswartales.com/2010/05/12/harry-glixon/ https://books.google.com/books?id=-_5IAQAAIAAJ&focus=searchwithinvolume&q=cyclic+binary+code --> (5 pages)</ref>
<ref name="White_1953">{{cite journal |title=Coded Decimal Number Systems for Digital Computers |author-first=Garland S. |author-last=White |journal=[[Proceedings of the Institute of Radio Engineers]] |publisher=[[Institute of Radio Engineers]] (IRE) |issn=0096-8390 |eissn=2162-6634 |volume=41 |number=10 |date=October 1953 |doi=10.1109/JRPROC.1953.274330 |s2cid=51674710 |pages=1450–1452}} (3 pages)</ref>
<ref name="Lucal_1959">{{cite journal |author-first=Harold M. |author-last=Lucal |title=Arithmetic Operations for Digital Computers Using a Modified Reflected Binary |journal=[[IRE Transactions on Electronic Computers]] |volume=EC-8 |number=4 |pages=449–458 |date=December 1959 |issn=0367-9950 |doi=10.1109/TEC.1959.5222057 |s2cid=206673385 |url=https://ieeexplore.ieee.org/document/5222057}} (10 pages)</ref>
<ref name="EHub_2015">{{cite web |title=Different Types of Binary Codes |at=Section 2.4 5211 Code |date=2019-05-01 |orig-date=2015-01-28 |work=Electronic Hub |url=https://www.electronicshub.org/disclaimer/ |access-date=2020-08-04 |url-status=live |archive-url=https://web.archive.org/web/20200518203953/https://www.electronicshub.org/disclaimer/ |archive-date=2020-05-18}}</ref>
<ref name="Paul_1995">{{cite web |author-first=Matthias R. |author-last=Paul |title=Unterbrechungsfreier Schleifencode |language=de |trans-title=Continuous loop code |version=1.02 |url=http://www.uni-bonn.de/~uzs180/download/mpbcd102.zip |date=1995-08-10 |orig-date=1994 |access-date=2008-02-11}}{{cbignore}} (NB. The author called this code {{lang|de|Schleifencode}} (English: "loop code"). It differs from [[Gray BCD code]] only in the encoding of state 0 to make it a cyclic [[unit-distance code]] for full-circle rotatory [[slip ring]] applications. Avoiding the all-zero code pattern allows for loop self-testing and to use the data lines for uninterrupted power distribution.)</ref>
Line 912 ⟶ 913:
<ref name="DEC_1985_VAX11">{{cite book |title=VAX-11 Architecture Handbook |publisher=[[Digital Equipment Corporation]] |date=1985}}</ref>
<ref name="ILE-RPG">{{cite web |url=http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c0925083170.htm |title=ILE RPG Reference}}</ref>
<ref name="Thelen_Van1401Van1401">[http{{cite web |url=https://edibm-thelen1401.org/1401Projectinfo/Van1401-CodeChart.pdf |title=IBM BM 1401/1440/1460/1410/7010 Character Code Chart in BCD Order]{{dead link|date=November 2016 |bot=InternetArchiveBot |fix-attempted=yes}}</ref>
<ref name="Intel_2020_V1">{{cite book |title=Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1: Basic Architecture |chapter=4.7 BCD and packed BCD integers |volume=1 |version=Version 072 |pages=3-2, 4-9–4-11 [4-10] |date=2020-05-27 |orig-date=1997 |id=253665-072US |publisher=[[Intel Corporation]] |url=https://software.intel.com/content/dam/develop/public/us/en/documents/253665-sdm-vol-1.pdf |access-date=2020-08-06 |url-status=live |archive-url=https://web.archive.org/web/20200806110842/https://software.intel.com/content/dam/develop/public/us/en/documents/253665-sdm-vol-1.pdf |archive-date=2020-08-06 |quote-page=4-10 |quote=[…] When operating on BCD integers in [[general-purpose register]]s, the BCD values can be unpacked (one BCD digit per byte) or packed (two BCD digits per byte). The value of an unpacked BCD integer is the binary value of the low [[Nibble|halfbyte]] (bits 0 through 3). The high half-byte (bits 4 through 7) can be any value during addition and subtraction, but must be zero during multiplication and division. Packed BCD integers allow two BCD digits to be contained in one byte. Here, the digit in the high half-byte is more significant than the digit in the low half-byte. […] When operating on BCD integers in [[x87]] [[floating-point unit|FPU]] data registers, BCD values are packed in an 80-bit format and referred to as decimal integers. In this format, the first 9 bytes hold 18 BCD digits, 2 digits per byte. The [[least-significant digit]] is contained in the lower half-byte of byte 0 and the [[most-significant digit]] is contained in the upper half-byte of byte 9. The most significant bit of byte 10 contains the [[sign bit]] (0 = positive and 1 = negative; bits 0 through 6 of byte 10 are [[don't-care term|don't care]] bits). Negative decimal integers are not stored in [[two's complement]] form; they are distinguished from positive decimal integers only by the sign bit. The range of decimal integers that can be encoded in this format is −10<sup>18</sup> + 1 to 10<sup>18</sup> − 1. The decimal integer format exists in memory only. When a decimal integer is loaded in an x87 FPU data register, it is automatically converted to the [[double-extended-precision floating-point format]]. All decimal integers are exactly representable in double extended-precision format. […]}} [http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html]</ref>
<ref name="Motorola_m68k">{{cite web |title=The 68000's Instruction Set |date= |url=http://www.tigernt.com/onlineDoc/68000.pdf |access-date=2023-11-21 |url-status=live |archive-url=https://web.archive.org/web/20231120233850/http://www.tigernt.com/onlineDoc/68000.pdf |archive-date=2023-11-20}} (58 pages)</ref>
Line 932 ⟶ 933:
* <!-- <ref name="Richards_1955"> -->{{cite book |author-first=Richard Kohler |author-last=Richards |title=Arithmetic Operations in Digital Computers |publisher=[[van Nostrand (publisher)|van Nostrand]] |___location=New York, USA |date=1955 |pages=397–}}<!-- </ref> -->
* {{cite book |title=Decimal Computation |author-first=Hermann |author-last=Schmid<!-- General Electric Company, Binghamton, New York, USA --> |author-link=Hermann Schmid (computer scientist) |date=1974 |edition=1 |publisher=[[John Wiley & Sons]] |___location=Binghamton, New York, USA |isbn=0-471-76180-X |url-access=registration |url=https://archive.org/details/decimalcomputati0000schm}} and {{cite book |title=Decimal Computation |author-first=Hermann |author-last=Schmid<!-- General Electric Company, Binghamton, New York, USA --> |author-link=Hermann Schmid (computer scientist) |orig-date=1974 |date=1983 |edition=1 (reprint) |publisher=Robert E. Krieger Publishing Company |___location=Malabar, Florida, USA |isbn=0-89874-318-4}} (NB. At least some batches of the Krieger reprint edition were [[misprint]]s with defective pages 115–146.)
* <!-- <ref name="Massalin_1987_Superoptimizer"> -->{{cite journal |author-first=Henry |author-last=Massalin |title=Superoptimizer: A look at the smallest program |journal=ACM SigopsSIGOPS Operating Systems Review |author-link=Henry Massalin |editor-first=Randy |editor-last=Katz |editor-link=Randy Katz |pages=122–126 |doi=10.1145/36204.36194 |date=October 1987 |volume=21 |issue=4 |isbn=0-8186-0805-6 |url=http://www.stanford.edu/class/cs343/resources/superoptimizer.pdf |access-date=2012-04-25 |url-status=live |archive-url=https://web.archive.org/web/20170704123738/https://web.stanford.edu/class/cs343/resources/superoptimizer.pdf |archive-date=2017-07-04}} (Also: ACM SIGPLAN Notices, Vol. 22 #10, IEEE Computer Society Press #87CH2440-6, October 1987)
**{{cite web |title=GNU Superoptimizer |website=HP-UX |url=http://hpux.connect.org.uk/hppd/hpux/Gnu/superopt-2.5/readme.html}}
* {{cite conference |title=VLSI designs for redundant binary-coded decimal addition |author-first1=Behrooz |author-last1=Shirazi |author-first2=David Y. Y. |author-last2=Yun |author-first3=Chang N. |author-last3=Zhang |conference=IEEE Seventh Annual International Phoenix Conference on Computers and Communications, 1988 |pages=52–56 |publisher=[[IEEE]] |date=March 1988}}