COBOL optimization (Was: Is COBOL Boring?) (Michael Nolan)
Thu, 23 Apr 1992 14:50:03 GMT

          From comp.compilers

Related articles
Why is Cobol ignored in compiler textbooks? (Trevor Jenkins) (1992-04-20)
Is COBOL Boring? davidm@Rational.COM (1992-04-22)
COBOL optimization (Was: Is COBOL Boring?) (1992-04-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Michael Nolan)
Keywords: Cobol
Organization: Tailored Software Services, Inc.
References: 92-04-093 92-04-105
Date: Thu, 23 Apr 1992 14:50:03 GMT

davidm@Rational.COM (David Moore) writes:
>There is one optimization which I am curious to know if anyone has ever
>implemented in a COBOL compiler. COBOL has a lot of data types for
>numeric values. Computation on some of these (eg ASCII rep, packed BCD)
>is often slow compared to computation of binary values, especially as many
>machines have no support for these types built into the instruction set.

>Has anyone implemented a COBOL compiler which attempts to replace
>expensive data representations by cheaper ones? Two methods of doing this
>which come to mind are flow analysis and lazy conversion.

It seems to me that back in '89 when I was beta testing the COBOL 85
compiler for NCR (based on the LPI engine) that there was some mention of
this idea. I know that NCR's 'native' compilers (as opposed to their
RPOPS/Ryan-McFarland heritage compilers) are somewhat less predictable in
their treatment of unexpected/illegal values in numeric variables.

Any flow analysis would have to take into account the existence of
REDEFINES, which often are used to restructure data even though it may be
in a less efficient computational format. Likewise, any variables that
are used in I/O operations might need to be untouchable. (Unless
conversion from/to 'proper' format is to be done at the time of the I/O
operation, a potential bottleneck in itself.) Finally, variables that are
used in CALL statements would need to be passed in their defined form.
Michael Nolan,
Tailored Software Services, Inc.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.