[M3devel] files larger than 2gig

[Jay]

Every modern system implements IEEE 754 binary floating point in hardware, except maybe for the occasional floating point-less embedded ARM or maybe MIPS, though even still, they tend to support "what I expect" in software (heck, just look at Apple's original 6502 and 68000 IEEE 754 software environments "SANE").


 

REAL is typically 32 bits.

LONGREAL is much more useful, 64 bits total, 53 bits of mantissa. Heck, anything more than 31 bits of mantissa is a win.

EXTENDED is the same as LONGREAL.

 

 

All you have to do to get an unhandled exception is use the file open gui in formedit or such and browse to a directory with a large file. It's quite lame.

 

 

Granted what Olaf said -- works fine on 64 bit platforms.

 

 

On later thought, I'm much less keen on LONGREAL here. LONGINT would still be good though.

And then trying to fix NT386 to have a 64bit LONGINT.

 

 

I am not convinced that Modula-3 is or ever was superior here, in implementation. Yeah, they made a bold statement -- here are our portable interfaces, but they weren't available on many platforms. At the same time, most C systems did document various features, usually not very portable, but perhaps the building blocks of something portable.

It's just that you have/had to read a lot of documentation, test it out, etc. Someone has to do it as some level. Nothing is free.

(Similarly, Modula-3 "portability" lately is greatly aided by Posix/pthreads standard/implementation catching up.)

 

 

C is getting better here, what with #pragma fenv and such.

And again, you could always dig into the system-specific details.

 

 

The real art that I don't fully understand, is how to specify "portable interfaces" that you "know" will be viable to implement "everywhere". Just what 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, again, "lots" isn't many any longer. Heck, it's basically just Linux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhile, my list still includes Tru64/Alpha, VMS/Alpha, maybe VMS/IA64, AIX/32, AIX/64, IRIX/32, IRIX/64, etc.. to get running... :) )

 

 

That is -- really -- we probably should try to implement all that FloatMode stuff.

 


 - Jay


 
> To: jay.krell at cornell.edu
> Date: Tue, 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
> 
> 
> Also, 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?
> 
> 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?)
> 
> Mika
> 
> Jay writes:
> >
> >Hm..I'm not sure.
> >Integers have certain properties, like dividing an integer by an integer yield
> >s an integer,
> >that floating point doesn't. Integer division tends toward zero faster than 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, 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 = RECORD
> >> type: Type;
> >> modificationTime: Time.T;
> >> size: INTEGER;
> >> END;
> >>
> >>
> >> 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, which generally has a 53 bit mantissa
> >> (out 64 bits total) and thus can represent integers very much larger than IN
> >TEGER.
> >>
> >>
> >> LONGINT is a tempting option but doesn't help on the current NT386 platform,
> >> 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 compatible:
> >>
> >>
> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN
> >> "../src/rw/FileRd.m3", line 140: types are not assignable
> >> 2 errors encountered
> >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN
> >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX
> >> 2 errors encountered
> >>
> >>
> >> Nevertheless I think it should be done, probably even for this release.
> >>
> >>
> >> - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090623/4ec9742a/attachment-0002.html>