[M3devel] files larger than 2gig

[Jay]

And on that note, here is the status on I386_INTERIX, using a native cm3. :)
 
 
--- building in I386_INTERIX ---
ignoring ../src/m3overrides
new source -> compiling SchedulerPosix.i3
Program received signal SIGSEGV, Segmentation fault.
0x00717e52 in ?? ()
(gdb) bt
#0  0x00717e52 in ?? ()
#1  0x0046e28c in Convert__InternalFromLongFloat ()
#2  0x0046db4d in Convert__FromExtended ()
#3  0x004edb03 in M3Buf__PutFloat ()
#4  0x0062c20a in ReelExpr__GenFPLiteral ()
#5  0x004991bc in Expr__GenFPLiteral ()
#6  0x004b5702 in Formal__AddFPTag ()
#7  0x006f4983 in Value__AddFPTag ()
#8  0x005cc021 in ProcType__FPrinter ()
#9  0x006e801a in TypeFP__Visit_SCC ()
#10 0x006e7daa in TypeFP__FromType ()
#11 0x006e299d in Type__GlobalUID ()
#12 0x006eb0a9 in TypeTbl__Put ()
#13 0x006e2bb5 in Type__Compile ()
#14 0x006e2b1f in Type__CompileAll ()
#15 0x0057192f in Module__Compile ()
#16 0x00527171 in M3Front__DoCompile ()
#17 0x005266a4 in M3Front__Compile ()
#18 0x0042cd62 in Builder__RunM3 ()
#19 0x0042b2a9 in Builder__PushOneM3 ()
#20 0x0042ae8e in Builder__CompileM3 ()
#21 0x00429916 in Builder__CompileOne ()
#22 0x004295b1 in Builder__CompileEverything ()
#23 0x004254ef in Builder__CompileUnits ()
#24 0x00423c0e in Builder__BuildLib ()
#25 0x004f4ac6 in M3Build__DoLibrary ()
#26 0x005dc1cf in QMachine__DoCall ()
#27 0x005db078 in QMachine__Eval ()
#28 0x005e3bad in QMachine ()
#29 0x005e39e5 in QMachine ()
#30 0x004f1296 in M3Build ()
#31 0x004f2da5 in M3Build__DoIncludeDir ()
#32 0x005dc1cf in QMachine__DoCall ()
#33 0x005db078 in QMachine__Eval ()
#34 0x005d9895 in QMachine__Evaluate ()
#35 0x005f1d8e in Quake__Run ()
#36 0x004ef4d6 in M3Build__Run ()
#37 0x0055c172 in Main__DoIt ()
 
  - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: mika at async.caltech.edu
> Date: Tue, 23 Jun 2009 11:27:33 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] files larger than 2gig
>
>
> 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_--