<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Well, I have to take that back.<BR>
I'm reading Rodney's proposal.<BR>
<A href="https://mail.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.txt">https://mail.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.txt</A> <BR>
<BR>
Notable so far:<BR>
He allowed mixed operations. Though mixed MOD he makes LONGINT, which is natural to think and maybe is what we should do, though INTEGER suffices, at least for positive numbers.<BR>
He defines ORD as possibly returning LONGINT. Which breaks my assertion below.<BR>
But he doesn't allow indexing an array by LONGINT.<BR>
Nor sets of LONGINT. I think this is just a tad limiting. You know, I might have a set that contains just a small range of longint. That isn't hard to implement?<BR>
<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Sun, 10 Jan 2010 09:10:52 +0000<BR>Subject: Re: [M3devel] what to do about file sizes being 32bits?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Just a note that the version with ORD and VAL sprinkled everywhere<BR>is compatible with every proposal, *except* removing LONGINT altogether.<BR>It is ugly and tedious, but it does seem to work.<BR> <BR>Can we go with it??<BR> <BR>Maybe "clean it up" afterward, if the compiler allows more?<BR>You basically just search for "LONGINT" or "VAL" across the tree...<BR> <BR> <BR> - Jay<BR> <BR>
<HR id=ecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] what to do about file sizes being 32bits?<BR>Date: Thu, 7 Jan 2010 11:22:37 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I'm working on this..<BR>Attached is what I have so far.<BR>Posix needs work.<BR>Most code continues to not work for files >4GB on 32bit, but it is a start.<BR>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.<BR>Similarly I should be able to compare a LONGINT to 0 directly, instead of 0L.<BR>I'm not sure if the ToProc/FromProc stuff should use INTEGER/CARDINAL or LONGINT.<BR><BR>This gets as far as:<BR><BR>== package C:\dev2\cm3.2\m3-obliq\obliqrt ==<BR><BR> +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -<BR>DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++<BR>--- building in NT386 ---<BR><BR>ignoring ..\src\m3overrides<BR><BR>\cm3\bin\stubgen -v1 -sno ObValue.RemVar -T.M3IMPTAB<BR>m3cfe: (Error) failed to find source or AST for interface 'WordRep'<BR>"\cm3\pkg\m3core\src/word\GenWord.ig[\cm3\pkg\m3core\src/word\Word.i3]": semanti<BR>c analysis suppressed due to import errors<BR>"\cm3\pkg\m3core\src/text\Text.i3", line 16,0: semantic analysis suppressed due<BR>to import errors<BR>m3cfe: (Error) failed to find source or AST for interface 'LongRep'<BR>"\cm3\pkg\m3core\src/word\GenWord.ig[\cm3\pkg\m3core\src/word\Long.i3]": semanti<BR>c analysis suppressed due to import errors<BR>"\cm3\pkg\m3core\src/float/IEEE\Real.i3", line 11,0: semantic analysis suppresse<BR>d due to import errors<BR>"\cm3\pkg\m3core\src/float/IEEE\LongReal.i3", line 10,0: semantic analysis suppr<BR><BR><BR>Which is probably some other problem?<BR><BR><BR> - Jay<BR><BR><BR>
<HR id=ecxecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Thu, 7 Jan 2010 09:47:07 +0000<BR>Subject: Re: [M3devel] what to do about file sizes being 32bits?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I think I can fix everything in the cm3 tree if size is changed to LONGINT.<BR>Including Index(), Length(), Seek().<BR>It involves *many* uses of VAL and ORD, and indeed, it would help if:<BR><BR><BR>INC(longint, integer) was legal, which seems perfectly ok.<BR>longint := integer ditto<BR><BR><BR>Most of the toplevel users will end up throwing in ORD, as they<BR>require files to fit in memory/addressspace.<BR><BR><BR>There is still the matter of this will break too much code out there.<BR><BR><BR> - Jay<BR><BR>
<HR id=ecxecxecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Thu, 7 Jan 2010 06:59:31 +0000<BR>Subject: [M3devel] what to do about file sizes being 32bits?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
File.i3:<BR><BR><BR> Status = RECORD<BR> type: Type;<BR> modificationTime: Time.T;<BR> size: CARDINAL (* oops... *)<BR> END;<BR><BR><BR>What to do?<BR>[0.. higher than 7FFFFFFF] doesn't "just work".<BR> higher than 7FFFFFFFF is not legal on 32bit, unless you put "L" on the end,<BR> which presumably has some relationship to turning it into a LONGINT, which<BR> causes users to fail to compile<BR><BR><BR>LONGINT doesn't "just work"<BR> causes users to fail to compile<BR><BR><BR>stale imports -> compiling ProcessPosixCommon.i3<BR>stale imports -> compiling ProcessPosixCommon.m3<BR>stale imports -> compiling ProcessPosix.m3<BR>stale imports -> compiling FileRd.i3<BR>missing version stamps -> compiling FileRd.m3<BR>"../src/rw/FileRd.m3", line 73: incompatible argument types: MIN<BR>"../src/rw/FileRd.m3", line 140: types are not assignable<BR>2 errors encountered<BR>stale imports -> compiling FileWr.i3<BR>missing version stamps -> compiling FileWr.m3<BR>"../src/rw/FileWr.m3", line 92: incompatible argument types: MIN<BR>"../src/rw/FileWr.m3", line 108: incompatible argument types: MAX<BR>2 errors encountered<BR>st<BR><BR><BR>Change it to LONGINT, fix all the callers, and hope the damage isn't too great outside the cm3 tree?<BR><BR><BR>Change it to LONGINT only for 32bit platforms, somehow author the cm3 tree to work either way,<BR>hope the damage isn't too great outside the cm3 tree?<BR><BR><BR>Change it to LONGREAL so that it works immediately on NT386.<BR> Same issues as above, breaks existing users.<BR><BR><BR>Maybe relax the language some, so that e.g.<BR>a:INTEGER;<BR>b:LONGINT;<BR><BR>b := a;<BR><BR>just works, see if it helps make more code compile with the change?<BR><BR>a := b is problematic of course, but what is wrong with b := a?<BR><BR> - Jay<BR><BR> </body>
</html>