Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Endless inSANEity...
Message-ID: <14001@dartvax.Dartmouth.EDU>
Date: 20 Jun 89 05:41:43 GMT
References: <227700009@uxa.cso.uiuc.edu> <2089@husc6.harvard.edu>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 26

In article <2089@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
...
>	In My Humble Opinion, someone Screwed Up when making doubles
>to be 80 bits. Motorola has some moderately reasonable reason for making
>the IEEE Extended type a 12-byte type, to wit, longword alignment.
>I think the SANE interfaces could have been designed this way, but it's
>kind of too late....

     Actually, double is 64 bits.  SANE defines four data types:
Single, double, computational, and extended have 32, 64, 64, and 80
bits respectively.  MPW is the only C compiler I know of which lets
you have all four types at the compiler level.  Aztec maps extended to
double, and from what you say TLSC maps double to extended.  (I am
using the SANE definition of double here.  One could argue that the
way C defines double actually implies IEEE Extended.)  One option is
to use SANE single or double for storage, and let SANE or the 881 do
the calculations in extended.  This is kind of rough in a high-level
language, and there is a speed penalty when using non-extended types.

     Actually, since the first Mac had 128k of RAM, I would say that
Apple had a fairly reasonable reason for storing extended in 80 bits.
Kind of like storing flags in the high bits of master pointers.

Earle R. Horton
"People forget how fast you did a job, but they remember how well you
did it."  Salada Tag Lines