[M3devel] Integer literals
Jay K
jay.krell at cornell.edu
Tue Jan 12 07:55:27 CET 2010
IEEE-754 is extremely long standing.
But it isn't the issue anyway.
The issue is if there exist good candiates for REAL and LONGREAL
such that LONGREAL can losslessly represent all values of REAL.
C systems are gradually supporting 3 or more floating point formats.
PowerPC has an optional 128 bit long double.
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html
I wonder if ultimately we should provide "pieces" for people
to define their own types:
TYPE Int1 = BITS 32, unsigned, integer, trap overflow;
TYPE Int2 = BITS 64, signed, integer, silent overflow;
TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;
TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;
and then provide just a few "canned" "popular" types so that
a lot of code can interoperate with a lot of code, but if a programmer
really needs something else, he has a chance of defining it.
Or maybe we can only define what is efficient in hardware, but still
do so with a syntax like this??
- Jay
> To: jay.krell at cornell.edu
> Date: Mon, 11 Jan 2010 22:42:43 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
>
> 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_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/60619ac5/attachment-0002.html>
More information about the M3devel
mailing list