Post by thread:[PIC]: BCD question

Hello Vasile, Thursday, April 19, 2001, 3:19:00 PM, you wrote: VS> Could someone explain briefly what are diferences between unpacked and VS> packed BCD ? In packet format it need one byte (nibble + nibble) to store a BCD number. And in unpacket format it need two bytes (byte + byte) to store a BCD number. I hope You understood my English :). -- Best regards, Alexey Musin -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Yes I understood. Spasiva Alexei ! Vasile On Thu, 19 Apr 2001, Alexey Musin wrote: {Quote hidden}> Hello Vasile, > > Thursday, April 19, 2001, 3:19:00 PM, you wrote: > > VS> Could someone explain briefly what are diferences between unpacked and > VS> packed BCD ? > > In packet format it need one byte (nibble + nibble) to store a BCD > number. > And in unpacket format it need two bytes (byte + byte) to store a BCD > number. > > I hope You understood my English :). > > -- > Best regards, > Alexey Musin > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi, >Could someone explain briefly what are diferences between unpacked and >packed BCD ? >Thank's, Vasile Let's say that you want to represent 3495 (decimal) In packed format it will be: 0x34 0x95 (in C notation, hex, 2 bytes) In non-packed format: 0x03 0x04 0x09 0x05 (hex, four bytes) Regards Les -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

VS> Could someone explain briefly what are diferences between unpacked and VS> packed BCD ? >In packet format it need one byte (nibble + nibble) to store a BCD >number. >And in unpacket format it need two bytes (byte + byte) to store a BCD >number. I would class this as "nearly correct". In unpacked BCD only the bottom nybble represents a digit. The top nibble can be anything, and is most commonly the ASCII high nibble of the number. Any arithmetic done on the nibble needs to be careful to not change the upper nibble for this reason. In packed BCD then two adjacent digits (e.g. from an ASCII string) will be packed into one byte. When this is done it is necessary to be careful to treat each byte properly when doing arithmetic as you cannot treat the number as one 8 bit binary number. You have to detect the overflow from 9 to A in the lower significant digit, and change it to 0 and increment the upper significant digit. The order of packing will depend on the processor as well, you cannot assume that the upper byte is the more significant digit. When dealing with the packing and unpacking the swap nibble instruction is very useful. Note that it is known as BCD because the nibble representing the number is constrained to the values 0-9, so any arithmetic that causes it to go outside this range needs logic to deal with the resetting to 0 or 9 and dealing with the adjacent digits correctly, which is extra logic compared to ordinary binary arithmetic routines unless the processor has instructions that deal with this for you. This is the reason that there is a "half carry" flag that shows the state of the carry between bit 3 and bit 4 on arithmetic operations (see the PIC flags definitions, it is there). -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi Alan. What about case when you have number in range from 0 upto 99 (decimal) stored in one byte? For instance in add/sub operations if number is rolled over 100. or borrow is generated than number is normalized again back to range 0...99 and carry/borrow operation is applied to next byte. Is it some particular case of BCD arithmetic or something else? WBR Dmitry. "Alan B. Pearce" wrote: > > Note that it is known as BCD because the nibble representing the number is > constrained to the values 0-9, so any arithmetic that causes it to go > outside this range needs logic to deal with the resetting to 0 or 9 and > dealing with the adjacent digits correctly, which is extra logic compared to > ordinary binary arithmetic routines unless the processor has instructions > that deal with this for you. This is the reason that there is a "half carry" > flag that shows the state of the carry between bit 3 and bit 4 on arithmetic > operations (see the PIC flags definitions, it is there). -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dmitry, You must perform a "decimal accumulator adjust" function after an add or subtract of two packed BCD numbers. Most CPUs have a form of this function in an instruction called "DAA". Note that the 17Cxxx and 18Cxxx parts have this instruction; on this processors it's called "DAW" for decimal adjust WREG Register. The operation of DAW (or DAA) is as follows: If (WREG<3:0> > 9) or (DC =1) then WREG<3:0> + 6 --> WREG<3:0> else WREG<3:0> --> WREG<3:0> If (WREG<7:4> > 9) or (C = 1) then WREG<7:4> + 6 --> WREG<7:4> else WREG<7:4> --> WREG<7:4> DAW performs the fix-ups so that the result of the computation remains in packer BCD format. Douglas Wood Software Engineer spam_OUTdbwoodTakeThisOuTkc.rr.com Home of the EPICIS Development System for the PIC and SX http://epicis.piclist.com {Original Message removed}

It is worth to mention the IBM mainframe architecture has also a sign nibble: the rightmost nibble contained (AFAIK) B, C, or D (hex) if negative, and A or E if positive. Any other values were illegal, similarly, if any of other nibbles contained a higher value than 0. Those illegalities led to the famous "Data Exception" 0C7. They (IBMs) have a decimal arithmetics such as AP, MP, DP, SP, ZAP, SPR, CP. Regards, Imre On Thu, 19 Apr 2001, Laszlo Kohegyi wrote: {Quote hidden}> Hi, > > >Could someone explain briefly what are diferences between unpacked and > >packed BCD ? > >Thank's, Vasile > > Let's say that you want to represent 3495 (decimal) > > In packed format it will be: 0x34 0x95 (in C notation, hex, 2 bytes) > > In non-packed format: 0x03 0x04 0x09 0x05 (hex, four bytes) > > > > Regards > > Les > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

Hi Douglas. Very informative answer but I've been asking about something else. WBR Dmitry. Wood wrote: > > Dmitry, > > You must perform a "decimal accumulator adjust" function after an add or > subtract of two packed BCD numbers. Most CPUs have a form of this function > in an instruction called "DAA". Note that the 17Cxxx and 18Cxxx parts have > this instruction; on this processors it's called "DAW" for decimal adjust > WREG Register. > > {Original Message removed}

>What about case when you have number in range from 0 upto 99 (decimal) >stored >in one byte? For instance in add/sub operations if number is rolled over >100. >or borrow is generated than number is normalized again back to range >0...99 >and carry/borrow operation is applied to next byte. >Is it some particular case of BCD arithmetic or something else? Well just like any variable you have to assign enough bytes to handle the largest value. There is nothing to stop you having a 10 digit number as 5 bytes of packed BCD. Your routine just needs to be able to carry over to the next digit in the next byte just as any binary routine would do when doing multibyte arithmetic. The basic arithmetic carry logic does not change. I used to do technical support and board repair to chip level for a machine that had a 16 byte accumulator in memory, and the CPU microcode did BCD arithmetic on this accumulator as unpacked BCD. When storing data to a file it was possible to save it as packed BCD to save file space. Is anyone still using a QANTEL machine out there? -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

Dmitry Kiryashov wrote: > > Hi Alan. > > What about case when you have number in range from 0 upto 99 (decimal) > stored > in one byte? For instance in add/sub operations if number is rolled over > 100. > or borrow is generated than number is normalized again back to range > 0...99 > and carry/borrow operation is applied to next byte. > > Is it some particular case of BCD arithmetic or something else? Dmitry, it's easier to understand like this: * BCD is a 4-bit format (from 0-9 decimal) the format is not related to bytes at all. * it's easiest to just put ONE digit in a byte, this makes math much easier between variables, this is called "un-packed". Yes it wastes 4 bits. Variables are easy to add, subtract, display etc. * if memory is limited you can put TWO digits in a byte. Each digit is separate and has 4 bits. This is called "packed". This is much harder to do math with and is best to avoid packed format unless you have a reason to use it. :o) -Roman -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

On Fri, 20 Apr 2001, Roman Black wrote: > Dmitry Kiryashov wrote: > > > > Hi Alan. > > > > What about case when you have number in range from 0 upto 99 (decimal) > > stored > > in one byte? For instance in add/sub operations if number is rolled over > > 100. > > or borrow is generated than number is normalized again back to range > > 0...99 > > and carry/borrow operation is applied to next byte. > > > > Is it some particular case of BCD arithmetic or something else? > > > Dmitry, it's easier to understand like this: <snip> Actually, Dmitry understands an explanation in code better: www.piclist.com/techref/microchip/math/add/bcdp2.htm http://www.piclist.com/techref/microchip/math/sub/bcdp2.htm These routines are packed bcd add and subtract. They support carry propogation. Scott -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

Dmitry Kiryashov <@spam@nzewsKILLspamMAIL.RU> wrote: > What about case when you have number in range from 0 upto 99 (decimal) > stored > in one byte? For instance in add/sub operations if number is rolled over > 100. > or borrow is generated than number is normalized again back to range > 0...99 > and carry/borrow operation is applied to next byte. > > Is it some particular case of BCD arithmetic or something else? Texas Instruments called that "Rad100" (radix 100) in their processors that supported it directly. I find it very convenient to use: it's easier to convert to decimal than plain binary numbers, and easier to calculate with than BCD (if your processor doesn't directly support BCD). Another advantage over BCD is that you have one completely unused bit per byte, which can be used to indicate a decimal point, or the end of a variable-length number. Jason Harper -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

>Another advantage over BCD is that you have one completely >unused bit per byte, which can be used to indicate a decimal >point, or the end of a variable-length number. Well only if you restrict yourself to 127 char ASCII. If you are using packed BCD then all bits are used. :) -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Hi Roman. I do understand what packed and unpacked BCD's are ;) The question was related to some particular unclassified yet (for me at least ;) case for numbers in range of 0..99. that is represented in pure binary form and is taken 7 bits to be stored and carry/borrow operation is propagated to next such a "number". Looks more like packed 100's number actually ;) WBR Dmitry. Black wrote: > Dmitry, it's easier to understand like this: > > * BCD is a 4-bit format (from 0-9 decimal) > the format is not related to bytes at all. -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Perfect! ;) Thank you Jason. I found it very useful as well for the same reasons you have listed. WBR Dmitry. > Texas Instruments called that "Rad100" (radix 100) in their processors that > supported it directly. I find it very convenient to use: it's easier to > convert to decimal than plain binary numbers, and easier to calculate with > than BCD (if your processor doesn't directly support BCD). Another > advantage over BCD is that you have one completely unused bit per byte, > which can be used to indicate a decimal point, or the end of a > variable-length number. > Jason Harper -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

Hi Alan. Brief track into it. You have a byte with lowest 7 bits occupied and MSB bit that is "free". In lowest 7 bits number in range of 0..99. (decimal) is stored. Carry(above 99.)/borrow(below 0) is propagated to next "number" and then current number is normalized back to range 0..99. MSB is always free and can be used for whatever you want. It is not BCD actually, Jason said right name for it. It is Rad100. WBR Dmitry. "Alan B. Pearce" wrote: > > >Another advantage over BCD is that you have one completely > >unused bit per byte, which can be used to indicate a decimal > >point, or the end of a variable-length number. > > Well only if you restrict yourself to 127 char ASCII. If you are using > packed BCD then all bits are used. :) -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

>You have a byte with lowest 7 bits occupied and MSB bit that is "free". >In lowest 7 bits number in range of 0..99. (decimal) is stored. >Carry(above 99.)/borrow(below 0) is propagated to next "number" >and then current number is normalized back to range 0..99. >MSB is always free and can be used for whatever you want. I take it from this and some other emails that you are talking of 7 bit binary, which is NOT BCD. BCD uses the numbers 0-9 only in 4 bits, where a 7 bit binary is 0-127, and then you are crunching it separately to 0-99. I think you are really confusing a thread which is talking about BCD. I only realised that you were talking about 7 bit binary (what someone else called rad100) after reading this block of messages from you, of which |I have quoted from the one you specifically addressed to me. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads