2008/10/9 Bernd Oppolzer <[EMAIL PROTECTED]>: > A variable which is listed in the storage offset listing as 0(r13) > actually never is held in storage, but it resides in a register all the time. > 0(r13) simply means that no storage is allocated for this variable (this > is not very nice, I asked the compiler people several times to fix this. > Some compiler versions simply give no offset at all in these cases, only > a line with the variable name and a comma instead of an offset.) > > A variable without allocated storage must be a simple local variable > which fits into a register (that is, a pointer, long, int, double etc.). > This is never the case for parameters (they are addressed with r1 and > never transferred by registers, always storage), or parts of a struct, > or variables which need to be addressed by pointer. And, of course, > not for char arrays, decimal values and so on, because they must reside > in storage.
With FASTLINK and XPLINK, some arguments are normally passed directly in GPRs 1-3, and/or FPRs 0-6, and R1 does not point to the argument list. > The only way to determine the actual register number is to look at the > assembly code around the error place. If you have something like > > x = 0; > > *** la r6,0 > > you know, for example, that r6 is used to hold the value of x. Keep in mind that this is not necessarily a fixed assignment, i.e. R6 may hold some other variable at some other point in the code, and some other register may hold the value of x. If you are in a position to reproduce the problem easily, it can make debugging at this low level easier if you compile with all optimizations turned off. And sometimes that even makes the problem go away... :-( Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
