🚀 go-pugleaf

    Scott Amspoker comments " ... I have to deal with decimal formats
everyday and I haven't been near a COBOL compiler in 12 years ..."

    Two points 1) perhaps Scott is confusing FORMATS with REPRESENTATION,
as the semantics of COBOL does.  That was my point -- the internal repre-
sentation is irrelevant unless format and representation are for some 
reason coupled by the semantics of the language.  Moreover, you can get
around the problem by careful programming in COBOL. 2) Scott also points
out that there are lots of other languages using (requiring?) floating 
decimal representations.  I guess so, but if COBOL (mis)usage didn't gen-
erate a (spurious) need for hardware decimal arithmetic, then those other 
languages would also learn to do without.

    Michael Meissner comments that COBOL uses overlayed structures, simi-
lar to Pascal variant records, with the implication that it somehow im-
pacts on my argument.  It does not.  Overlays don't necessarily imply
data conversion.  I suspect that if they do, then it is an abuse of the
feature.  All it means is that stored overlayed fields require as much
space as the biggest overlayed field.

    Andrew Klossner gives a contrived (his words) example of a case where
decimal arithmetic is (supposedly) faster than binary.  If his RISC mach-
ine doesn't have binary divide, then it is unlikely to have BCD instruc-
tions either.  Moreover, a smart compiler dealing with the scaling prob-
lem will delay division as late as possible, ie, until it needs to output
a datum, and will keep the internal formats in their scaled form.  Event-
ually, of course, the division will have to be done.

								George
----
Dr. G. W. Gerrity                              Phone: +61 62 68 8180
Dept. of Computer Science                      Fax:   +61 62 68 8581
University College, UNSW                       Email: gwg@cs.adfa.oz.au
ADFA, Northcott Drive                          Telex: ADFADM AA62030
Canberra, ACT 2600            
AUSTRALIA