An ancillary "problem" with making these changes is that code is being
changed. Which takes time. Which is money. So there needs to be a cost
justification. I can imagine how difficult it would be to find, code,
AND TEST every z/OS macro which does something akin to:
BAL R1,*+8
DC FL4(value)
L R1,0(,R1)
with the equivalent:
LLILF R1,value
or, if "value" is an ADCON:
LLILF R1,0
ORG *-4
DC AL4(adcon)
could be significant. And the difficulty of replacing something like:
CNOP 0,4
BAL R1,*+4+3*4
DC F'one',F'two',F'three'
LM R1,R3,0(R1)
would be even worse.
Now, for a new macro, or a major rewrite of an old macro, it would be
obvious to use the new instructions. But once done, the software
definitely won't run on older hardware. Perhaps IBM would not really
care. But a smaller ISV just might.
On Sun, 2010-08-22 at 19:17 -0400, John P. Baker wrote:
> Keith,
>
> Most of what you are asking for is already available using AFI, ALFI, CFI,
> CLFI, LHI, LLILF, NOLF, OILF, and XILF.
>
> It is not necessary to save anything in a GBLx array.
>
> It is just necessary to use the new instructions.
>
> I have raised the same issue on the z/VSE side. We need to have the system
> macros updated to make use of the machine instructions available in the
> minimum supported hardware architecture level for that release of the
> operating system.
>
> And yes, I know that doing so will create an issue for ISVs in that code
> assembled for operating system level n+1 may not run on operating system
> level n.
>
> So be it. I can live with that.
>
> John P. Baker
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:[email protected]]
> On Behalf Of Keith E. Moe
> Sent: Sunday, August 22, 2010 5:34 PM
> To: [email protected]
> Subject: Suggestion for System Macros
>
> One of my pet peeves about many system macros is that some of them generate
> inline constants which they have to branch around. This not
> only generates an extra branch instruction which, while being unconditional,
> it's not a major slowdown in the pipeline, it means that the cache
> line has to be in both the instruction and data caches, even in reentrant
> code.
>
> I would like to see a system macro option that would cause these macros the
> save their "inline constants" in a GBLC array. This array would
> be used by a system "constant dump" macro which would generate the DCs for
> the accumulated constants. I'm not looking for the HLASM to
> generate them automatically like literals (many macros are now using
> literals anyway), but changes to the existing macros to do this.
>
> And, yes, if the user fails to code the "dump" macro or codes it where there
> is no addressability, I expect assembly errors.
>
>
> Keith E. Moe
> MAINVIEW for z/OS Support
> BMC Software, Inc.
