Xref: utzoo comp.arch:11422 comp.lang.misc:3480
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Fast conversions, another urban myth?
Keywords: BCD, radix-conversion, COBOL
Message-ID: <2116@munnari.oz.au>
Date: 16 Sep 89 05:52:52 GMT
References: <832@dms.UUCP>
Sender: news@cs.mu.oz.au
Lines: 56

In article <832@dms.UUCP>, albaugh@dms.UUCP (Mike Albaugh) writes:
[asking about BCD -vs- binary arithmetic]

Burroughs considered this when designing the B6700.  There was a paper
about it, but I'm afraid I've lost the reference.  Their decision was
to concentrate on making binary<->decimal conversion fast (love that
ScaleRightFinal opcode).  There are several points to note:
(1) COBOL requires that 18-digit arithmetic be supported (~60 bits).
    [B6700s could do arithmetic on 78-bit+sign binary integers.]
(2) COBOL doesn't just require arithmetic on "BCD" (alias "packed decimal").
    It requires that arithmetic on text (USAGE DISPLAY) (ASCII or EBCDIC
    or whatever) be supported as well.  So just having packed decimal
    arithmetic doesn't solve everything, legal COBOL programs _still_
    require conversion, so a compiler has to be ready to optimise
    text<->BCD conversion, and if it is, it has most of the machinery
    in place to optimise BCD<->binary conversion.
(3) It is often possible to amortize the cost of a conversion over
    several uses.  For example,
	77 STUPID-EXAMPLE PIC S9(12) USAGE DISPLAY.
	77 STUPID-RESULT PIC S9(12) USAGE DISPLAY.
	...
	MOVE ZEROS TO STUPID-RESULT.
	PERFORM ADD-EXAMPLE VARYING I FROM 1 TO 50.
	...
    ADD-EXAMPLE.
	ADD STUPID-EXAMPLE TO STUPID-RESULT.

    A smart compiler can treat this as

	long long int temp1, temp2;

	temp1 = text_to_binary(STUPID-EXAMPLE, S9_12);
	temp2 = 0;
	for (i = 1; i <= 50; i++) temp2 += temp1;
	binary_to_text(STUPID-RESULT, temp2, S9_12);

>[unit cost is 32-bit binary add = 1] 
> 	BCD add 	2-8
> 	BCD->Binary 	9-30
> 	Binary->BCD 	16(_very_ optimistic)-100

Don't forget your BCD multiplications and your BCD divisions!  If you're
not going to provide them, your compiler still has to hack BCD<->binary.
The conversion estimates here are FAR too high; 9 decimal <-> 30 binary
conversion can be done much faster than that with the aid of a few tables.
(You don't have to convert one digit at a time, you know!)

> add), and this assumes that the 1-cycle multiply needed for the fastest
> convert cannot be used in the BCD add.
What multiply?  BCD<->binary conversions don't need any multiplications
or divisions!

> 	So, where did I go wrong, or should I say, where do I find
> that blazing Binary->BCD routine? :-)

I've got some code somewhere, if I can dig it up I'll post it.