[M3devel] extended

[mika at async.caltech.edu]

Yes, it is standard practice to write x87 registers to memory and read
them back to guarantee one is not getting "extended" precision by mistake.

Modula-3 does a pretty good job of defining what all the floating formats
are, if you look at the various interfaces for the formats.

I seem to remember the story is that one of Kahan's grad students was
interning at SRC one summer and wrote the interfaces.  

"Among the best in the business."

     Mika

Hendrik Boom writes:
>On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote:
>> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128?
>> And some way to indicate what is available?
>
>Those who do serious numerical analysis for a iving are very careful of=20
>their precisions.
>
>They really care about these datails to an extent most of us mortalls=20
>don't.
>
>I've even had freinds complain about compilers that gave them *more*=20
>precision than they had asked for.
>
>-- hendrik
>
>>=20
>> =20
>> On many/most/but-not-all modern 32bit x86 systems, "long double" is the
>> same as "double". Modula-3 is in agreement with many/most/but-not-all C s=
>ystems.
>> =20
>>=20
>> m3cc might be using x87 instructions on some platforms, at least sometime=
>s.
>> But that doesn't change in-memory extended to other than 64 bits.
>> Just temporary in-register values might be 80 bits.
>> =20
>>=20
>>  - Jay
>>=20
>>=20
>> =20
>> Date: Sun, 31 May 2015 09:06:26 +1000
>> From: peter.mckinna at gmail.com
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] extended
>>=20
>> Hi
>>   While we are on the subject of integer types can we diverge slightly to=
> floating point types. I wonder if anyone can explain why the extended type=
> is treated exactly the same as longreal in the frontend? They have the sam=
>e sizes and ranges and precisions.   As for backends,  at the moment m3cc i=
>s generating 8 byte sse instructions for both types. The llvm is generating=
> 10 byte float instructions as per its x86fp80 type which are a fair bit sl=
>ower at the expense of greater range and precision. However they are not in=
>teroperable with legacy libraries and we should probably change the type to=
> agree with m3cc and the frontend.  It seems that the 8087 80 bit float is =
>being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may=
>be the m3 implementors saw the writing on the wall and and decided to wait =
>for hardware to catch up. Anyway I wonder if its worth considering making e=
>xtended one of the 128 bit floating point types which although emulated in =
>software would at least give us a different type and one which would give s=
>ome applications a huge precision (and range ~10^4090) boost.
>> Peter 		 	   		 =20