<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
IEEE-754 is extremely long standing.<BR>
<BR>
But it isn't the issue anyway.<BR>
<BR>
The issue is if there exist good candiates for REAL and LONGREAL<BR>
such that LONGREAL can losslessly represent all values of REAL.<BR>
<BR>
C systems are gradually supporting 3 or more floating point formats.<BR>
PowerPC has an optional 128 bit long double.<BR>
<A href="http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html">http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html</A><BR>
<BR>
I wonder if ultimately we should provide "pieces" for people<BR>
to define their own types:<BR>
<BR>
TYPE Int1 = BITS 32, unsigned, integer, trap overflow;<BR>
TYPE Int2 = BITS 64, signed, integer, silent overflow;<BR>
TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;<BR>
TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;<BR>
<BR>
and then provide just a few "canned" "popular" types so that<BR>
a lot of code can interoperate with a lot of code, but if a programmer<BR>
really needs something else, he has a chance of defining it.<BR>
<BR>
Or maybe we can only define what is efficient in hardware, but still<BR>
do so with a syntax like this??<BR>
<BR>
<BR>
- Jay<BR> <BR>> To: jay.krell@cornell.edu<BR>> Date: Mon, 11 Jan 2010 22:42:43 -0800<BR>> From: mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Integer literals<BR>> <BR>> Jay K writes:<BR>> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><BR>> >When do you forsee any non-IEEE 754 floating point environments coming into=<BR>> > existance?<BR>> <BR>> x86 (well, x87) is actually very much IEEE 754. It's almost the reference<BR>> implementation. Normal on x87 is 80-bit extended (all math in the x87 is<BR>> done in extended and then truncated by a store/load pair, if I remember<BR>> correctly). That's not a non-IEEE format. And I find it puzzling that<BR>> we don't expose the x87 native format in Modula-3 as EXTENDED.<BR>> <BR>> One common completely non-IEEE format is Cray floating point.<BR>> <BR>> In any case writing IEEE floating point into the specification of a<BR>> systems language like Modula-3 seems completely wrong to me.<BR>> Who knows what tomorrow will bring?<BR>> <BR>> Mika<BR>> <BR>> ><BR>> >=20<BR>> ><BR>> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=<BR>> >=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=<BR>> >ature of all CPUs=2C at least ones that have any floating point support? Or=<BR>> > any software floating point library?<BR>> ><BR>> >For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>> ><BR>> >Chances are high they only expose 64bit float and nothing else.<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >The precisions and magnitudes of 32bit float and 64bit double are *really o=<BR>> >ld* and in no apparent danger of going away. I think over 25 years and coun=<BR>> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=<BR>> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=<BR>> >e used a different format=2C but the processor had no floating point suppor=<BR>> >t.) I think the only system with different formats is VAX. And Alpha suppor=<BR>> >ts IEEE-754 and VAX. ?<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >I know=2C I know "never say never"=2C but sometimes....?<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> >Certainly there are also 80bit formats on x86 and 68K.<BR>> ><BR>> > Though x86 is moving away from this with SSE/SSE2.<BR>> ><BR>> >And I think 128bit formats on PowerPC.<BR>> ><BR>> >And something beyond 64bits on IA64 (Itanium).<BR>> ><BR>> >=20<BR>> ><BR>> >=20<BR>> ><BR>> > - Jay<BR>> >=20<BR>> >> To: jay.krell@cornell.edu<BR>> >> CC: m3devel@elegosoft.com<BR>> >> Subject: Re: [M3devel] Integer literals=20<BR>> >> Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>> >> From: mika@async.async.caltech.edu<BR>> >>=20<BR>> >> Jay K writes:<BR>> >> ><BR>> >> >>> One thing I've really struggled with over the introduction of LONGINT=<BR>> > is<BR>> >> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=<BR>> >e<BR>> >> >>> literals are really just ways of writing values=3D2C rather than stat=<BR>> >ing<BR>> >> >>> anything about how they should be represented.<BR>> >> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=<BR>> >tinct=3D<BR>> >> >=3D2C<BR>> >> >>> but they really do have incompatible value representations).<BR>> >> >><BR>> >> >> I agree=3D2C the need for distinctly typed literals is much greater fo=<BR>> >r the<BR>> >> >> floating types than the integer types=3D2C because they can't be viewe=<BR>> >d<BR>> >> >> as having overlapping value sets in any reasonable way.<BR>> >> ><BR>> >> >=3D20<BR>> >> >Huh? This seems to me to be directly opposite of the truth.<BR>> >> >LONGREAL is a strict superset of REAL in what it can represent.<BR>> >> >There is *complete* overlap.<BR>> >> >Am I really mistaken here?<BR>> >> >Floating point is indeed very wierd=3D2C but it isn't this wierd.<BR>> >> >Right?<BR>> >> >=3D20<BR>> >> >=3D20<BR>> >> > - Jay<BR>> >>=20<BR>> >> Jay=2C I think if you have hardware that's strictly compliant with IEEE<BR>> >> 754=2C you're right. Or at least there exists an interpretation of the<BR>> >> values that have this property. I alluded earlier to the fact that<BR>> >> Alpha represents single-precision by zeroing out the middle of the<BR>> >> double-precision register (some of the mantissa and some of the exponent)=<BR>> >.<BR>> >>=20<BR>> >> However I'm sure there are systems for which this is not true. Is=20<BR>> >> Modula-3 forbidden from being ported to such machines?<BR>> >>=20<BR>> >> Mika<BR>> > =<BR>> ><BR>> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_<BR>> >Content-Type: text/html; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><html><BR>> ><head><BR>> ><style><!--<BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px=3B<BR>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>> >font-size: 10pt=3B<BR>> >font-family:Verdana<BR>> >}<BR>> >--></style><BR>> ></head><BR>> ><body class=3D'hmmessage'><BR>> >When do you forsee any non-IEEE 754 floating point environments coming into=<BR>> > existance?<BR><BR>> > =3B<BR><BR>> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=<BR>> >=2C Java=2C Modula-3=2C JavaScript=2C etc. =3Bcode in the world not bei=<BR>> >ng a feature of all CPUs=2C at least ones that have any floating point supp=<BR>> >ort? Or any software floating point library?<BR><BR>> >For that matter=2C probably Perl and Python=2C but I'd have to check.<BR><BR>> >Chances are high they only expose 64bit float and nothing else.<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >The precisions and magnitudes of 32bit float and 64bit double are *really o=<BR>> >ld* and in no apparent danger of going away. I think over 25 years and coun=<BR>> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=<BR>> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=<BR>> >e used a different format=2C but the processor had no floating point suppor=<BR>> >t.) I think the only system with different formats is VAX. And Alpha suppor=<BR>> >ts IEEE-754 and VAX. ?<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >I know=2C I know "never say never"=2C but sometimes....?<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> >Certainly there are also 80bit formats on x86 and 68K.<BR><BR>> > =3BThough x86 is moving away from this =3Bwith SSE/SSE2.<BR><BR>> >And I think 128bit formats on PowerPC.<BR><BR>> >And something beyond 64bits on IA64 (Itanium).<BR><BR>> > =3B<BR><BR>> > =3B<BR><BR>> > =3B- Jay<BR> =3B<BR>>=3B To: jay.krell@cornell.edu<BR>>=3B CC:=<BR>> > m3devel@elegosoft.com<BR>>=3B Subject: Re: [M3devel] Integer literals <B=<BR>> >R>>=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>>=3B From: mika@async=<BR>> >.async.caltech.edu<BR>>=3B <BR>>=3B Jay K writes:<BR>>=3B >=3B<BR>&=<BR>> >gt=3B >=3B>=3B>=3B One thing I've really struggled with over the intr=<BR>> >oduction of LONGINT is<BR>>=3B >=3B>=3B>=3B the need for distinct l=<BR>> >iteral forms. This strikes me as odd=3D2C since<BR>>=3B >=3B>=3B>=<BR>> >=3B literals are really just ways of writing values=3D2C rather than statin=<BR>> >g<BR>>=3B >=3B>=3B>=3B anything about how they should be represente=<BR>> >d.<BR>>=3B >=3B>=3B>=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=<BR>> >ENDED literals are all distinct=3D<BR>>=3B >=3B=3D2C<BR>>=3B >=3B&g=<BR>> >t=3B>=3B but they really do have incompatible value representations).<BR>=<BR>> >>=3B >=3B>=3B<BR>>=3B >=3B>=3B I agree=3D2C the need for distin=<BR>> >ctly typed literals is much greater for the<BR>>=3B >=3B>=3B floating=<BR>> > types than the integer types=3D2C because they can't be viewed<BR>>=3B &=<BR>> >gt=3B>=3B as having overlapping value sets in any reasonable way.<BR>>=<BR>> >=3B >=3B<BR>>=3B >=3B=3D20<BR>>=3B >=3BHuh? This seems to me to b=<BR>> >e directly opposite of the truth.<BR>>=3B >=3BLONGREAL is a strict supe=<BR>> >rset of REAL in what it can represent.<BR>>=3B >=3BThere is *complete* =<BR>> >overlap.<BR>>=3B >=3BAm I really mistaken here?<BR>>=3B >=3BFloatin=<BR>> >g point is indeed very wierd=3D2C but it isn't this wierd.<BR>>=3B >=3B=<BR>> >Right?<BR>>=3B >=3B=3D20<BR>>=3B >=3B=3D20<BR>>=3B >=3B - Jay<B=<BR>> >R>>=3B <BR>>=3B Jay=2C I think if you have hardware that's strictly com=<BR>> >pliant with IEEE<BR>>=3B 754=2C you're right. Or at least there exists an=<BR>> > interpretation of the<BR>>=3B values that have this property. I alluded =<BR>> >earlier to the fact that<BR>>=3B Alpha represents single-precision by zer=<BR>> >oing out the middle of the<BR>>=3B double-precision register (some of the=<BR>> > mantissa and some of the exponent).<BR>>=3B <BR>>=3B However I'm sure =<BR>> >there are systems for which this is not true. Is <BR>>=3B Modula-3 forbid=<BR>> >den from being ported to such machines?<BR>>=3B <BR>>=3B Mika<BR> =<BR>> > </body><BR>> ></html>=<BR>> ><BR>> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--<BR> </body>
</html>