[M3devel] what to do about file sizes being 32bits?

Sun Jan 10 21:52:16 CET 2010

Thanks.  I needed that refresher just to remember what your design space had been.

On 10 Jan 2010, at 15:45, Jay K wrote:

> I've sent various patches.
> I believe the first had no compiler changes and built the whole tree.
> The second had maximum compiler changes (except for FOR) and built the whole tree.
> The third had only assignability and built just libm3.
>   To build the whole tree you'd pretty much add all of the first diff. A few lines
>    could be saved but not much. Assignability doesn't buy very much.
>    I can do that if you want: assignability and build the whole tree.
>    But we do know just about what it looks like.
>  
>  - Jay
> 
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 09:30:00 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> I still want to see the patch...
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office  +1 765 494 6001  +1 765 494 6001 | Mobile  +1 765 427 5484  +1 765 427 5484
> 
> 
> 
> 
> On 10 Jan 2010, at 04:10, Jay K wrote:
> 
> Just a note that the version with ORD and VAL sprinkled everywhere
> is compatible with every proposal, *except* removing LONGINT altogether.
> It is ugly and tedious, but it does seem to work.
>  
> Can we go with it??
>  
> Maybe "clean it up" afterward, if the compiler allows more?
> You basically just search for "LONGINT" or "VAL" across the tree...
>  
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: [M3devel] what to do about file sizes being 32bits?
> Date: Thu, 7 Jan 2010 11:22:37 +0000
> 
> I'm working on this..
> Attached is what I have so far.
> Posix needs work.
> Most code continues to not work for files >4GB on 32bit, but it is a start.
> It seems to me I shouldn't have o use VAL(i, LONGINT) to convert an INTEGER to a LONGINT, as all INTEGER values fit.
> Similarly I should be able to compare a LONGINT to 0 directly, instead of 0L.
> I'm not sure if the ToProc/FromProc stuff should use INTEGER/CARDINAL or LONGINT.
> 
> This gets as far as:
> 
> == package C:\dev2\cm3.2\m3-obliq\obliqrt ==
> 
>  +++ C:\cm3\bin\cm3.exe  -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -
> DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++
> --- building in NT386 ---
> 
> ignoring ..\src\m3overrides
> 
> \cm3\bin\stubgen -v1 -sno ObValue.RemVar   -T.M3IMPTAB
> m3cfe: (Error) failed to find source or AST for interface 'WordRep'
> "\cm3\pkg\m3core\src/word\GenWord.ig[\cm3\pkg\m3core\src/word\Word.i3]": semanti
> c analysis suppressed due to import errors
> "\cm3\pkg\m3core\src/text\Text.i3", line 16,0: semantic analysis suppressed due
> to import errors
> m3cfe: (Error) failed to find source or AST for interface 'LongRep'
> "\cm3\pkg\m3core\src/word\GenWord.ig[\cm3\pkg\m3core\src/word\Long.i3]": semanti
> c analysis suppressed due to import errors
> "\cm3\pkg\m3core\src/float/IEEE\Real.i3", line 11,0: semantic analysis suppresse
> d due to import errors
> "\cm3\pkg\m3core\src/float/IEEE\LongReal.i3", line 10,0: semantic analysis suppr
> 
> 
> Which is probably some other problem?
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 7 Jan 2010 09:47:07 +0000
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> I think I can fix everything in the cm3 tree if size is changed to LONGINT.
> Including Index(), Length(), Seek().
> It involves *many* uses of VAL and ORD, and indeed, it would help if:
> 
> 
> INC(longint, integer) was legal, which seems perfectly ok.
> longint := integer ditto
> 
> 
> Most of the toplevel users will end up throwing in ORD, as they
> require files to fit in memory/addressspace.
> 
> 
> There is still the matter of this will break too much code out there.
> 
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 7 Jan 2010 06:59:31 +0000
> Subject: [M3devel] what to do about file sizes being 32bits?
> 
> File.i3:
> 
> 
>   Status = RECORD
>     type: Type;
>     modificationTime: Time.T;
>     size: CARDINAL (* oops... *)
>   END;
> 
> 
> What to do?
> [0.. higher than 7FFFFFFF] doesn't "just work".
>    higher than 7FFFFFFFF is not legal on 32bit, unless you put "L" on the end,
>    which presumably has some relationship to turning it into a LONGINT, which
>    causes users to fail to compile
> 
> 
> LONGINT doesn't "just work"
>    causes users to fail to compile
> 
> 
> stale imports -> compiling ProcessPosixCommon.i3
> stale imports -> compiling ProcessPosixCommon.m3
> stale imports -> compiling ProcessPosix.m3
> stale imports -> compiling FileRd.i3
> missing version stamps -> compiling FileRd.m3
> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN
> "../src/rw/FileRd.m3", line 140: types are not assignable
> 2 errors encountered
> stale imports -> compiling FileWr.i3
> missing version stamps -> compiling FileWr.m3
> "../src/rw/FileWr.m3", line 92: incompatible argument types: MIN
> "../src/rw/FileWr.m3", line 108: incompatible argument types: MAX
> 2 errors encountered
> st
> 
> 
> Change it to LONGINT, fix all the callers, and hope the damage isn't too great outside the cm3 tree?
> 
> 
> Change it to LONGINT only for 32bit platforms, somehow author the cm3 tree to work either way,
> hope the damage isn't too great outside the cm3 tree?
> 
> 
> Change it to LONGREAL so that it works immediately on NT386.
>   Same issues as above, breaks existing users.
> 
> 
> Maybe relax the language some, so that e.g.
> a:INTEGER;
> b:LONGINT;
> 
> b := a;
> 
> just works, see if it helps make more code compile with the change?
> 
> a := b is problematic of course, but what is wrong with b := a?
> 
>  - Jay
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/b0fbb5ce/attachment-0002.html>