[M3devel] files larger than 2gig
Mika Nystrom
mika at async.caltech.edu
Tue Jun 23 13:20:53 CEST 2009
Jay,
Just a few comments...
I do have some interest in the Modula-3 implementation on the Caltech
Mosaic-C (which has no floating point). M3 has run on this before---I
have an old M3 compiler for it. More in general, M3 is a very nice
language to bring up on new hardware. Requiring the presence of
floating point makes that much more difficult.
EXTENDED really should not be 64 bits. It should be 80 bits or
perhaps (on some archs) 128 bits. On x86 it should definitely be
80 bits, since that is the only precision actually supported by
Intel hardware. Not only would the the answers have more bits of
precision but the hardware would actually run faster in many cases!
(Long double is 80 bits under gcc on my FreeBSDs.)
Finally my understanding is that when M3 was developed, Bill Kahan
sent over one of his grad students to work on the floating point.
That is what all those weird FP interfaces are about. They're not
so much about portability as they are about completeness---from the
point of view of the person developing numerical methods. If you
read Kahan's rants about how FP "should be done" you can see that
the M-3 Float interfaces closely follow the rants. I don't think
they're expected to work on all hardware, only on systems that have
reasonably powerful floating point (IEEE, VAX, System/370?)
Mika
Jay writes:
>--_263ab327-88e7-4d2a-89fb-ad414fed2458_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Every modern system implements IEEE 754 binary floating point in hardware=
>=2C except maybe for the occasional floating point-less embedded ARM or may=
>be MIPS=2C though even still=2C they tend to support "what I expect" in sof=
>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa=
>re environments "SANE").
>
>
>=20
>
>REAL is typically 32 bits.
>
>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck=
>=2C anything more than 31 bits of mantissa is a win.
>
>EXTENDED is the same as LONGREAL.
>
>=20
>
>=20
>
>All you have to do to get an unhandled exception is use the file open gui i=
>n formedit or such and browse to a directory with a large file. It's quite =
>lame.
>
>=20
>
>=20
>
>Granted what Olaf said -- works fine on 64 bit platforms.
>
>=20
>
>=20
>
>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil=
>l be good though.
>
>And then trying to fix NT386 to have a 64bit LONGINT.
>
>=20
>
>=20
>
>I am not convinced that Modula-3 is or ever was superior here=2C in impleme=
>ntation. Yeah=2C they made a bold statement -- here are our portable interf=
>aces=2C but they weren't available on many platforms. At the same time=2C m=
>ost C systems did document various features=2C usually not very portable=2C=
> but perhaps the building blocks of something portable.
>
>It's just that you have/had to read a lot of documentation=2C test it out=
>=2C etc. Someone has to do it as some level. Nothing is free.
>
>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre=
>ads standard/implementation catching up.)
>
>=20
>
>=20
>
>C is getting better here=2C what with #pragma fenv and such.
>
>And again=2C you could always dig into the system-specific details.
>
>=20
>
>=20
>
>The real art that I don't fully understand=2C is how to specify "portable i=
>nterfaces" that you "know" will be viable to implement "everywhere". Just w=
>hat is nearly exactly the same "everywhere" that you know you'll be able to=
> fill in the details later? Maybe it is survey lots of systems??
>
>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L=
>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi=
>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C =
>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) )
>
>=20
>
>=20
>
>That is -- really -- we probably should try to implement all that FloatMode=
> stuff.
>
>=20
>
>
> - Jay
>
>
>=20
>> To: jay.krell at cornell.edu
>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] files larger than 2gig
>>=20
>>=20
>> Also=2C making file handling code depend on the presence of IEEE floating
>> point seems rather odd... As far as I know there is nothing in Modula-3
>> that bans implementing REAL with single precision arithmetic?
>>=20
>> By the way I think it's sad that Modula-3's wonderful floating-point
>> support has attracted so much bit rot. I think it's better than just
>> about any other programming language (except maybe some Fortran
>> dialects?)
>>=20
>> Mika
>>=20
>> Jay writes:
>> >
>> >Hm..I'm not sure.
>> >Integers have certain properties=2C like dividing an integer by an integ=
>er yield
>> >s an integer=2C
>> >that floating point doesn't. Integer division tends toward zero faster t=
>han fl
>> >oating point division.
>> >I can try getting it all to compile with LONGINT maybe instead.
>> >The current behavior is pretty lame.
>> >
>> > - Jay
>> >
>> >----------------------------------------
>> >> From: jay.krell at cornell.edu
>> >> To: m3devel at elegosoft.com
>> >> Date: Mon=2C 22 Jun 2009 12:58:17 +0000
>> >> Subject: [M3devel] files larger than 2gig
>> >>
>> >>
>> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3
>> >>
>> >>
>> >> TYPE
>> >> Status =3D RECORD
>> >> type: Type=3B
>> >> modificationTime: Time.T=3B
>> >> size: INTEGER=3B
>> >> END=3B
>> >>
>> >>
>> >> size: INTEGER causes exceptions when you use the Modula-3 gui
>> >> and browse to a directory with files larger than 2 gig.
>> >>
>> >>
>> >> I suggest size be changed to LONGREAL=2C which generally has a 53 bit =
>mantissa
>> >> (out 64 bits total) and thus can represent integers very much larger t=
>han IN
>> >TEGER.
>> >>
>> >>
>> >> LONGINT is a tempting option but doesn't help on the current NT386 pla=
>tform=2C
>> >> and I think 53 bits will last a very long time.
>> >>
>> >>
>> >> I'm just trying out such a change and I can see it is not source compa=
>tible:
>> >>
>> >>
>> >> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN
>> >> "../src/rw/FileRd.m3"=2C line 140: types are not assignable
>> >> 2 errors encountered
>> >> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN
>> >> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX
>> >> 2 errors encountered
>> >>
>> >>
>> >> Nevertheless I think it should be done=2C probably even for this relea=
>se.
>> >>
>> >>
>> >> - Jay
>
>--_263ab327-88e7-4d2a-89fb-ad414fed2458_
>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'>
>Every modern system implements IEEE 754 binary floating point in hardware=
>=2C except maybe for the occasional floating point-less embedded ARM or may=
>be MIPS=2C though even still=2C they tend to support "what =3BI expect"=
> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754=
> software environments "SANE").<BR><BR>
> =3B<BR>
>REAL is typically =3B32 bits.<BR>
>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck=
>=2C anything more than 31 bits of mantissa is a win.<BR>
>EXTENDED is the same as LONGREAL.<BR>
> =3B<BR>
> =3B<BR>
>All you have to do to get an unhandled exception is use the file open gui i=
>n formedit or such and browse to a directory with a large file. It's quite =
>lame.<BR>
> =3B<BR>
> =3B<BR>
>Granted what Olaf said -- works fine on 64 bit platforms.<BR>
> =3B<BR>
> =3B<BR>
>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou=
>ld still be good though.<BR>
>And then trying to fix NT386 to have a 64bit LONGINT.<BR>
> =3B<BR>
> =3B<BR>
>I am not convinced that Modula-3 is or ever was superior here=2C in impleme=
>ntation. Yeah=2C they made a bold statement -- here are our portable interf=
>aces=2C but they weren't available on many =3Bplatforms. At the same ti=
>me=2C most =3BC systems did document various features=2C usually not ve=
>ry portable=2C but perhaps the building blocks of something portable.<BR>
>It's just that you have/had to read a lot of documentation=2C test it out=
>=2C etc. Someone has to do it as some level. Nothing is free.<BR>
>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre=
>ads standard/implementation catching up.)<BR>
> =3B<BR>
> =3B<BR>
>C is getting better here=2C what with #pragma fenv and such.<BR>
>And again=2C you could always dig into the system-specific details.<BR>
> =3B<BR>
> =3B<BR>
>The real art that I don't fully understand=2C is how to specify "portable i=
>nterfaces" that you "know" will be viable to implement "everywhere". Just w=
>hat is nearly exactly the same "everywhere" that you know you'll be able to=
> fill in the details later? Maybe it is survey lots of systems??<BR>
>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L=
>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi=
>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C =
>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) )<BR>
> =3B<BR>
> =3B<BR>
>That is -- really -- we probably should try to implement all that FloatMode=
> stuff.<BR>
> =3B<BR>
><BR> =3B- Jay<BR>
><BR> =3B<BR>>=3B To: jay.krell at cornell.edu<BR>>=3B Date: Tue=2C 23 =
>Jun 2009 02:54:47 -0700<BR>>=3B From: mika at async.caltech.edu<BR>>=3B CC=
>: m3devel at elegosoft.com<BR>>=3B Subject: Re: [M3devel] files larger than =
>2gig<BR>>=3B <BR>>=3B <BR>>=3B Also=2C making file handling code depe=
>nd on the presence of IEEE floating<BR>>=3B point seems rather odd... As =
>far as I know there is nothing in Modula-3<BR>>=3B that bans implementing=
> REAL with single precision arithmetic?<BR>>=3B <BR>>=3B By the way I t=
>hink it's sad that Modula-3's wonderful floating-point<BR>>=3B support ha=
>s attracted so much bit rot. I think it's better than just<BR>>=3B about =
>any other programming language (except maybe some Fortran<BR>>=3B dialect=
>s?)<BR>>=3B <BR>>=3B Mika<BR>>=3B <BR>>=3B Jay writes:<BR>>=3B &g=
>t=3B<BR>>=3B >=3BHm..I'm not sure.<BR>>=3B >=3BIntegers have certai=
>n properties=2C like dividing an integer by an integer yield<BR>>=3B >=
>=3Bs an integer=2C<BR>>=3B >=3Bthat floating point doesn't. Integer div=
>ision tends toward zero faster than fl<BR>>=3B >=3Boating point divisio=
>n.<BR>>=3B >=3BI can try getting it all to compile with LONGINT maybe i=
>nstead.<BR>>=3B >=3BThe current behavior is pretty lame.<BR>>=3B >=
>=3B<BR>>=3B >=3B - Jay<BR>>=3B >=3B<BR>>=3B >=3B---------------=
>-------------------------<BR>>=3B >=3B>=3B From: jay.krell at cornell.ed=
>u<BR>>=3B >=3B>=3B To: m3devel at elegosoft.com<BR>>=3B >=3B>=3B D=
>ate: Mon=2C 22 Jun 2009 12:58:17 +0000<BR>>=3B >=3B>=3B Subject: [M3d=
>evel] files larger than 2gig<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B<=
>BR>>=3B >=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3<BR=
>>>=3B >=3B>=3B<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B TYPE<BR>=
>>=3B >=3B>=3B Status =3D RECORD<BR>>=3B >=3B>=3B type: Type=3B<=
>BR>>=3B >=3B>=3B modificationTime: Time.T=3B<BR>>=3B >=3B>=3B s=
>ize: INTEGER=3B<BR>>=3B >=3B>=3B END=3B<BR>>=3B >=3B>=3B<BR>>=
>=3B >=3B>=3B<BR>>=3B >=3B>=3B size: INTEGER causes exceptions whe=
>n you use the Modula-3 gui<BR>>=3B >=3B>=3B and browse to a directory=
> with files larger than 2 gig.<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=
>=3B<BR>>=3B >=3B>=3B I suggest size be changed to LONGREAL=2C which g=
>enerally has a 53 bit mantissa<BR>>=3B >=3B>=3B (out 64 bits total) a=
>nd thus can represent integers very much larger than IN<BR>>=3B >=3BTEG=
>ER.<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B LO=
>NGINT is a tempting option but doesn't help on the current NT386 platform=
>=2C<BR>>=3B >=3B>=3B and I think 53 bits will last a very long time.<=
>BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B I'm ju=
>st trying out such a change and I can see it is not source compatible:<BR>&=
>gt=3B >=3B>=3B<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B "../src/rw=
>/FileRd.m3"=2C line 73: incompatible argument types: MIN<BR>>=3B >=3B&g=
>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable<BR>>=3B =
>>=3B>=3B 2 errors encountered<BR>>=3B >=3B>=3B "../src/rw/FileWr.=
>m3"=2C line 87: incompatible argument types: MIN<BR>>=3B >=3B>=3B "..=
>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX<BR>>=3B =
>>=3B>=3B 2 errors encountered<BR>>=3B >=3B>=3B<BR>>=3B >=3B&g=
>t=3B<BR>>=3B >=3B>=3B Nevertheless I think it should be done=2C proba=
>bly even for this release.<BR>>=3B >=3B>=3B<BR>>=3B >=3B>=3B<BR=
>>>=3B >=3B>=3B - Jay<BR></body>
></html>=
>
>--_263ab327-88e7-4d2a-89fb-ad414fed2458_--
More information about the M3devel
mailing list