Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mcvax!ukc!eagle!icdoc!cl-jenny!nmm
From: nmm@cl-jenny.UUCP
Newsgroups: comp.lang.c
Subject: Re: Order of evaluation, machine floating point
Message-ID: <692@jenny.cl.cam.ac.uk>
Date: Fri, 27-Mar-87 06:49:41 EST
Article-I.D.: jenny.692
Posted: Fri Mar 27 06:49:41 1987
Date-Received: Sat, 11-Apr-87 05:59:48 EST
References: <4775@brl-adm.ARPA> <7779@utzoo.UUCP> <521@cpocd2.UUCP> <2910@jade.BERKELEY.EDU>
Organization: U of Cambridge Comp Lab, UK
Lines: 31
Summary: IBM 360/370 Floating Point

In article <2910@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes:
> In article <521@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
> >>	#3 may be true for the naive, but makes the pros unhappy.
> >
> >Unless you happen to be working on an IBM 360/370 family machine.  The
> >"single precision" arithmetic is so bad that it has often been called
> >"half precision".  The C insistance on double precision makes a lot of
> >sense in such an environment.
> 
> Even there, the comment about #3 is still true. I know how bad the
> 360/370 single precision floating point is. I also know how
> _expensive_ the double precision stuff is - it takes about four times
> as long to do things.

This has not been true for at least 12 years on the 'mainstream' range
of IBM 360/370 machines.  I have no experience of the 4300 or 9370 series,
or the very small 360/370 machines, but I very much doubt that it is
true even there.

Most of the bigger machines have 64-bit (i.e. 56 bit) hardware, and use
microcode to strip this down for 32-bit arithmetic.  In fact, on the
370/165 32-bit floating point addition was actually 1 cycle SLOWER than
the 64-bit equivalent.

Howard A. Landman is right.  The only real disadvantage of using 64-bit
arithmetic throughout is the extra store needed and, if you are pushing
IBM's store limits, you are going to need the extra precision to get any
meaningful results.

Nick Maclaren
University of Cambridge Computer Laboratory