APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

© Tony Lawrence, aplawrence.com

Understanding Packed BCD

See also Understanding Floating Point

Packed BCD (Binary Coded Decimal) is a numeric format that was directly supported on cpu's almost from the beginning, and still is today. Simply put, it relies on the fact that 4 bits are more than sufficient to represent decimal numbers. Therefore, two decimal numbers can be held in each byte, a 32 bit register can hold 8 such numbers, and a 64 bit register can of course hold 16. Many cpu's can do BCD math - it's just a matter of having the half bytes carry when their value exceeds 9, conceptually not a lot different than ordinary binary math. It also isn't very hard to write programs to do math on BCD numbers of arbitrary length.

There is also unpacked BCD, which of course is very wasteful of space: 1 byte per numeric digit stored.

If you look at hex representations of BCD numbers, the individual digits are simply read left to right: what you see is what you have (ignoring sign and any exponent). BCD formats are directly human readable without any more math than translating the bit values to numbers.

The advantage of BCD over floating point formats is that numbers can be accurately represented (assuming you have enough bytes to store the number). Floating point is a compromise: some numbers (6.25) can be represented accurately, but most can only be approximated. The approximation is very close with double precision formats, but it is still an approximation.

The disadvantage is range. In 32 bits, IEEE floating point can store numbers in the range of 2^-126 to 2^127 - very large numbers. In the same 32 bits, even if you ignore the need to store a sign, the largest possible number in packed BCD would be 99999999. That's less than 2^27 right there, which is a long, long way from IEEE floating point range. As you also need the sign and an exponent to locate the decimal point, packed BCD obviously needs much more storage space to handle typical numbers. However, people have used this: MBASIC on Tandy Xenix used packed BCD for floating point, and many an accounting package used BCD internally to avoid rounding errors.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Understanding Packed BCD


More Articles by

Find me on Google+

Tony Lawrence

Click here to add your comments
- no registration needed!

Back in the days when I wrote a lot of 65xx machine code, I grappled with trying to produce accurate mathematical results. Neither excess 128 or IEEE floating point produced the desired results, so I turned to compressed (packed) BCD. I decided to use a 64 bit BCD number in big endian notation (opposite of the 65xx little endian word ordering, but easier to work with), which would produce more than sufficient range for the financial applications I was writing.

As Tony noted above, the number's precision and sign have to be accounted for somewhere. Accordingly, I employed the following scheme (I don't claim to have invented it, but I never saw it described in any of the literature I knew of at the time):

In this structure, 'H' and 'h' refer to bits 4-7, the high nybble of each byte, and 'L' and 'l', the low nybble.

The 'A' nybble of byte 'AL' is the key to decoding the rest of the number. Bits within the 'AL' byte are defined as follows:

Bit Meaning
7 Sign: 0 = +, 1 = minus
4-6 Number of places to right of decimal point
0-3 Most significant BCD digit, range of 0-9

Bits 4-7 are the 'A' nybble, with bits 4-6 interpreted as a binary integer. Since the maximum value that can be represented with 3 bits is 7 (2^0 + 2^1 + 2^2), the maximum fractional precision possible is .0000001. For monetary usage, a bit pattern such as:


would be appropriate, indicating two place decimal precision ('x' represents the sign bit). The maximum possible range would be:

+/- 9,999,999,999,999.99

which is more than adequate to describe Bill Gates' net worth. &lt;Smile&gt;

An 'A' nybble pattern like this:


indicates that the number is negative; again, bits 4-6 ('xxx') describe the decimal precision.

To extract the sign and precision from the 'AL' byte, masking and arithmetic shifting were required. Assuming byte 'AL' was already loaded into the .A register, the required 65xx/85xx assembly language statements (using MOS Technology syntax) would be as follows:

PHA ;push .A onto stack...
PHA ;twice
AND #%10000000 ;mask out all but sign bit
STA SIGN ;store sign somewhere in memory
PLA ;recover original value from stack
AND #%01111111 ;mask out the sign bit
LSR A ;bits 4-6 become bits 3-5...
LSR A ;3-5 become 2-4...
LSR A ;2-4 become 1-3 &amp; finally...
LSR A ;1-3 become 0-2, the precision value
STA PRC ;store precision somewhere in memory
PLA ;again, recover original value from stack
AND #%00001111 ;mask hi nybble, leaving most siginificant BCD digit
... program continues

Bytes 'HL' and 'hl' define normal compressed BCD digits, with 'hl' being the least significant. Therefore, the compressed BCD number

09 99 99 99 99 99 99 99

decodes into the ASCII equivalent:



9 * 10^14
a range sufficient for most applications. The negative equivalent would be:

89 99 99 99 99 99 99 99
which would be:


in ASCII. The other extreme would be:

F9 99 99 99 99 99 99 99

which would be:

a number that sometimes seems to represent my business's cash flow.


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar
Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

This post tagged: