> reentrant code tends to run faster than non-reentrant code Could you elaborate on that? I understand that there is a savings if reentrant code can be reused without reloading (such as if it is resident in the LPA) but why would reentrant code be inherently faster than non-reentrant? There is certainly an additional overhead for GETMAIN, storage initialization, often an extra level of indirection, etc. Reentrant design often burns one more register, which may in turn lead to additional register save and restore operations. Reentrant code is typically more scattered in its storage references, which increases paging overhead (at least in theory).
It's an academic question, I admit. 99% of all assembler code is so fast it does not matter, and the 1% that matters can always be optimized despite any considerations for reentrance. I'm just curious about your assertion. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 7:55 AM To: [email protected] Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? <snip> A discussion of the reasons why reentrant code tends to run faster than non-reentrant code would take longer and be a far more advanced than simply teaching new programmers to always acquire working storage. In a lab setting on a test machine running z/OS, I would also enable the CsvRentSp252 DIAG trap to ensure that reentrant programs loaded from _unauthorized_ libraries reside in subpool 252. Abend0C4 can be an extremely useful debugging aid! ;-) <snip> ---------------------------------------------------------------------- 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
