On 4/11/2011 2:31 PM, McKown, John wrote:
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Monday, April 11, 2011 3:08 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Best way to multiply doublewords?
On Mon, 4 Apr 2011 07:27:13 -0500, McKown, John wrote:
you'd need to look at the passed in save area to see if you were
supplied with one which has room for the upper half of the registers.
You can not tell by looking at the save area that was passed to you
to determine the size of the save area that was passed to you. A
program does not "determine". A program "requires". If your program
requires a 144-byte save area, your callers must provide it. If you
cannot control your callers, you have to operate on the assumption
that you have only a 72-byte save area.
The OP can simply save the high halves in his own storage if he
chooses, but he should restore the high halves before returning to his
caller.
--
Tom Marchant
OK. So, in order to be totally safe when the programmer cannot
__guarantee__ that the caller has supplied a proper save area
for 64 bit programs (i.e., the caller might or might not use
the 72 or 144 word save area format), then one __must__ assume
a 72 work standard save area, no? In which case, if called by a
routine which uses 64 bit register, you are in a quandry.
Not so much.
Assuming you don't have source to modify the caller, that is. I
guess what could be done in this case is to have two entry points.
One to be used by routines which must have their 64 bit registers
saved. The other where it does not matter.
Too complicated. If you do 64-bit things, you can assume an
old style 72 byte save area and provide your own save area
extension and just _always_ save and restore 64-bits. If your
caller only uses 32-bit regs, no harm. If your caller uses
64-bit regs, no harm.
Or, being the paranoid person that I am, one could use the BAKR
to save the register on the linkage stack, ignoring the supplied
save area in R13. Secondly, as you said, save the low fullword
of the registers in the save area. Then save the high fullwords
in an area the routine itself got (either in the program or via
a STORAGE OBTAIN). Lastly, one could save the low fullword!
of the registers in the caller's save area, then do a SYNCH to the
actual internal label where the processing occurs. Something like:
MYROUT CSECT
USING *,R11
SAVE (14,12)
LR R11,R15
SYNCH ROUTINE
RETURN (14,12),T,RC=(15)
ROUTINE DS 0H
...
GOBACK SVC 3
I guess I'd go with the program saving the high fullwords in a
STORAGE OBTAIN'ed area which is part of the "working storage".
Or, if LE, in the DSA.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
Way too complicated.
One example, reentrant, non-LE program invoked in AMODE 64,
assuming only 72 byte save area provided, we provide a 144-byte
save area and set it up standard 64-bit reg linkages:
AnyProg csect
AnyProg AMODE 64
SYSSTATE AMODE64=YES,ARCHLVL=2
LLGTR 13,13 ensure effective s.a. address is 64 bits
stm 14,12,12(13) save right hand (rh) 32-bit regs
GETMAIN R,LV=216 get 144 for calling, + 72 for lh regs
xc 0(216,1),0(1) zero out
stg 13,128(1) save pointer to caller's save area
st 1,4(13) save pointer to our save area
lgr 13,1 set our savearea address into R13
stmh 14,12,144(13) save lh of regs of caller
larl 12,Anyprog addressability
using AnyProg,12 "
.
.
.
lmh 14,12,144(13) restore lh of regs
lg 13,(128)13 pointer to caller's save area
lm 14,12,12(13) restore rh of regs
l 1,4(13) restore pointer to getmained area
FREEMAIN R,LV=216,A=(1)
sr 15,15 set return code
bsm 0,14 return in AMODE of caller
So this code provides a 144-byte save area for any routines
it calls, and uses an additional 72 bytes to save the high
order register values of the routines that call it. Remember
that save areas must be below the bar so that the address
of the save area will fit into 31-bits. Similarly, any parm
list must reside below the bar, so the address will fit into
31-bits.
<ad>
In our four day course "z/OS Assembler Programming
Part 4: z/Architecture and z/OS" we discuss many alternatives
for save areas and running in AMODE 64, and we even have hands
on labs for doing this. It can be confusing, but it is not
rocket science. See
http://www.trainersfriend.com/Assembler_%20courses/C500descrpt.htm
and follow the link to the course outline if you want a
little more detail.
We also discuss 64-bit saveara logic, and lots more.
</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
