Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: C needs BCD -- why BCD?  Accountants!
Message-ID: <257@rlgvax.UUCP>
Date: Mon, 26-Nov-84 18:38:19 EST
Article-I.D.: rlgvax.257
Posted: Mon Nov 26 18:38:19 1984
Date-Received: Wed, 28-Nov-84 13:13:40 EST
References: <4611@utzoo.UUCP> <222@desint.UUCP> <161@harvard.ARPA> <241@desint.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 23

> >As soon as I/O gets involved, it hardly matters which one is faster
> >computationally. BTW, you can do conversions using shifts and (sorry
> >to say that) BCD arithmetic... but you can write that in assembly
> >language.
> 
> A Fujitsu Eagle transfers data at about 1.8 megabytes per second.  Many
> mainframe disks are even faster.  If you are storing 6-byte (12-digit) BCD
> and are adding two streams, you are transferring 18 bytes per operation.
> Assuming you double-buffer but have only one controller, this is 100K
> operations per second.  You thus have to convert to binary, add, and
> convert back to BCD in approximately 10 microseconds.

Ummmmmmm... isn't there any seek time in there?  Even with IBMish track-at-
a-time reads the heads'll have to move *some*time - and if you're not doing
sequential access of a batch file, but, say, a transaction processing
application they'll be moving more than that.

For that matter, what if the operation involves multiplication or, worse,
division?  BCD *adds* can be done quickly (even 4/8 digits in parallel), but
multiplications and divisions are a major pain.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy