IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

IBM Enterprise COBOL compiler optimisation


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Martin Ward

New User


Joined: 20 Mar 2007
Posts: 2
Location: Durham

PostPosted: Thu Mar 22, 2007 4:40 pm
Reply with quote

I work to develop automated technology for migrating assembler to C and COBOL.

One of our customers is migrating to mainframe COBOL and is getting very poor performance from the COBOL we generate (CPU usige is nearly 10 times higher than for the assembler). The COBOL code looks pretty good, but looking at the output of IBM's COBOL compiler there are a lot of unnecessary instructions being generated.

For example, R5 and R6 are two fullwords, defined as PIC S9(9) COMP. The simple ADD statement:

ADD R5 TO R6

compiles into this code:

001416 ADD
00070A 5840 A060 L 4,96(0,10) R5
00070E 8E40 0020 SRDA 4,32(0)
000712 5800 A068 L 0,104(0,10) R6
000716 8E00 0020 SRDA 0,32(0)
00071A 1A04 AR 0,4
00071C 1E15 ALR 1,5
00071E 47C0 B4C2 BC 12,1218(0,11) GN=81
(000726)
000722 5A00 C004 A 0,4(0,12) SYSLIT AT +4
000726 GN=81 EQU *
000726 5010 A068 ST 1,104(0,10) R6

It converts the fullword values to doublewords (in four registers),
adds the high order fullwords, adds the low order fullwords and finally stores the low order fullword in the result! icon_rolleyes.gif

Is there some way to get the compiler to just do a simple fullword
load, add, store? I would expect to see something like:

L 4,96(0,10) R5
A 4,104(0,10) R6
ST 4,104(0,10) R6

... but with proper register allocation eliminating a lot of the load and store instructions.

The code for:

MOVE LINK-TMP-BIGDATA-1(1:R5) TO LINK-TMP-BIGDATA-2(1:R5)

is even worse, generating a huge block of code (including an MVCL instruction) ending up with a call to a support function IGZCVMO to do the actual move!

Why can't it just generate a simple MVCL?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Mar 22, 2007 4:49 pm
Reply with quote

Not sure which, bot I think some of the compiler options might affect the math behavior.
Have you got the optimizer active?
Back to top
View user's profile Send private message
Martin Ward

New User


Joined: 20 Mar 2007
Posts: 2
Location: Durham

PostPosted: Thu Mar 22, 2007 5:50 pm
Reply with quote

Compiler options included: AWO, ARITH(COMPAT), AWO, DATA(31), OPTIMIZE(STD), NUMPROC(NOPFD), TRUNC(OPT), NOSSRANGE, NOTEST, NOTHREAD.

OPTIMIZE(FULL) is the same as OPTIMIZE(STD) except that it also deletes unreferenced data items (which we don't want to do, since we want to preserve the data layout: data is accesed via pointers).

Is there any difference between TRUNC(OPT) and TRUNC(BIN) for binary computations?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Mar 22, 2007 6:03 pm
Reply with quote

Personally, I prefer TRUNC(BIN), why not change it and compare the PMAPs?
BTW, it doesn't really delete, it just doesn't include unreferenced data items in the load module. If at son=me later date, the program is modified to reference one, it magically reappears.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts How I Found a Bug in a FORTRAN Compiler All Other Mainframe Topics 4
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
Search our Forums:

Back to Top