[M3devel] files larger than 2gig
Jay
jay.krell at cornell.edu
Tue Jun 23 13:27:33 CEST 2009
Mika, floating point is, for better or worse, deep in Modula-3.
I was surprised. The garbage collector uses it.
So you'll need software floating point or somesuch.
Or maybe you can change the code to use fixed point.
Probably not a bad idea.
But also Time.T is LONGREAL.
Though again, maybe that's dubious.
NT has as good time representation.
It is 64bit integers, something like measured in 10,000 nanosecond
units since 1601.
The .NET runtime uses the same unit of precision, but starts at year 0.
Time.T splits up easily into Unix seconds + milli or microseconds.
Of course, all those 32bit second things are broken.
I know the x87 uses 80 bit floating point numbers in hardware,
but there is also SSE/SSE2/SSE3/whatever now, that might be
different, and faster.
You know, they have actual "registers" instead of a register stack.
If you have some floating point intensive code, you might try it.
More info on the Mosiac-C?
I'll search the web.
- Jay
----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 23 Jun 2009 04:20:53 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] files larger than 2gig
>
> 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
>>
>>
>>
>>
>>
>>
>>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").
>> =3B
>>REAL is typically =3B32 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.
>> =3B
>> =3B
>>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.
>> =3B
>> =3B
>>Granted what Olaf said -- works fine on 64 bit platforms.
>> =3B
>> =3B
>>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou=
>>ld still be good though.
>>And then trying to fix NT386 to have a 64bit LONGINT.
>> =3B
>> =3B
>>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.
>>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.)
>> =3B
>> =3B
>>C is getting better here=2C what with #pragma fenv and such.
>>And again=2C you could always dig into the system-specific details.
>> =3B
>> =3B
>>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... :) )
>> =3B
>> =3B
>>That is -- really -- we probably should try to implement all that FloatMode=
>> stuff.
>> =3B
>>
=3B- Jay
>>
=3B
>=3B To: jay.krell at cornell.edu
>=3B Date: Tue=2C 23 =
>>Jun 2009 02:54:47 -0700
>=3B From: mika at async.caltech.edu
>=3B CC=
>>: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] files larger than =
>>2gig
>=3B
>=3B
>=3B Also=2C making file handling code depe=
>>nd on the presence of IEEE floating
>=3B point seems rather odd... As =
>>far as I know there is nothing in Modula-3
>=3B that bans implementing=
>> REAL with single precision arithmetic?
>=3B
>=3B By the way I t=
>>hink it's sad that Modula-3's wonderful floating-point
>=3B support ha=
>>s attracted so much bit rot. I think it's better than just
>=3B about =
>>any other programming language (except maybe some Fortran
>=3B dialect=
>>s?)
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &g=
>>t=3B
>=3B>=3BHm..I'm not sure.
>=3B>=3BIntegers have certai=
>>n properties=2C like dividing an integer by an integer yield
>=3B>=
>>=3Bs an integer=2C
>=3B>=3Bthat floating point doesn't. Integer div=
>>ision tends toward zero faster than fl
>=3B>=3Boating point divisio=
>>n.
>=3B>=3BI can try getting it all to compile with LONGINT maybe i=
>>nstead.
>=3B>=3BThe current behavior is pretty lame.
>=3B>=
>>=3B
>=3B>=3B - Jay
>=3B>=3B
>=3B>=3B---------------=
>>-------------------------
>=3B>=3B>=3B From: jay.krell at cornell.ed=
>>u
>=3B>=3B>=3B To: m3devel at elegosoft.com
>=3B>=3B>=3B D=
>>ate: Mon=2C 22 Jun 2009 12:58:17 +0000
>=3B>=3B>=3B Subject: [M3d=
>>evel] files larger than 2gig
>=3B>=3B>=3B
>=3B>=3B>=3B<=
>>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B
>=3B>=3B>=3B
>=3B>=3B>=3B TYPE
=
>>>=3B>=3B>=3B Status =3D RECORD
>=3B>=3B>=3B type: Type=3B<=
>>BR>>=3B>=3B>=3B modificationTime: Time.T=3B
>=3B>=3B>=3B s=
>>ize: INTEGER=3B
>=3B>=3B>=3B END=3B
>=3B>=3B>=3B
>=
>>=3B>=3B>=3B
>=3B>=3B>=3B size: INTEGER causes exceptions whe=
>>n you use the Modula-3 gui
>=3B>=3B>=3B and browse to a directory=
>> with files larger than 2 gig.
>=3B>=3B>=3B
>=3B>=3B>=
>>=3B
>=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g=
>>enerally has a 53 bit mantissa
>=3B>=3B>=3B (out 64 bits total) a=
>>nd thus can represent integers very much larger than IN
>=3B>=3BTEG=
>>ER.
>=3B>=3B>=3B
>=3B>=3B>=3B
>=3B>=3B>=3B LO=
>>NGINT is a tempting option but doesn't help on the current NT386 platform=
>>=2C
>=3B>=3B>=3B and I think 53 bits will last a very long time.<=
>>BR>>=3B>=3B>=3B
>=3B>=3B>=3B
>=3B>=3B>=3B I'm ju=
>>st trying out such a change and I can see it is not source compatible:
&=
>>gt=3B>=3B>=3B
>=3B>=3B>=3B
>=3B>=3B>=3B "../src/rw=
>>/FileRd.m3"=2C line 73: incompatible argument types: MIN
>=3B>=3B&g=
>>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable
>=3B =
>>>=3B>=3B 2 errors encountered
>=3B>=3B>=3B "../src/rw/FileWr.=
>>m3"=2C line 87: incompatible argument types: MIN
>=3B>=3B>=3B "..=
>>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX
>=3B =
>>>=3B>=3B 2 errors encountered
>=3B>=3B>=3B
>=3B>=3B&g=
>>t=3B
>=3B>=3B>=3B Nevertheless I think it should be done=2C proba=
>>bly even for this release.
>=3B>=3B>=3B
>=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay
>>=
>>
>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_--
More information about the M3devel
mailing list