Xref: utzoo comp.lang.misc:3565 comp.arch:11689
Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!mailrus!husc6!rutgers!mcnc!rti!xyzzy!tiktok!meissner
From: meissner@tiktok.dg.com (Michael Meissner)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Fast conversions, another urban myth?
Message-ID: <1663@xyzzy.UUCP>
Date: 7 Oct 89 23:14:04 GMT
References: <832@dms.UUCP> <688@UALTAVM.BITNET> <1989Sep25.184425.20936@utzoo.uucp> <2261@csadfa.oz>
Sender: usenet@xyzzy.UUCP
Reply-To: meissner@tiktok.UUCP (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 40

In article <2261@csadfa.oz> gwg@csadfa.oz (George Gerrity) writes:
| 
|    But why MUST the conversion be performed, except for the case of final
| output to a screen or printer?  The answer is that it doesn't, but in
| most cases, it is, and the reason can be found in the genesis of COBOL
| and the bias built into the language.  The original COBOL -PRESUMED- that
| the underlying arithmetic was decimal, and this presumption was cast in
| concrete by making DISPLAY usage the default for numeric fields in the
| RECORD DESCRIPTION clause.  Thus, most COBOL programmers as a matter of
| practice will only use the USAGE IS COMPUTATIONAL option when a particu-
| lar computation is clearly a performance bottleneck.  If COMPUTATIONAL
| were the default, and DISPLAY the option, then it would be used only
| where required (for DISPLAYing on a screen or printer), and we would, I
| believe, in many cases see a considerable performance improvement, due
| mainly to the resulting decrease in I/O traffic, but also because of
| the improvement in computational speed.  Moreover, such programs would
| show NO improvement if hardware decimal arithmetic were provided, and
| consequently there would be no incentive for making it available.

Two things.  I seem to recall that some/many COBOL programmers use
overlay schemes and such (level 88 declarations? -- it's been 15 years
since I last programmed in COBOL) that define two or more elements in
a structure sharing the same space.  One element might be numeric with
leading zeros changed into blanks, and another might be alphanumeric.
The programs would then store in one format, and read the other (sort
of the same abuse people make of unions in C, or equivalence in F77).
If fields are overlayed that way, the compiler is pretty much forced
to do the conversions at every step if they use binary.

The second point is, that I've heard about COBOL compilers that will
automatically figure out which variables arithmetic is done on, and if
there is no overlay like I mentioned above, will internally use binary
for the variable (providing the binary form can meet the accuracy
requirements from the declaration).  This is sort of like modern C
compilers which will automatically allocate stack locals to registers,
even if the programmer did not specify register directly.
--
Michael Meissner, Data General.
Uucp:		...!mcnc!rti!xyzzy!meissner		If compiles were much
Internet:	meissner@dg-rtp.DG.COM			faster, when would we
Old Internet:	meissner%dg-rtp.DG.COM@relay.cs.net	have time for netnews?