Re: Curious compiler optimization
On 2021-11-13 01:04, Peter Relson wrote: When it needs zero, it merely copies it into anther register that it has allocated? Yes, but why not just store the register that they know already contains zero? Because they do not necessarily "know" that when the code is generated. It might well be that the removal of the extra instructions and the "knowledge" itself is an optimization, and the OP asked for no optimization. So this is not a curious "optimization". It is a natural non-optimization. Unless the OP's curiosity was about use of MVHI which, as was pointed out, is fully correct. I'd think that if you want decent code, you don't ask for no optimization. If you do ask for no optimization, you get what you get. Maybe that helps you learn how these compilers generate code. For example, the "initial" pass of the code-gen for z system does not necessarily assume knowledge of there being only 16 GRs available. Regarding "ST r0,var(,r13,160)" I have no idea, but this is not assembler, it is pseudo-assembler. Not having seen more examples, I'm guessing that it's giving you the standard assembler version "ST r0,var" with the index, base, and displacement corresponding to "var" in parentheses. If they don't document otherwise, it can be as "pseudo" as they choose. Maybe the leading comma is to indicate that there is no index register. That's how you'd code it in assembler (of course you'd have the "160" where "var" is). Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
On 2021-11-13 02:32, Phil Smith III wrote: Thanks to all for the replies. I had clearly forgotten what MVHI did (OK, I probably never knew-too many new instructions!). As I said, it's not a problem, but I'm a bit bothered by your comment, Peter: So this is not a curious "optimization". It is a natural non-optimization. Seems like the unoptimized code is oddly crude. 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. I suppose compiler authors must fight the urge to do some basic optimization, but why would it ever be this bad? Is this bad? You would not notice the time to execute the redundant LR instruction. If you want better code, specify optimisation. I do like the pseudo-assembler, putting as much info as possible in. It just threw me since I was first wondering "Is there some new assembler syntax I've missed??"
Re: Base-less macros
This draft document, entitled Register Constraint Relief 2021, coincidentally addresses the subject of Base-less/Base-free Macros. See references to Base Address Register (BAR) 15 and relative addressing for all base/displacement operands.. https://docs.google.com/document/d/19O8Z-H3XcgiDWOI_zO4NM8JnRHllGn91sFTDtgQ39bc/edit?usp=sharing OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Wed, Nov 10, 2021 at 3:02 AM Jonathan Scott wrote: > The documentation update for APAR PH34824, for the alignment of > literals referenced by relative address, has now been completed. > > https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=instruction-literal-pool > > It seems it was overlooked after being transferred from our old > request tool to the new - a case of "falling between two tools". > > Jonathan Scott, HLASM > IBM Hursley, UK >
Re: Curious compiler optimization
Thanks to all for the replies. I had clearly forgotten what MVHI did (OK, I probably never knew-too many new instructions!). As I said, it's not a problem, but I'm a bit bothered by your comment, Peter: > So this is not a curious "optimization". It is a natural non-optimization. Seems like the unoptimized code is oddly crude. I suppose compiler authors must fight the urge to do some basic optimization, but why would it ever be this bad? I do like the pseudo-assembler, putting as much info as possible in. It just threw me since I was first wondering "Is there some new assembler syntax I've missed??" ...phsiii (who is now having flashbacks to almost 40 years ago, dealing with FORTHX optimization that was optimizing the index increment out of loops.)
Re: Avoiding SIIS - (Was Base-less macros)
Wendell wrote: > From Tony's explanation concerning moving the TR command to the data area via LOCTR, can I surmise that it might be counter-productive to do so--that leaving the TR and EX commands in consecutive memory is more efficient? My $0.02 is that I'm not so sure about the "do it once with length of 1, then do it for real with EX" approach, but what is mentioned in the Kevin Shum paper that Tony referenced is that you want the target of the EX instruction "close" to the EX itself, so that the target instruction might already be in the i-cache and won't have to be fetched. I usually try to place it like this: SUBROUTINE_1DS0H ... EXR2,EX_TARGET ... BRR14 . EX_TARGET MVC 0(*-*,R3),0(R4) . SUBROUTINE_2DS0H ... so that the EX target isn't in a data area, but is "close" to the EX itself. == Adam Johanson R Software Engineer adam.johan...@broadcom.com -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: Curious compiler optimization
The compiler has to know which register contains zero in order to generate the LR. If the OP was asking about the MVHI then I understand the code but not what is curious about it. I found it obvious that the first comma indicated the lack of an index register; it was the second comma and displacement that I thought was awkward. In assembler I would have expect just var, with R13 and 160 implied by an active USING and visible in the object code as D0A0, although 160(R13) would certainly be a legitimate alternative. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Friday, November 12, 2021 9:04 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Curious compiler optimization > When it needs zero, it merely copies it into anther > register that it has allocated? Yes, but why not just store the register that they know already contains zero? Because they do not necessarily "know" that when the code is generated. It might well be that the removal of the extra instructions and the "knowledge" itself is an optimization, and the OP asked for no optimization. So this is not a curious "optimization". It is a natural non-optimization. Unless the OP's curiosity was about use of MVHI which, as was pointed out, is fully correct. I'd think that if you want decent code, you don't ask for no optimization. If you do ask for no optimization, you get what you get. Maybe that helps you learn how these compilers generate code. For example, the "initial" pass of the code-gen for z system does not necessarily assume knowledge of there being only 16 GRs available. Regarding "ST r0,var(,r13,160)" I have no idea, but this is not assembler, it is pseudo-assembler. If they don't document otherwise, it can be as "pseudo" as they choose. Maybe the leading comma is to indicate that there is no index register. That's how you'd code it in assembler (of course you'd have the "160" where "var" is). Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
If they are documented that way then it's legitimate, and, as you note, it provides more information then the assembler equivalent. IBM's current compilers for C, COBOL and PL/I use a common back end; the last I heard, IBM was not using that back end for Ada or FORTRAN, although those may no longer be supported. I would have expected them to use peephole optimization by now. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Friday, November 12, 2021 2:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Curious compiler optimization This is the usual way the generated statements are documented in the pseudo assembly listings since (I think) 20 years now, no matter if the compiler is C, PL/1 or COBOL (don't know about others). The shown ASSEMBLER code would not work, of course, but it shows the variable or structure names AND the offsets and base registers (sometimes other information like the name of intenal compiler work areas, control blocks etc.). What the "pseudo" assembly listing does: trying to put as much information as possible into the pseudo assembly notation, while still showing what the original machine instruction looks like. IMO, this "pseudo" notation is a clever solution, and: it is not an error. This said: most Windows etc. based compilers don't even have a compiler listing; at least it is completely uncommon to use it there. Kind regards Bernd Am 12.11.2021 um 03:46 schrieb Seymour J Metz: > If that were assembler source it would be invalid, but IBM uses various > pseudo-assembler formats in their compiler listings. > It's confusing and ugly, but unless IBM documents a different format it's > probably Broken As Designed (BAD). > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > > With NOOPT: > > * int var = 0; > > LA r4,0 > LR r0,r4 > ST r0,var(,r13,160) > > And I'm unclear what > > var(,r13,160) > > is supposed to be-the actual generated opcodes are > > 5000 D0A0 > > Which makes sense. Feels like there's an extra comma in there and an extra > offset. Maybe this is the compiler's way of saying "This is tinkering with > var, which is at offset 160"? I.e., it explicitly mentions both the variable > name and the 160 for readability? >
Re: Curious compiler optimization
> When it needs zero, it merely copies it into anther > register that it has allocated? Yes, but why not just store the register that they know already contains zero? Because they do not necessarily "know" that when the code is generated. It might well be that the removal of the extra instructions and the "knowledge" itself is an optimization, and the OP asked for no optimization. So this is not a curious "optimization". It is a natural non-optimization. Unless the OP's curiosity was about use of MVHI which, as was pointed out, is fully correct. I'd think that if you want decent code, you don't ask for no optimization. If you do ask for no optimization, you get what you get. Maybe that helps you learn how these compilers generate code. For example, the "initial" pass of the code-gen for z system does not necessarily assume knowledge of there being only 16 GRs available. Regarding "ST r0,var(,r13,160)" I have no idea, but this is not assembler, it is pseudo-assembler. If they don't document otherwise, it can be as "pseudo" as they choose. Maybe the leading comma is to indicate that there is no index register. That's how you'd code it in assembler (of course you'd have the "160" where "var" is). Peter Relson z/OS Core Technology Design
