On 4/4/2011 6:01 AM, Joe Owens wrote:
Thanks for the replies, much appreciated.
We do have current processors, just my knowledge that is out of date :)
The factor might not be a whole number, which is why I thought of FP, but
I can see I can follow the multiply by a 64 bit divide by 100 to get a
percentage.
I take it the 'G' instructions can be executed in 31 bit, due to their
explicit naming (and no-one mentioned amode)?
One question occurs - must I now use extended save areas, as I am doing
something to the top halves of the GPRs, or will the system take care of
that for me? (There are no amode 64 progs on the calling chain).
Thanks, Joe
You do not need to run AMODE64 to use 64-bit arithmetic.
And, yes, you should use save area chaining that will
preserve all the bits in your registers.
Since, I think, z/OS 1.3, the operating system has supplied
a 144 byte save area on entry, although most programmers
have had no need to change their coding assuming 72-byte
save areas. If you care about the high order words of
registers after calling subroutines, you could provide
your own extended save area - but, of course, you have no
guarantee the subroutine will use it. So if you need to
preserve 64-bit values across calls, you might need to
save-before-call and restore-after-call yourself.
<ad>
Our 4-day course, "z/OS Assembler Programming Part 4: z/Architecture and z/OS",
covers all the new hardware instructions introduce by the
z Series machines as well as software related issues such
as save areas and concerns about running in amode 64. See:
http://www.trainersfriend.com/Assembler_%20courses/C500descrpt.htm
for details.
</ad>
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
