Page 1 of 1
Code snippet to add two numbers
Posted:
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
Posted:
Thu Mar 10, 2011 3:23 pm
by NicC
Because SUM is character not packed
Re: need help
Posted:
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
Posted:
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
Posted:
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
Posted:
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
Posted:
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.