[M3devel] extended

[Jay K]

Modula-3 may be good, but it isn't likely unique here.
Apple did a good job probably.
C9x caught up probably.
 
 
 
 - Jay


 
> To: hendrik at topoi.pooq.com
> Date: Sat, 30 May 2015 19:18:31 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] extended
> 
> 
> 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150531/7185c74c/attachment-0002.html>