<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Modula-3 may be good, but it isn't likely unique here.<BR>Apple did a good job probably.<BR>C9x caught up probably.<BR> <BR> <BR> <BR> - Jay<br><br><br> <BR><div>> To: hendrik@topoi.pooq.com<br>> Date: Sat, 30 May 2015 19:18:31 -0700<br>> From: mika@async.caltech.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] extended<br>> <br>> <br>> Yes, it is standard practice to write x87 registers to memory and read<br>> them back to guarantee one is not getting "extended" precision by mistake.<br>> <br>> Modula-3 does a pretty good job of defining what all the floating formats<br>> are, if you look at the various interfaces for the formats.<br>> <br>> I seem to remember the story is that one of Kahan's grad students was<br>> interning at SRC one summer and wrote the interfaces. <br>> <br>> "Among the best in the business."<br>> <br>> Mika<br>> <br>> Hendrik Boom writes:<br>> >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote:<br>> >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128?<br>> >> And some way to indicate what is available?<br>> ><br>> >Those who do serious numerical analysis for a iving are very careful of=20<br>> >their precisions.<br>> ><br>> >They really care about these datails to an extent most of us mortalls=20<br>> >don't.<br>> ><br>> >I've even had freinds complain about compilers that gave them *more*=20<br>> >precision than they had asked for.<br>> ><br>> >-- hendrik<br>> ><br>> >>=20<br>> >> =20<br>> >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the<br>> >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s=<br>> >ystems.<br>> >> =20<br>> >>=20<br>> >> m3cc might be using x87 instructions on some platforms, at least sometime=<br>> >s.<br>> >> But that doesn't change in-memory extended to other than 64 bits.<br>> >> Just temporary in-register values might be 80 bits.<br>> >> =20<br>> >>=20<br>> >> - Jay<br>> >>=20<br>> >>=20<br>> >> =20<br>> >> Date: Sun, 31 May 2015 09:06:26 +1000<br>> >> From: peter.mckinna@gmail.com<br>> >> To: m3devel@elegosoft.com<br>> >> Subject: [M3devel] extended<br>> >>=20<br>> >> Hi<br>> >> While we are on the subject of integer types can we diverge slightly to=<br>> > floating point types. I wonder if anyone can explain why the extended type=<br>> > is treated exactly the same as longreal in the frontend? They have the sam=<br>> >e sizes and ranges and precisions. As for backends, at the moment m3cc i=<br>> >s generating 8 byte sse instructions for both types. The llvm is generating=<br>> > 10 byte float instructions as per its x86fp80 type which are a fair bit sl=<br>> >ower at the expense of greater range and precision. However they are not in=<br>> >teroperable with legacy libraries and we should probably change the type to=<br>> > agree with m3cc and the frontend. It seems that the 8087 80 bit float is =<br>> >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may=<br>> >be the m3 implementors saw the writing on the wall and and decided to wait =<br>> >for hardware to catch up. Anyway I wonder if its worth considering making e=<br>> >xtended one of the 128 bit floating point types which although emulated in =<br>> >software would at least give us a different type and one which would give s=<br>> >ome applications a huge precision (and range ~10^4090) boost.<br>> >> Peter =20<br></div> </div></body>
</html>