Re: Why is Cobol ignored in compiler textbooks?

In article 92-04-099 John Levine (the moderator) 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]


Speaking as an implementor, I don't know what John means by this.
Picture data has neither numeric nor string values.
[If you use picture data in a string context e.g. printing, it acts like a
string, while if you use it in a numeric context, e.g. arithmetic it acts
like a number. -John]


(i) The picture of a non-edited field (no floating symbols or * $ . _ + B
/ characters - there may be more, don't quote me) is interpreted at
compile time only, and turns into a tuple (datatype, byte-length, digits,
decimals, sign, ...).


(ii) The picture of an edited field is typically encoded much like a
BASIC-PLUS PRINT USING mask (or whatever the hardware edit instruction
likes, if any), and is used at run-time when storing (MOVE, ADD, SUB,
DIVIDE, MULTIPLY, COMPUTE) into the edited field. COBOL-85 also allows you
to use edited field as a source operand; this is the same process in
reverse.


Other contributors speculated on how to implement fall-throughs out of
paragraphs and sections. The end of a paragraph (section) is basically a
conditional return which is taken if the paragraph (section) is currently
marked as a PERFORM exit in a paragraph-indirection table. This
information is set up and cleared by the PERFORM statement. It need only
be 1 bit: extending it to a value field would allow support of recursive
PERFORMs which are non-standard.


You also need the indirection table to support ALTER; contrary to yet
another statement, ALTER was not dropped from either the 74 or the 85
standards, and must be supported for certification. It has been declared
obsolete and will not appear in COBOL-9X.


COBOL presents unique lexical, syntactic and semantic problems, and it has
not been well served by the academic community.


One problem which in general it does _not_ present is a requirement for
massive optimization in the code generation phase. COBOL statements
typically compile to calls to longish library routines whose execution
time completely dominates; also, active variables rarely fit into a
register.
--
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz
--

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