One simply turns off optimization during all but final testing. Saves compile time too.
Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Keith Moe Sent: Monday, January 29, 2018 4:09 PM To: [email protected] Subject: Re: Fair comparison C vs HLASM One of the downsides to such great optimization is the added difficulty in debugging. Programs will often have code that leaves footprints and saves various values in work areas for diagnostic reasons. Many optimization algorithms will detect that these area are "never referenced" after being set and eliminate the code that sets or stores these values. Another optimization that makes debugging difficult is the inlining of subroutines that are only called in one place to save the overhead of the linkage. But the generated mapping of the source to the generated machine code/assembler does not match the original source statements to the generated machine code. Sure, there are various tricks that can be done to prevent such optimization, but that partially defeats the value of using a high level language when you have to think about how to defeat it. When you spend a lot of time debugging problems occurring in customer production environments, life can be difficult. Optimization is great until it isn't!
