From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5c884986b9e56484
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-09-22 15:09:16 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!panix!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody
From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Transition from 32 to 64 bit
Date: 22 Sep 1994 10:09:42 -0400
Organization: Courant Institute of Mathematical Sciences
Message-ID: <35s376$63o@gnat.cs.nyu.edu>
References: <1994Sep21.111428.24972@sydney.DIALix.oz.au>
 <1994Sep21.122657.729@sydney.DIALix.oz.au> <35qgno$ivk@gnat.cs.nyu.edu>
 <35qp39$8mk@Starbase.NeoSoft.COM>
NNTP-Posting-Host: gnat.cs.nyu.edu
Date: 1994-09-22T10:09:42-04:00
List-Id: <comp.lang.ada>

There are definitely machines in which double precision float (64 bits) is
much more efficient than single precision float (32 bits). This can arise
from two sources. First, you can have problems with checks (e.g. on the
x86 with 64-bit precision mode set, the checks are free for 64-bit but
require expensive store instructions for 32-bit). The permissions in 
Ada 9X for going outside the range of unconstrained floating-point types
help a lot in eliminating this annoying glitch.

Secondly there are machines where all machine arithmetic is always done in
64-bit (notably the RS6000, but NOT the power PC). On such machines you may
well find that 32-bit fpt is slower.

That's why incidentally the uniformity recommendation is that short_float
should be 32 bits (or whatever makes sense for single precision), long_float
should be 64 bits (or whatever makes sense for double precision), and
float should be whichever of these two types is more efficient in practice.