> 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. 
> 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. 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!

I have stayed out of this and bit my tongue so far, but here goes nothing. An 
"interface" is a contract between the caller and the callee. The caller has to 
meet that interface specification or there can be no expectation that the 
called function will operate correctly. So if *YOU* are the one who is writing 
the new function, *YOU* get to define its interface and your callers have to 
provide you with whatever you specify. So if you want to use the full 64 bit 
register set, you need to specify an appropriate 64 bit save area format. When 
you get control you save and restore your caller's registers (2-14 anyway) 
using the save area format you asked for. 
The one thing you can say for sure when a PSW shows up in your code out of the 
ozone, is that there is *NO* way to disambiguate all of the possible calling 
methods. If you caller screws up and doesn't meet the interface standard, 
that's on him, not you. However, if you're trying to be more general and cover 
all of the possible bases, then the more elegant (and reliable) way of doing it 
is to provide those callers with different interface names and put appropriate 
"glue" logic in those interfaces to line up the assumptions of the caller and 
the callee. 
CC                                        

Reply via email to