Speaking of optimizations, a while back I noticed the COBOL compiler generated
the following code to edit a PIC 9(4) BINARY value into a PIX ZZZZ9 field
MVC 496(6,R13),1851(R3) # TS2=119 +185
LLH R2,8(,R2) # U010-CO-ID
VCVD VRF16,R2,0x85,0
VUPKZ VRF16,1005(,R13),0x4 #
CDZT FP0,1005(5,R13),0x8 #
ESDTR R2,FP0
VL VRF17,2224(,R3),0 #
VL VRF18,2240(,R3),0 #
VLRL VRF20,1005(,R13),0x4 #
VGBM VRF19,0x0
VLEIB VRF19,0xf0,15
VO VRF20,VRF20,VRF19
VPERM VRF16,VRF17,VRF20,VRF18
LHI R4,0x5
VSTL VRF16,R4,496(,R13) # TS2=119
VREPIB VRF20,0x40
LLC R4,2256(R2,R3) #
LTR R4,R4
JE L0642
AHI R4,0xffff
VSTL VRF20,R4,497(,R13) # TS2=119
L0642: EQU *
L R2,108(,R8) # BLL_9
MVC 8(5,R2),497(R13) # U016-CO-ID-DISPLAY TS2=119
I thought "All those vector instructions are better than an a single ED? I'd
better learn what that's doing so I can use that technique myself".
Today, I decided to recompile the module to see if it generates better code
since I noticed some of the above code could be further optimized. Our current
COBOL 6.4 compiler generated:
MVC 536(6,R13),2403(R3) # TS2=119 +2403
LLH R2,8(,R2) # U010-CO-ID
CVD R2,1050(,R13) #
ED 536(6,R13),1055(R13) # TS2=119
L R2,88(,R8) # BLL_9
MVC 8(5,R2),537(R13) # U016-CO-ID-DISPLAY TS2=119
Robert Ngan
DXC Luxoft
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Ian Worthington
Sent: Wednesday, August 20, 2025 06:16
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Execute-Type Instructions
[Some people who received this message don't often get email from
00000c9b78d54aea-dmarc-requ...@listserv.uga.edu. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
I had the opportunity a couple of years ago to do a deep dive into C/C++ (gcc)
optimisation, resulting from an incidence of integer overflow in a z/TPF C
segment. For those who are unfamiliar with the C language standardisation
backstory it seems that the original standards committee was tasked with
writing a language definition that encompassed all the different ways that
compilers of that time dealt with such matters as integer overflow. They did
this by the liberal use of such terms as "undefined" and "implementation
dependant", a situation which has lead to airline groundings and deaths,
amongst other things. Nothing quite so dramatic in our case, just a near
strike by a group travel booking office.
After fixing the immediate issue I took the opportunity to investigate what
could be done to remedy this situation more robustly, and implemented my own
arithmetic functions using C and gcc's inline assembler. As they stood, these
were horribly inefficient, but when gcc's level 3 optimisation stripped away
all of the function call overhead and what remained was only the arithmetic
operation, the CC check, and a conditional branch, just as if we had coded the
most optimal solution in line.
I came away with a deep respect for the optimisation routines.
> but all hardware enhancements> need to be translated into compiler code.
> Changing the compiler is tedious and laborious.
I did, out of curiosity, take a journey down the gcc optimisation pathway, but
came away bloodied and confused. It seemed, iirc, that there are both generic
optimisers and architecture-specific optimisers/code generators. In order to
add enhancements it is only necessary to modify the later (the gcc maintainers
will do this) and then programs may be recompiled at leisure. This seems a
much better solution than hand-modifying and retesting one's entire code base.
I am no fan of the C language "portable assembler", but came away from this
exercise mightily impressed with the capabilities of gcc.
(Should you want to know more, a write up, and a presentation deck, are
available at [snipped]
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
[snipped here and above to get under the posting line limit]
