Re: COBOL datatype and other COBOLisms

Trevor Jenkins <tfj@cix.compulink.co.uk> writes:


>Taking a survey of the compiler text books I have on my shelf I noticed
>that none discussed the problems of compiling Cobol.


Yes, it is an important language, given the installed base of code;
however, not too many COBOL programmers are going to be interested in
compiler techniques....


There ARE, however, compilers WRITTEN in COBOL (with many extensions).
Given the verbosity of COBOL, just imagine the size of the source code!


---------------------------
On COBOLs PICTURE datatype:
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]


No, although it is an interesting idea. But keeping two forms around
would double the amount of work required on operations on PIC() data. The
COBOL PIC() datatype and the PL/I PICTURE() datatype are very similar,
and, for our common back-end, the picture data is compiled into a separate
storage class (basically a structure), and at runtime, a finite-state
machine does the appropriate stuff. Some hardware/OS's have support for
PICTURE data, which a compiler could utilize, but many of the recent
architectures don't. Some of the semantics of PICTURE data for PL/I
conflict for COBOL PICTURE data, so the state machine gets a bit tricky to
deal with. Curiously enough, typical usage of the PICTURE() datatype in
PL/I seems to simply put digits into the variable, (effectively treating
it as BCD) but since the datatype permits blanks, decimal points, dollar
signs, and other miscellany, the performance isn't all that good.


---------------------------
On COBOL datatype transformation as an optimization: was "Is COBOL Boring?"


davidm@Rational.COM (David Moore) writes:
>Has anyone implemented a COBOL compiler which attempts to replace
>expensive data representations by cheaper ones?


Yes. If you carry a decimal data element as a binary element (internally
to whatever program), you HAVE to be sure that the representation is
converted to its 'normal' form for I/O purposes.


Richard Gorton rcg@lpi.liant.com (508) 626-0006
Liant Software Corp. Framingham, MA 01701 USA
Project leader: LPI-BASIC, LPI-FORTRAN, LPI-Pascal, LPI-PL/I
--

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