On 17 Feb 2014 10:13:44 -0800, in bit.listserv.ibm-main you wrote: >On Mon, Feb 17, 2014 at 12:06 PM, Elardus Engelbrecht < >[email protected]> wrote: > >> Ted MacNEIL wrote: >> >> >I have to ask: Why they big concern over a few instructions? >> >> Good question. This is why I asked that loop question earlier today. But >> I'm following this fun thread about the cache, fetch/modify by different >> CPs and execution prediction. Just curious of course. >> >> >Optimisation of a few is not worth the effort these days. >> >> After my question, someone posted me off-line that if the machine only >> execute ONE instruction PER second, then only, then this optimisation work >> is worth the trouble. >> >> Groete / Greetings >> Elardus Engelbrecht >> > >Of course, IBM is trying to make this discussion moot by getting people off >of using assembler at all, and implementing a code generation "back end" >which will produce "better than the average HLASM programmer" code for >C/C++, Java, and COBOL (COBOL code generation, pre-V5.1 at least, really >stinks IMO). I don't know if IBM worries as much about FORTRAN and PL/I >these days.
If the code generated by the COBOL compiler at your installation stinks, review the compile options. The compiler does such optimizations as code movement, elimination of unnecessary subscript calculation and loop unrolling. If the code in your shop contains a lot of GO TO statements this can defeat the ability of the compiler to do many of its optimizations. Code generated by CSP V1.4 was so convoluted that programs had to be compiled NOOPTIMIZE. In general, I would look to see what the OPTIMIZE setting is, choose TRUNC(OPT) for most programs (for BINARY to BINARY operations no truncation according to PICTURE will occur based on tests I ran in the late 1990s) and either NUMPROC(MIG) or NUMPROC(PFD) depending on your data. If your shop is moving to COBOL 5.1 and it currently uses NUMPROC(MIG) because of F zones in sign positions of signed fields then your shop will have to change to NUMPROC(NOPFD). I hope that 5.1 generates the same code for NUMPROC(NOPFD) that it used to for NUMPROC(MIG). If your shop has COBOL programs that perform poorly, it may be due to poor choices of field definition or excessive use of GO TO. This can defeat PERFORM optimization. There were some cases of what I considered poor code generation but in general starting with COBOL 1.4, the first full 1985 standard COBOL from IBM the code generation has been good and in some cases impressive. Clark Morris ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
