Related articles |
---|
Why is Cobol ignored in compiler textbooks? tfj@cix.compulink.co.uk (Trevor Jenkins) (1992-04-20) |
Is COBOL Boring? davidm@Rational.COM (1992-04-22) |
COBOL optimization (Was: Is COBOL Boring?) nolan@tssi.com (1992-04-23) |
Newsgroups: | comp.compilers |
From: | nolan@tssi.com (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, nolan@tssi.com
Tailored Software Services, Inc.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.