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

Sun Jan 10 21:53:12 CET 2010

(Actually the first didn't build quite the whole tree, but very nearly;

a small number of packages remained to be fixed).

I avoided hijacking a different thread, so I'll say it here instead:

  I'm surprised we are ok with the runtime checks of INTEGER := LONGINT
   but not the very natural INTEGER + LONGINT => LONGINT.

   You first find what all the expression terms are assignable to, do the math

    there, and that is the result. You can even adopt that simple rule for MOD,

    though MOD is a "very reducing" function and it is statically knowable

    I believe that widening isn't really needed.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 20:45:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?

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    +1 765 494 6001  +1 765 494 6001  | Mobile   +1 765 427 5484  +1 765 427 5484    +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/708d2874/attachment-0002.html>