Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!udel!burdvax!barry
From: barry@PRC.Unisys.COM (Barry Traylor)
Newsgroups: comp.arch
Subject: Re: Fast conversions, another urban myth?
Summary: It really isn't done THAT often
Keywords: BCD, radix-conversion, COBOL
Message-ID: <11501@burdvax.PRC.Unisys.COM>
Date: 20 Sep 89 04:39:34 GMT
References: <832@dms.UUCP> <11488@burdvax.PRC.Unisys.COM> <27768@winchester.mips.COM>
Followup-To: comp.arch
Organization: Unisys Corporation, Paoli Research Center; Paoli, PA
Lines: 32

In article <27768@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>
>It's good to see this topic discussed a bit more.  Can you share any
>info, like frequencies of operations, i.e., info that isn't
>implementation-secret?

Argh!  I'm not quite sure what the frequency of the  ops are.  We have done
a fair amount of program analysis and backplane probing.  My impression,
talking to the analyzers and probers, is that arithmetic in COBOL is rare
compared to just about everything else.  There seems to be a lot of
character-oriented data movement.  As has already been mentioned in this
forum, a lot of cobol computation is done with non-packed character
strings.  Some thought was given to this in our architecture and the result
is that the conversion from EBCDIC to binary is not much worse than from
BCD to binary.  The compiler generated code looks pretty good too.  Our
binary to BCD ops are actually decimal scaling ops.  This seems to satisfy
the rounding problems (although I'd be hard pressed to answer the "why"
question.  After all, I'm an operating system designer, although I seem to
be spending increasing amounts of time with the hardware folks).

Keeping in mind that ALL of our I/O routines are in the operating system
and that there is virtually no penalty for the context switch into the OS,
we have found with our probes that most COBOL programs spend 80% or more of
their time doing I/O.  That interesting discovery led to some interesting
biasing of the instruction set performance to handling OS code, with very
gratifying overall results.  It also led to the offloading of process
switching and I/O processing code into special purpose processors, also
giving gratifying results.

Barry Traylor
Unisys A Series Engineering
barry@prc.unisys.com