Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!sjc
From: sjc@mips.UUCP (Steve "The" Correll)
Newsgroups: comp.arch
Subject: Re: Brain-Clogging Decimal (Was: Re: Wirth's challenge (Was Re: RISC))
Message-ID: <1101@quacky.UUCP>
Date: 11 Dec 87 21:03:46 GMT
References: <6901@apple.UUCP> <15782@watmath.waterloo.edu>
Lines: 60

In article <15782@watmath.waterloo.edu>, ccplumb@watmath.waterloo.edu (Colin Plumb) writes:
> The most recent processor family I know of that still faintly supports
> BCD math is the 68000...Is [Cobol support] just hanging on like
> bad smells and MS-DOS, or is it worth anything at all?

As is often the case, if hardware BCD instructions do everything you need
and exactly what you need, you win; if they do almost everything you need
and almost exactly what you need, you might as well not use them.

I just compared the "inner loop" code for a commercial MC68000 implementation
of packed decimal addition, which uses the "ABCD" instruction to add a pair of
digits and propagate the carry, against the MIPS R2000 implementation by
E. Killian and K. Mortensen, which has no BCD support (just XOR).

  MC68000 cost: 	5 * ((precision + 1) div 2)

  R2000 cost:		(precision <= 7) ? 19 : ((precision <= 15 ? 30 : ...))

The R2000, in typical RISC fashion, assumes that packed decimal strings
are word aligned, and manipulates a word at a time, so that it costs 19
instructions whether you have 1 digit or 7.

But it turns out that the work done by the MC68000 "ABCD" instruction,
which adds a pair of packed-decimal digits and propagates the carry for
the next pair, just isn't an important part of the total. Outside the
inner loop, both machines must extract and deposit sign nibbles; both
must compare the signs to see whether you're really doing subtraction;
both must check that they don't create a negative zero result. All of
this happens outside the loop which uses "ABCD", and costs more for the
MC68000.

I arbitrarily picked a case as "reasonable" (both operands positive,
both operands have the same number of digits, odd number of digits, not
all digits zero, and a nonzero result).  Subject to my slightly sloppy
instruction-counting, the cost was:

	digits		MC68000 instructions 	MIPS R2000 instructions
	1 		34			28
	3		39			28
	5		44			28
	7		49			28
	9		54			49
	11		59			49
	...

(I ignored some scaling which the R2000 does inside the 8..15 digit routine 
but the MC68000 does outside its routine.)

If you pick a harder case (the operands aren't known to have the same
number of digits or aren't known to have the decimal point in the same
place; you have to remap the sign nibble because there are multiple
representations; and so on) both implementations become much more expensive;
I didn't have the patience to count instructions to see how they compare.

The moral: if you have an instruction for "add or subtract two packed decimal
strings including encoded signs where the sources and destination may
have disparate lengths with decimal points in different places", it will be a
big help. If you have only "ABCD", you might as well use XOR.

-- 
...decwrl!mips!sjc						Steve Correll