Page 1 of 1

Code snippet to add two numbers

PostPosted: Thu Mar 10, 2011 2:10 pm
by syamcs
hi all,
recently i have started learning assembly language and struck with a small doubt below i have the code snippet to add two numbers


                      AP NO1,NO2
                      AP NO3,NO1
                      UNPK ZDV,NO3
                      OI ZDV+7,X'F0'
                      MVC SUM(L'ZDV),ZDV


i understood the the very first two lines the third,fourth and fifth line i can't understand why we have to unpack it and do the rest all operations
the data section for the above code snippet is as follows
                           NO1      DC P'100'
                           NO2      DC P'200'
                           NO3      DC P'300'
                           NO4      DS PL8
                           SUM      DS CL80
                           ZDV      DS ZL8

Regards
Syam

Re: need help

PostPosted: Thu Mar 10, 2011 3:23 pm
by NicC
Because SUM is character not packed

Re: need help

PostPosted: Thu Mar 10, 2011 3:39 pm
by Robert Sample
What is the internal representation of a packed number compared to SUM? Is that internal representation made up of printable (that is, values in the range C1-C9, D1-D9, E2-E9, F0-F9 for uppercase) characters?

Re: need help

PostPosted: Thu Mar 10, 2011 3:40 pm
by BillyBoyo
"Characters", "Display", "Zoned-Decimal" is stuff that we humans can read on a display (with no HEX capabilities) or on a printed line.

However, the CPU can't directly do calculations with such things. All CPUs like binary for calculations. 360/370 (and I have no idea at all what other architectures) also support calculations and manipulations of "packed-decimal" values. If you are adding up a list of order values that start off as "display", then you will convert them to packed decimal, do the addition, and convert the result back to display at some point for a user to see. On IBM, you don't have to convert to binary, unless you are naturally using binary.

Your SUM is an 80 character field. Could be a punch card, an old console-type printer, an 80x40 display or whatever, but for anyone to be able to see what the sum is, you have to unpack the calculated total. To do the calculation, all the components have to be in "packed" format.

The OR with "F0" stuff is to make sure that any sign is not carried forward from the calculation (Cx or Dx). Because the result of just allowing the display of the positive or negative in the low-order byte is that the low-order byte can no longer be read by humans when displayed/printed.

All this stuff is what you will be doing lots of if you are using Assembler for "application programming" tasks. Hopefully you'll get lucky, and you can get a higher-level language to do all that work for you, but it is useful to know what Cobol, for instance, is going through when you do an ADD or COMPUTE or whatever. Generate the Assembler code on your Cobol listing and you'll see the same sort of stuff as this example.

Re: need help

PostPosted: Thu Mar 10, 2011 3:51 pm
by syamcs
thanks a lot to all who have spend their valuable time for this problem.... :)

Re: need help

PostPosted: Thu Mar 10, 2011 7:22 pm
by Zio69
BillyBoyo wrote:360/370 (and I have no idea at all what other architectures) also support calculations and manipulations of "packed-decimal" values.

I'm pretty sure x86/X64 and ARM can deal with BCD (Binary Coded Decimal), which is a packed number without the sign. z/os defines them "unsigned packed decimals" but offers limited support for them. AFAIK that's the only thing that resembles packed decimals outside mainframes

Re: need help

PostPosted: Thu Mar 10, 2011 10:55 pm
by steve-myers
In the 1960s, S/360 packed decimal was considered a big deal. For larger values, packed decimal provided a nearly 50% reduction in storage use compared to keeping the data as "zoned" decimal, when main storage was very expensive (roughly $1/byte), and external storage was both expensive and slow. Not only that, you did not have to translated packed decimal data to and from binary; instructions like CVD (Convert binary to packed decimal) and CVB (Convert packed decimal to binary) were very slow. Packed decimal arithmetic instructions were not all that fast, but they were much faster than a couple of CVB instructions, a binary arithmetic instruction, and a CVD instruction, which was often the real requirement for dealing with most commercial data.