On 2025-08-22 15:35, Seymour J Metz wrote:
Peephole optimization, yes, and the can vary the object code based on the >
target processor, but I have seen some truly ghastly code generated by older
PL/I compilers for unaligned bit strings.
In 1996 I rewrote a CRC calculating program at a client. It used unaligned bit
strings. Moving them to aligned ones at the start, doing the (optimised)
calculations on these, and moving them back to the unaligned one at the end
reduced, as measured by Strobe, the CPU time by 99.7%...
How good is the code for unaligned bit strings in Enterprise PL/I.
Never tried that, and don't have the tools, other than a wand-clock to test it,
but there's not really any reason for not trying to start two programs at the
same time, one with unaligned bit strings, the other with aligned ones, and let
them run for a couple of hours. (Yes, on that system...)
Assembler has an advantage over compilers when the application needs to do
things that do not map well into the source language, but even there the
compiler might surprise you.
Comparing the code generated with the old OS V2.30, PL/I Optimizing Compiler,
and the code generated with Enterprise PL/I, you might in some cases be
disappointed, despite two or three decades of compiler development. And looking
at the code generated by IBM's PL/I for Windoze? Don't get me started.
Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html
External Message: Use Caution
I agree with this. The compiler folks work hard to generate the most efficient
code based on the target HW. I can (usually) do slightly better than the
compiler for small loops (where I know exactly what idiosyncrasies to take
advantage of) but for anything more than a couple dozen HLL lines of code, the
compiler beats me every time, even without optimizations.
With optimizations, I don't stand a chance. My take is that unless I need to
very carefully set up for HW instructions that are not supported by the HLL
(instructions such as those used for CPACF), it's never worth my time to do the
work fully in assembler.
Eric Rossman
---------------------------------
ICSF Security Architect
z/OS Security
---------------------------------
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Colin Paice
Sent: Friday, August 22, 2025 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: RMODE 64 - Why?
I remember about 40 years ago, the CICS development team were very pleased with
their work optimising the CICS dispatcher code - the key code was written in
assembler, and polished till they could get no more benefits from tuning it.
Then came the next generation hardware, and all their polishing was of no
benefit. They found it was best to structure their code and let the PLS
compiler optimise it - which was generally better than they could.
Colin
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
