Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.14 $; site umn-cs.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!stolaf!mmm!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: Float Double Parameters
Message-ID: <1700006@umn-cs.UUCP>
Date: Mon, 7-Apr-86 23:34:00 EST
Article-I.D.: umn-cs.1700006
Posted: Mon Apr  7 23:34:00 1986
Date-Received: Fri, 11-Apr-86 01:29:42 EST
References: <5216@alice.UUCP>
Lines: 39
Nf-ID: #R:alice:-521600:umn-cs:1700006:000:1838
Nf-From: umn-cs!herndon    Apr  7 22:34:00 1986


  [Spare bits.]

  Oy!  Floats & Doubles have certainly caused their share of
troubles in both C & Unix.  I believe that the original reason
for doing all arithmetic in double precision originated with
the PDP-11, which had some mis-features in its floating point
processor.  It seems that on the PDP-11 (/45 certainly, and
I believe the /70 and others too) there was no way to write
the floating point processor status word.  Thus if more than
two processes were using the FPP, one of which was generating
overflows and the other of which was generating underflows,
the two processes would get each other's errors after context
switches.  I also recall that there was an instruction (SETD)
which caused all FPP instructions to be performed in double
precision, and that there was no way (i'm not sure here) to
query the FPP to see whether it was in double or single precision
mode.  Since double precision arithmetic was not much slower
than single, and floating point wasn't used that much anyway, it
was decided that all arithmetic would be done in double precision,
and the kernel would assume that all processes ran in double
precision mode.  During context switches, the kernel would save
all FPP registers, reload them for the new process, and leave
the FPP in double mode.  (Screwing any process which wanted to
use single precision arithmetic.)
  As far as I know (admittedly, not far) there is no longer any
good reason for the current schizophrenia about single/double
precision arithmetic, other than historical precedent.  Does
anyone know any other good reasons, such as design faults in
the VAX FPA?

				Robert Herndon
				...!ihnp4!umn-cs!herndon
				herndon@umn-cs
				herndon.umn-cs@csnet-relay.ARPA
				Dept. of Computer Science,
				Univ. of Minnesota,
				136 Lind Hall, 207 Church St. SE
				Minneapolis, MN  55455