[M3devel] Integer literals
Tony Hosking
hosking at cs.purdue.edu
Tue Jan 12 19:31:46 CET 2010
Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 12 Jan 2010, at 01:42, Mika Nystrom wrote:
> 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.
That would also be a great project for someone to pick up. ;-) Just trying to encourage participation...
> 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?
I agree that the spec should be neutral on the formats. Just as it is about INTEGER and ADDRESS.
>
> 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_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/e0a38233/attachment-0002.html>
More information about the M3devel
mailing list