According to Tom Ross (of IBM COBOL development) at SHARE last year, they are working on migrating the "back end" to the same one that PL/I uses. (And I am assuming the same one some of the other languages also use.)
No idea if that would "fix" COBOL arithmetic. Frank ----- Original Message ----- > From: "McKown, John" <john.mck...@healthmarkets.com> > To: IBM-MAIN@bama.ua.edu > Cc: > Sent: Thursday, April 12, 2012 10:45 AM > Subject: Re: Modernizing the BCP code ? > > Now that you mention it, I remember that the C/C++ compiler has a > architecture > option to control the instructions generated. I should have known that the > PL/X > compiler would too. I didn't know that they both share the same back-end. I > wish that the COBOL compiler did. I am constantly amazed at the amount of > code > generate by a simpe: > > ADD +1 TO WS-INTEGER. > > when WS-INTEGER is defined as PIC S9(9) BINARY or NATIVE. COBOL seems to have > an > inordinate love for PACKED-DECIMAL. Someone once said it was due to ANSI > standards compliance. Might be worth it, in CPU saved, to license the C > compiler > and port the OpenCOBOL > > Unless I somehow have the wrong compile parameters. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact > the sender by reply e-mail and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten and issued by > the > insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance > Company(r), Mid-West National Life Insurance Company of TennesseeSM and The > MEGA > Life and Health Insurance Company.SM > > > >> -----Original Message----- >> From: IBM Mainframe Discussion List >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Crayford >> Sent: Thursday, April 12, 2012 11:04 AM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Modernizing the BCP code ? >> >> AFAIK, the PL/X compiler shares a back-end with the other code >> optimizers, so should produce excellent code. The compiler team is in >> Toronto and I was lucky enough to talk to a few at Share in Orlando. >> As it stands z/OS needs to run on machines as old as a z/800. So the >> architecture level (ARCH(n)) of BCP code has to support old >> hardware. As >> Bob Shannon mentioned, with z/OS going to a new version >> IBM can safely recompile the BCP PL/X code for not so ancient boxes. >> >> On 12/04/2012 11:14 PM, McKown, John wrote: >> > First thing to wonder about is: "Has IBM upgraded the >> PL/AS(current name?) compiler to emit Relative and Immediate >> instructions?". Most of the BCP is supposedly written in >> PL/AS, not HLASM. Second, for those modules which are written >> in HLASM, is it cost effective to IBM to systematically >> update the source from the older instructions? Why would it >> be? The new instructions may (or may not) be less resource >> efficient that the older versions.I doubt that many are more >> efficient (LHI being more efficient seems likely). Many of >> the R&I instructions are longer than the corresponding >> Base+Displacement instruction. The simpliest thing for IBM >> would be to use the IEABRCX macro to change all the branch >> instructions to branch relative instructions. But you can't >> do that type of OPSYN method to do something like replacing >> the LA with an LARL. So replacing LA with LARL would require >> looking at every LA instruction to see if it could be >> replaced by an LARL. The same with replacing selec! >> te! >> > d L and LH with LHI, which would verifying that the value >> being loaded is indeed never modified. And I don't see a >> general way to do it if they are inside a macro. And an LARL >> may not be the best idea simply because it is 6 bytes instead >> of the LA instruction's 4 bytes. So, at the very least, it >> will take up more space in the I-cache hardware. Other >> immediate instructions may also require more bytes that the >> replaced instruction. So, IMO, a command such as "Replace all >> base+displacement instructions in a program with the >> corresponding R&I instruction, whenever possible." is not a good > idea. >> > >> > IMO, the only time to use a relative instruction is in >> "baseless" code. Only use "baseless" coding when you > are >> either out of registers or you need too many base registers >> due to the size of the program. Which, in HLASM programs, >> usually means the program is too big and should be split up somehow. >> > >> > Again, the only time to use immediate instructions is when >> the value is a constant and will fit into a halfword. Why a >> halfword? Because the LHI is the same number of bytes as the >> LH or L instruction, taking up the same I-cache space. And >> because the immediate instructions to load a fullword are >> larger than the base+displacement load instruction, and so >> use more I-cache space. Space which may be better spend >> buffering more instructions and let the D-cache hold the >> value instead of the I-cache holding the equivalent of the >> instruction and data, and not using the D-cache. This is >> especially true if there are two or more immediate >> instructions in the I-cache that are loading the same value. >> In this case, assuming the duplicate instruction is something >> like "L r,=F'10'", the F'10' would be held in the > D-cache and >> so be likely be used almost as fast, if not equally fast, as >> it would be by being encoded in the instruction in the I-cache. >> > >> > However, I will freely admit that I use R&I instructions in >> preference to B+D instructions in most of my HLASM programs. >> > >> > Oh, and one other reason to use at least one Branch >> instruction in your program instead of a Brance Relative. If >> the start of a program starts with the sequence: >> > >> > USING *,15 >> > B AROUND >> > DC C'some character string' >> > AROUND DS 0H >> > >> > Then the SYSUDUMP will print "some character string" in the >> save area trace portion of the dump. In most cases, this >> works because GPR15 points to the B instruction. >> > >> > -- >> > John McKown >> > Systems Engineer IV >> > IT >> > >> > Administrative Services Group >> > >> > HealthMarkets(r) >> > >> > 9151 Boulevard 26 * N. Richland Hills * TX 76010 >> > (817) 255-3225 phone * >> > john.mck...@healthmarkets.com * www.HealthMarkets.com >> > >> > Confidentiality Notice: This e-mail message may contain >> confidential or proprietary information. If you are not the >> intended recipient, please contact the sender by reply e-mail >> and destroy all copies of the original message. >> HealthMarkets(r) is the brand name for products underwritten >> and issued by the insurance subsidiaries of HealthMarkets, >> Inc. -The Chesapeake Life Insurance Company(r), Mid-West >> National Life Insurance Company of TennesseeSM and The MEGA >> Life and Health Insurance Company.SM >> > >> > >> > >> >> -----Original Message----- >> >> From: IBM Mainframe Discussion List >> >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari >> >> Sent: Thursday, April 12, 2012 9:16 AM >> >> To: IBM-MAIN@bama.ua.edu >> >> Subject: Modernizing the BCP code ? >> >> >> >> Hi >> >> >> >> We try to modernize our code here, with relative >> instructions, long >> >> displacements , immediate s etc etc >> >> What about the control program ? >> >> Just got some REXX IRXINIT dumps, and seems to me the code >> >> is not very >> >> modern. >> >> >> >> >> ---------------------------------------------------------------------- >> >> For IBM-MAIN subscribe / signoff / archive access instructions, >> >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN >> >> >> >> >> > >> ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
