Re: z/Architecture Principles of Operation pdf
On Nov 14, 2021, at 14:52:12, Charles Mills wrote: > > Well, not sure it's sensible but "z Architecture" is not a "feature of z/OS." > Yes, but still a hyperlink would be useful. > Yes, yes, of course, not very sensible. z/OS only runs on one type of > hardware, and any assembler developer interested in z/OS is interested in how > the hardware works. > Even less sensible is that SuperC comes with either ISPF or HLASM TK with separate manuals. The M&C differ largely in messages prefixes and degree of obsolescence. When I suggested in these lists that SuperC be made a single dependent FMID, applicable to either product, with a uniform component prefix, an IBM representative replied that Would be contrary to Company Policy. > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Bob Raicer > Sent: Sunday, November 14, 2021 1:18 PM > > I am curious to know why z/Architecture Principles of Operation > (SA22-7832) is not included in the z/OS 2.5 documentation collection > (ZOSV2R5-PDFKIT_GA2021.zip), nor is it in the z/OS 2.4 documentation > collection (zOSV2R4Library.zip), nor is it in the z/OS 2.3 > documentation collection (zOSV2R3Library.zip). > > SA22-7832-10 WAS included in the z/OS 2.2 collection (C27843006.zip) > and a current-at-the-time version was included in all prior collections > (as best as I can tell). > > It can be obtained by going through > https://www-01.ibm.com/servers/resourcelink, however, this requires > an IBM Resourcelink user ID and the pub seems to be in a machine > model specific library (for example, the "z15 Model T01 library"). > > Is there some (sensible) reason for this? -- gil
Re: z/Architecture Principles of Operation pdf
Well, not sure it's sensible but "z Architecture" is not a "feature of z/OS." Yes, yes, of course, not very sensible. z/OS only runs on one type of hardware, and any assembler developer interested in z/OS is interested in how the hardware works. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bob Raicer Sent: Sunday, November 14, 2021 1:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: z/Architecture Principles of Operation pdf I am curious to know why z/Architecture Principles of Operation (SA22-7832) is not included in the z/OS 2.5 documentation collection (ZOSV2R5-PDFKIT_GA2021.zip), nor is it in the z/OS 2.4 documentation collection (zOSV2R4Library.zip), nor is it in the z/OS 2.3 documentation collection (zOSV2R3Library.zip). SA22-7832-10 WAS included in the z/OS 2.2 collection (C27843006.zip) and a current-at-the-time version was included in all prior collections (as best as I can tell). It can be obtained by going through https://www-01.ibm.com/servers/resourcelink, however, this requires an IBM Resourcelink user ID and the pub seems to be in a machine model specific library (for example, the "z15 Model T01 library"). Is there some (sensible) reason for this? Thanks. Bob Raicer
z/Architecture Principles of Operation pdf
I am curious to know why z/Architecture Principles of Operation (SA22-7832) is not included in the z/OS 2.5 documentation collection (ZOSV2R5-PDFKIT_GA2021.zip), nor is it in the z/OS 2.4 documentation collection (zOSV2R4Library.zip), nor is it in the z/OS 2.3 documentation collection (zOSV2R3Library.zip). SA22-7832-10 WAS included in the z/OS 2.2 collection (C27843006.zip) and a current-at-the-time version was included in all prior collections (as best as I can tell). It can be obtained by going through https://www-01.ibm.com/servers/resourcelink, however, this requires an IBM Resourcelink user ID and the pub seems to be in a machine model specific library (for example, the "z15 Model T01 library"). Is there some (sensible) reason for this? Thanks. Bob Raicer
Re: Curious compiler optimization
(OK, I said I was done, but Michael Schmitt's excellent post deserves attention) Michael wrote, in part: >I think what we're seeing is the evolution of compilers on z/OS. ... >In the example case, Phil pointed out that the C code is really >two operations: define a variable, and then move (initialize) a >value to it. FTR, that was Robin, not me. >My guess is that at opt(0) the compiler is just outputting the >generated instructions for the pseudo-ops directly, 1 for 1. That's intriguing and could be the explanation!
Re: Curious compiler optimization
[snipped due to line limit] I think what we’re seeing is the evolution of compilers on z/OS. Take the COBOL compiler: it used to be that the optimizer was a distinctly optional extra step. That is, NOOPT would generate a reasonable set of instructions, that would be approximately what a person trying to write straight-forward assembler would do. The optimizer would apply more global optimizations, such as loop unrolling and common expression elimination. The IBM COBOL for z/OS 5 & 6 compiler is rewritten, and generates much more aggressive optimization. It rearranges the statement order, even to the extent of performing sections in a different order than coded. I think the way the modern compiler works is the front end decomposes the statements down to a set of pseudo-operations, that are not optimized at all, and don’t directly map to zArchitecture instructions. Then the back end optimizes the pseudo-ops and then generates the machine instructions necessary to implement them. In the example case, Phil pointed out that the C code is really two operations: define a variable, and then move (initialize) a value to it. So, this could be two pseudo-ops. My guess is that at opt(0) the compiler is just outputting the generated instructions for the pseudo-ops directly, 1 for 1. And since the pseudo-ops aren’t directly equivalent to z/OS instructions, you end up with code that neither a human nor the older compiler would generate. But I could be wrong.
Re: Curious compiler optimization
OK, you seem to be sensitive to questions about how compilers work and/or deliberately misinterpreting my questions, so I'm going to drop this. -Original Message- From: robi...@dodo.com.au Sent: Sunday, November 14, 2021 7:04 AM To: Phil Smith III Cc: 'IBM Mainframe Assembler List' Subject: Re: Curious compiler optimization On 2021-11-14 03:10, Phil Smith III wrote: >> 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. No it isn't. It contains a declaration and an initialization. >> 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. Rubbish. An LR instruction is one of the smallest and fastest. > This is code that will run billions of times, The body of the procedure will take far longer than the "LR". Compared to that code, the time taken by the LR will be negligible. And if it were to be run "billions" of times, you wouldn't be running it unoptimised. > often millions in a single run; > yes, we will feel it. No you won't. > 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? Because you asked it to. You specified no optimisation. > Note that I had the same ARCH() value on both versions. That's irrelevant. > So why wouldn't the > original code use the same fancy new instruction? Because you didn't ask for optimisation. > I would have assumed that optimization meant considering how > statements interact, not generating lousy code for each on purpose. Specifying optimisation does not generate lousy code "on purpose". Have you got your lines crossed? In any case, optimisation can involve optimisation within a statement; moving code from inside a loop to outside a loop; and improving the transition between statements. > 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...
Re: Curious compiler optimization
On 2021-11-14 03:10, Phil Smith III wrote: 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. No it isn't. It contains a declaration and an initialization. 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. Rubbish. An LR instruction is one of the smallest and fastest. This is code that will run billions of times, The body of the procedure will take far longer than the "LR". Compared to that code, the time taken by the LR will be negligible. And if it were to be run "billions" of times, you wouldn't be running it unoptimised. often millions in a single run; yes, we will feel it. No you won't. 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? Because you asked it to. You specified no optimisation. Note that I had the same ARCH() value on both versions. That's irrelevant. So why wouldn't the original code use the same fancy new instruction? Because you didn't ask for optimisation. I would have assumed that optimization meant considering how statements interact, not generating lousy code for each on purpose. Specifying optimisation does not generate lousy code "on purpose". Have you got your lines crossed? In any case, optimisation can involve optimisation within a statement; moving code from inside a loop to outside a loop; and improving the transition between statements. 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...
