Re: Curious compiler optimization
Jonathan Scott described a plausible way that the generated code could make sense. This I can believe. Thanks. FTR, by "deliberately" and "on purpose" I meant that the code wasn't accidentally generated, and that since it's a pretty basic statement, I was assuming that it's boilerplate for "define a variable with initial value x". I.e., someone chose to have it emit that code, as opposed to optimized code which could (and often is) very complex and occasionally (though hopefully not so much these days) outright wrong. (cf. the FORTHX example I mentioned) Thanks to all who responded. ...phsiii
Re: z/Architecture Principles of Operation pdf
I somewhat agree that z/Architecture is not "a feature of z/OS", however, access to Principles of Operation is mandatory in order to to write (or even study) assembler code. Numerous other z/OS pubs make many references to Principles of Operation. For example, the statements shown below extracted from page 65 within "z/OS Version 2 Release 4 MVS Programming: Extended Addressability Guide" (SA23-1394-40): "The purpose of this section is to help you use the 64-bit GPR and the 64-bit instructions as you want to save registers, perform arithmetic operations, access data. It is not a tutorial about how to use the new instruction set. Principles of Operation is the definitive reference book for these instructions." It appears that IBM is a bit inconsistent about how to obtain the z/Architecture Principles of Operation. I thought I would take peek at the z/VM library at: https://www.vm.ibm.com/library/index.html Down on the left hand side of the page is an item labeled "z/VM Related PDFs" which gets you to: https://www.vm.ibm.com/library/other.html If you type "Principles" in the "Filter" box on the resultant page you'll see the download links for SA22-7832-12 (z/Architecture Principles of Operation) and SA22-7201-08 (Enterprise Systems Architecture/390 Principles of Operation). The links work and no IBM user ID is required. Also, on the z/VM Indexed PDF page (https://www.vm.ibm.com/library/pdfzip.html) there is this statement: "Note: Starting with the 2019 April Refresh Collection the z/VM Related PDFs will no longer be included. Please see earlier collections or see the Related PDFs page." Hopefully the "Related PDFs page" will continue to be available. To the IBMers: Any chance on having a similar Related PDFs link on the z/OS home page? Bob
Re: Curious compiler optimization
>* int var = 0; > > LA r4,0 > LR r0,r4 > ST r0,var(,r13,160) My guess is that this code is doing the following: 1. A constant of zero will be needed. Assign this to a register without changing the cond code. It might be needed again in the near future. 2. Assign the variable var temporarily to r0, in case we need it again soon, and set it to zero. 3. Store the variable var in its storage field for later, as it has just been updated and we may need to reuse the temporary register. This obviously leaves huge scope for optimisation. Jonathan Scott, HLASM IBM Hursley, UK
Re: Curious compiler optimization
On 2021-11-16 10:44 AM, John wrote: ...deliberately...on purpose. I can understand that you are disappointed with the code that is generated when you don't request optimization, but I absolutely don't get your assertion that the compiler would generate poor code on purpose. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Curious compiler optimization
Nobody has mentioned an interactive debugger, which might be why the compiler creates code like this. Joe Goovoo may not have a clue about the assembly code the compiler generates, but he wants to modify variables at a breakpoint and the code must use the changed value when he types "go". Optimized code is hard to debug if you don't know assembler and have the listing. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Saturday, November 13, 2021 11:10 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Curious compiler optimization Unoptimised code typically has redundant instructions. For example, a store instruction to finish an assignment operation might be followed by a load from the same place in a following statement. That I could believe--the unoptimized code is dealing with the statements as discrete code snippets. But this was code generated for a single, simple statement. Is this bad? You would not notice the time to execute the redundant LR instruction. If that statement were true, there would be no need for optimization. This is code that will run billions of times, often millions in a single run; yes, we will feel it. Again, my point (well, one of them) was that this is really pretty grim code: I'd downmark a student who produced it. If you want better code, specify optimisation. Corollary: the compiler generates...deliberately poor code without optimization? Again, why? Note that I had the same ARCH() value on both versions. So why wouldn't the original code use the same fancy new instruction? I would have assumed that optimization meant considering how statements interact, not generating lousy code for each on purpose. But I am not a compiler creator by any stretch of the imagination. Maybe I'm missing some design principle here, which is why I asked in the first place...
