Others have well-addressed your central questions. Let me just address this one thing:
> if developing software for distribution, > is it best to avoid using the "newer," fancier instructions I have been developing almost exclusively "product" software for distribution to multiple, unknown at the time of development, customers -- for about 50 years, most of it on the 360 and its successors. I used to avoid the "new" instructions (whatever "new" meant at the time). It took me a long time to embrace the S/370 enhancements to the original instruction set. I thought "what if some prospect has an older machine?" I'd hate to lose even one deal. Well, through years of commercial software product development and management I have learned the following: there may be shops out there with ancient hardware. But they are 100% shops that are "getting off the mainframe." (Some may be in the eighth year of a three-year project to get off the mainframe, but that is a different topic, and it has already been hashed to death here.) So they are not your prospects. They are not going to buy your product even if it DOES run on a z900 or whatever. So there is no need to eschew "new" instructions. My rule is to support the oldest version of z/OS still in extended support, which I believe is currently V2R2, and the oldest hardware that it supports, which is the z10. My theory is that any customer that considers the mainframe vital enough to warrant an investment in the product is not running an unsupported OS. So I would use decimal floating point and extended immediates, but eschew vector packed decimal. If you have *extremely* performance-sensitive portions of your code then dual-pathing may be appropriate. FWIW, most of my current development is in C++, and the great thing about compiled languages is that you can just "turn the dial" on the supported hardware. Some customer wants maximal performance and is willing to pay you for it? Do a custom build for them with ARCH(13). Some customer surfaces who is still running a z9? Do a custom build with ARCH(7). Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Dave Clark Sent: Friday, March 4, 2022 9:01 AM To: [email protected] Subject: Long Displacement Facility (was: Fun with RXSBG) "IBM Mainframe Assembler List" <[email protected]> wrote on 03/03/2022 05:22:52 PM: > Not counting any branch following the determination, I had > previously managed to trim this down to three instructions. For > example, to determine if a prospective insertion crosses a 4 K-byte boundary: > 1. LAY S,-1(L,P) where "S" is a scratch register. > 2. XR S,P determine the difference > 3. NILF S,X'FFFFF000' Turn off insignificant bits. The second operand of the first instruction in this sequence caught my eye -- having not seen negative displacements -- before but immediately appreciating its applications. So, I first thought I would ask what are the benefits of doing it that way as opposed to the following more traditional approach (other than the obvious of simply "one less instruction")? LA S,0(L,P) AHI S,-1 Secondly... I missed the Y the first time and tried testing the following. That, of course, generated a syntax error (invalid displacement). LA S,-1(L,P) So, I looked at the original email again and did some research into the LAY instruction. That is when I read about the Long Displacement Facility (LDF) having to be installed for this instruction to work (otherwise: operation exception). So, other than just trying it, how would I determine if the box we are on (2818) has the LDF? Further, if developing software for distribution, is it best to avoid using the "newer," fancier instructions and just stick with the more traditional approaches?
