C needs BCD (ANSI People: Please Listen)

[Geoff Kuenning]

Craig Lund writes:

>Why should C provide floating point operations and not provide
>BCD operations ? 

Well, C is a systems programming language.  That produces a couple of effects:

    (1)	In the first place (let's be real about this) systems programmers
	tend to be snobs regarding business software.  Obviously, anyone
	who writes software for ATM's is obviously a wimp, not a real
	programmer.  :-)  (Note:  lest anyone take me too seriously,
	despite the preceding sideways smile, let me note that in my
	experience the majority of the software for a device like an ATM is
	real-time control and communications stuff, not adding columns of
	PICTURE-described numbers).

    (2) Disregarding the first point, there is very little need for a BCD
	data type in *systems* programming (in the traditional sense of
	writing a general-purpose timesharing or batch OS for a large
	computer).  Even floating point is essentially unused in the
	kernel.  (On the Callan [Unisoft] kernel, I once fgrepped for
	'float' and 'double'.  If I remember correctly, "Double" appeared
	once, in a comment about indirect blocks!  'float' appeared only in
	code relating to our hardware floating-point support.)

These are not very good reasons.  I suspect that, if you put BCD support into
the language, a bunch of people would find it useful for stuff that takes more
than 32 bits to represent, but needs more accuracy than floating point.  (An
example would be a time represented in microseconds or milliseconds since
((time_t) 0), rather than in seconds.)

C was invented on the PDP-11, which has no BCD support, but does have floating
point.  At that time, only IBM 360's (not 370's yet!) and similar
business-oriented machines had floating point;  I suspect it never crossed
the original implementors' minds to install BCD.

I vote for discussion of two questions by the net:

    (1) Is it appropriate to put a feature into the language such as BCD,
	which is going to have to be implemented as an inefficient subroutine
	package on at least *some* hardwares.  [hardwares?  is that a word?
	somebody please slap my wrists].  Or should it be a standard
	subroutine package, like strings(3), that is often implemented with
	hardware instructions?
    (2) If we are going to hang BCD onto the language, what is a decent
	syntax, keeping in mind that this is basically an array type like
	strings?

Please redirect flames along the lines of "BCD is not useful" or "BCD is
for wimps" to /dev/null.  If you can't see the need for efficient increased
precision, I'm not really interested in your opinion.  (Flames along the
lines of "it's a wart on the language", etc., are gladly accepted--it's
wintery even here in Southern CA).
-- 
	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff