Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!tribble_acn%uta.csnet@csnet-relay.arpa
From: tribble_acn%uta.csnet@csnet-relay.arpa (David Tribble)
Newsgroups: net.lang.c
Subject: double vs single precision
Message-ID: <1333@brl-tgr.ARPA>
Date: Wed, 8-Jan-86 05:47:32 EST
Article-I.D.: brl-tgr.1333
Posted: Wed Jan  8 05:47:32 1986
Date-Received: Fri, 10-Jan-86 06:45:19 EST
Sender: news@brl-tgr.ARPA
Lines: 41

For the last few weeks there has been on-going discussion of
the merits and drawbacks (demerits?) of the precision the compiler
sees fit to use for statements like-
	float a, b;
	a = a + 1.0;	/* 1 */
	a = a + b;	/* 2 */
One argument that should be mentioned is that some compiler writers
choose the criteria-
	1. keep runtime code small.
	2. stay standard (K&R).
to design their C compiler.  For some machines, especially those that
so not have floating point instructions built in (eg, 808 and 68000)
it makes sense to convert everything to double (with a runtime called
something like $ftod), do the add operation (with a runtime called
$dadd), then convert the result back to a float (with a rtn called $dtof).
What's the advantage, you ask?  Well,-
	1. It keeps runtime code small, because only one floating
	   point routine ($dadd) is required; a single-precision
	   $fadd is not necessary.
	2. It agrees with K&R's definition of 'the usual arithmetic
	   conversions' for doing arithmetic operations.
True, it is more inefficient than calling a single-precision add ($fadd)
and sidestep the converions to and from double-precision. But if your
code uses ANY float-double conversions, your executable code will
require $ftod and $dtof calls, so you are incurring this overhead
already; why incur more overhead with $fadd?

Of course, if you are compiling code for a machine with built-in
floating point rtn's (or if your operating system supplies you
with them), or if you are not concerned with executable runtime code
size, then it would be advantageous to make the compiler smart enough
to choose the precision as it pleases.

My suggestion is to provide ANSI C with the standard pragmas
	#pragma float		/* force single precision */
	#pragma double		/* force double precision */
that the programmer could insert above the arithmetic statement
to specify the precision to use. These pragmas would be ignored
on compilers that choose not to give the programmer a choice.

	David R. Tribble,	Univ. Texas @ Arlington