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