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