Related articles |
---|
Re: Why is Cobol ignored in compiler textbooks? preston@dawn.cs.rice.edu (1992-04-22) |
Cobol picture data ericj@csn.org (Eric Jacobsen) (1992-04-22) |
Re: Cobol picture data reid@csgrad.cs.vt.edu (1992-04-23) |
Re: Cobol picture data md@sco.COM (1992-04-27) |
Newsgroups: | comp.compilers |
From: | md@sco.COM (Michael Davidson) |
Keywords: | Cobol |
Organization: | The Santa Cruz Operation, Inc. |
References: | 92-04-099 92-04-109 |
Date: | Mon, 27 Apr 1992 19:23:58 GMT |
ericj@csn.org (Eric Jacobsen) writes:
>> [One issue I haven't seen addressed is Cobol picture data, which has a
>> numeric value in a numeric context and a string value in a string context.
>> Do you keep two copies, one copy and convert on demand, or what? -John]
Typically, yes, you keep one copy in the format specified by the PICTURE
clause and convert on demand at the time that the data is used. Actually
there are multiple numeric data formats, including (at least) DISPLAY,
COMP and COMP-3 which are unpacked ASCII, binary and packed decimal,
respectively.
Conversion among numeric, alphanumeric and edited data types really only
occurs on MOVE operations. Conversion between numeric types happens
implicitly whenever you do arithmetic on them.
Where numeric operands are all of the same type most Cobol compilers try
pretty hard to do all of the arithmetic in that format, so you will
typically find compilers generating code for unpacked ASCII, packed
decimal and binary arithmetic according to the operand types. (Even if the
operands are all binary in the native byte and word order of the machine
the arithmetic is complicated by the fact that the precision of the result
is specified as an exact number of *decimal* digits so that rounding and
overflow checks still have to worry about the decimal value of the result.)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.