> I know of people using SR RF,RF - but I never saw SLR RF,RF up until now
This issue has been beat to death here but on recent processors SR, SLR and XR to clear a register are all equally fast. Use whichever one you find most aesthetic. At one time LHI r,0 was generally faster because SR/SLR/XR r,r tied up a fixed point arithmetic unit (albeit LHI uses 2 additional bytes of i-cache). Modern processors all recognize SR/SLR/XR r,r and treat it as a non-arithmetic "slam a zero into r." LHI may still have a slight advantage in some situations because it does not set the condition code, possibly making things easier on the branch prediction logic. That aspect is also advantageous for compilers which now do things like a compare, followed by a bunch of unrelated instructions, followed by a branch on the results of the compare -- to take advantage of pipelining. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Thursday, May 11, 2017 3:24 PM To: [email protected] Subject: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP Am 12.05.2017 um 00:08 schrieb John McKown: > On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer > <[email protected]> > wrote: > >> Yes, of course. I detected the error when I looked at my piece of >> software from last year which examined the different LE heaps. >> >> and: thank you, Allan Kielstra, for the clarification regarding Reg >> 12; so my call to the ASSEMBLER function to get the address of the >> CEECAA will work? >> >> Here is the ASSEMBLER program which returns the registers (especially >> reg >> 12) >> to the C program: >> >> MDV9970 CSECT >> MDV9970 AMODE 31 >> MDV9970 RMODE ANY >> * >> *************************************************************** >> * UNTERPROGRAMM ZUR ERMITTLUNG DER >> * AKTUELLEN REGISTERSTAENDE UND ABLAGE >> * IN EINEN C-BUFFER (DER ALS PARAMETER >> * UEBERGEBEN WIRD). ZWECK DER UEBUNG: >> * ZUGRIFF AUF CEECAA (COMMON ANCHOR AREA VOM LE) >> * UND DAMIT AUF ANYHEAP UND BELOWHEAP >> * BERND OPPOLZER / AUGUST 2016 >> *************************************************************** >> * >> R0 EQU 0 >> R1 EQU 1 >> R2 EQU 2 >> R3 EQU 3 >> R4 EQU 4 >> R5 EQU 5 >> R6 EQU 6 >> R7 EQU 7 >> R8 EQU 8 >> R9 EQU 9 >> RA EQU 10 >> RB EQU 11 >> RC EQU 12 >> RD EQU 13 >> RE EQU 14 >> RF EQU 15 >> * >> STM RE,RC,12(RD) REGISTER SICHERN >> USING MDV9970,RF ADRESSIERUNG HERSTELLEN >> L R3,0(R1) ADRESSE VOM BUFFER = 1. PARAMETER >> MVC 0(52,R3),20(RD) REGISTER 0 BIS 12 AUS SA UEBERTR. >> ST RD,52(R3) REGISTER 13 ABSPEICHERN >> MVC 56(8,R3),12(RD) REGISTER 14 UND 15 AUS SA UEBERTR. >> LM RE,RC,12(RD) REGISTER ZURUECKLADEN >> BR RE UND RUECKSPRUNG >> * >> END MDV9970 >> > Looks fairly good to me. For returning the 32 bit registers, that is. > But it seems to be "overkill" to me. The "guts" of the routine could be just: > > STM R0,RF,12(RD) SAVE ALL REGS. > L R3,0(,R1) POINT TO RETURN AREA > MVC 0(64,R3),12(RD) MOVE REGS AT ENTRY > SLR RF,RF > BR RE > > This does not use standard linkage, but is that really necessary? The > only possible abend would be on the MVC, if the routine is not called > properly. > I included the SLR just to "zero" the return code. If the C code is > declared as returning "void" (e.g. "void MDV9970(regs) ;" where regs > is defined as "uint regs[16];" ) then R15 on exit is ignored. > > But you should add a LM instruction to restore the registers, for example R3. The original program is called inside a C function, and I thought that the registers should be restored on exit in a (sort of) standard way. This is expected by the surrounding C routine, IMO. What I find most interesting: if I set RF (or any other register) to zero, I always would code XR RF,RF you use SLR RF,RF it's a matter of style, or maybe what you learned first. I know of people using SR RF,RF - but I never saw SLR RF,RF up until now. Nice :-) There was once a discussion that you can tell the author of a piece of software from such style attributes ... not only with ASSEMBLER, but with other languages (even C etc.), too. With other languages, it's maybe more the style of writing, layout etc. Kind regards Bernd ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
