From hosking at cs.purdue.edu  Fri Jan  1 21:30:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 15:30:42 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
Message-ID: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>

What does -C do?

On 29 Dec 2009, at 12:47, Olaf Wagner wrote:

> Any ideas? Interaction problem between threads and select?
> 
> Olaf
> 
> ----- Forwarded message from bugs at elego.de -----
>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>    From: CM3 <bugs at elego.de>
> Reply-To: CM3 <bugs at elego.de>
> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>      To: @MISSING_DOMAIN
> 
> #1080: CVSUPD server hangs if used with -C option
> -----------------------------+----------------------------------------------
>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>      Type:  sw-bug          |           Status:  new
>  Priority:  high            |        Milestone:
> Component:  sys             |          Version:  5.8-RC3
>  Severity:  critical        |         Keywords:
>   Relnote:                  |     Confidential:  no
>       Org:  Collabnet       |   Estimatedhours:  0
>     Hours:  0               |         Billable:  0
> Totalhours:  0               |
> -----------------------------+----------------------------------------------
> Htr:
> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
> 
> Start the cvsupd server with -C option
> 
> ./cvsupd -b /data/cvsupd -C 2
> 
> Try cvsup client to connect to the sever
> 
> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> 
> The client connection will hang and after sometime we will get "Inactivity timeout"
> 
> 
> Fix:
> 
> 
> 
> Env:
> 
> 
> -----------------------------+----------------------------------------------
> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
> cvsup installed.
> 
> The server starts find and there was no issues if I start the server
> without -C option.
> 
> Starting cvsupd server without -C option
> 
> $ ./cvsupd -b /u2/site/data/cvsupd
> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> 
> Then I did a client request as below
> 
> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> Parsing supfile "/tmp/cvsupd.cfg"
> Connecting to myserver.com
> Connected to myserver.com
> Rejected by server: Access denied
> Will retry at 21:37:09
> 
> So the request was successful and I get a valid error message at the
> client.
> 
> But when I start the server with -C option like the one as below, requests
> from client are hanging and eventually getting "Inactivity timeout" after
> sometime.
> 
> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> 
> When ever a new client connection was made, this daemon clones another
> cvsupd process and it also hangs. So none of the client request were
> processed.
> 
> Strace of the main cvsupd server process, when a new client request was
> fired.
> 
> -----------------------------------
> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> gettimeofday({1262103026, 146476}, NULL) = 0
> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> _llseek(7, 0, [0], SEEK_CUR)            = 0
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> close(7)                                = 0
> gettimeofday({1262103026, 147481}, NULL) = 0
> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
> such file or directory)
> write(5, "\0", 1)                       = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0xb7f43708) = 6543
> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> close(6)                                = 0
> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
> unavailable)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> 
> ------------------------------------
> 
> gdb backtrace of the main cvsupd server process
> 
> ------------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> ../src/unix/Common/UnixC.c:301
> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
> M3_A4bqCj_timeout=0xbfed9410) at
> ../src/thread/PTHREAD/ThreadPThread.m3:900
> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> ../src/thread/PTHREAD/ThreadPThread.m3:854
> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:153
> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> ------------------------------------------------
> 
> 
> strace of the cloned cvsupd process
> 
> -----------------------------------
> 
> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> 
> -----------------------------------
> 
> gdb backtrace of the cloned cvsupd process
> 
> -----------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/libpthread.so.0
> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> ../src/FSServer.m3:231
> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:227
> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> 
> -------------------------------------------
> 
> So it looks like both the main and cloned cvsupd processes were waiting
> for a response from the kernel call "__kernel_vsyscall ()". Under what
> condition will this happen? Am I doing something wrong here?
> 
> -- 
> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> CM3 <http://projects.elego.de/cm3>
> Critical Mass Modula3 Compiler
> 
> 
> ----- End forwarded message -----
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/4d7ee17c/attachment.html>

From jay.krell at cornell.edu  Fri Jan  1 23:56:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 22:56:00 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
Message-ID: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>


I can understand that the name on the left isn't in scope "yet" on the right,
but what is the algorithm for anyone else using IMPORT?


import foo;
import foo(bar);
import foo(bar) as foobar;
import foo(bar).T as fooT;


I doubt all but the first of these are legal, but I also don't think they are very far fetched
in terms of being reasonable constructs and not difficult to implement.


And I'm not sure the presence of the '(' is enough disambiguation for a quick human reader
or a pleasantly simply enough implementation, but maybe.


All that is to say, I don't think disallowing interface foo = foo(bar) is so bad.


 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 1 Jan 2010 14:43:36 -0500
To: jkrell at elego.de
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3



That's a bug in m3tk scope management.  Probably needs a ticket in the bugs database...


On 30 Dec 2009, at 15:40, Jay Krell wrote:CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/12/30 15:40:06

Modified files:
	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3 
	                              m3makefile 
Added files:
	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg 
Removed files:
	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg 

Log message:
	go back to GenWord
	the other front end (Olivetti m3-tk)
	doesn't understand
	INTERFACE Word = Word(WordRep) END Word.
	but it does't understand
	INTERFACE Word = GenWord(WordRep) END Word.

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

From mika at async.async.caltech.edu  Sat Jan  2 00:02:23 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 01 Jan 2010 15:02:23 -0800
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl> 
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
Message-ID: <20100101230223.355441A2080@async.async.caltech.edu>

Jay K writes:
...
>
>import foo=3B
>import foo(bar)=3B
>import foo(bar) as foobar=3B
>import foo(bar).T as fooT=3B

Modula-3 doesn't work like that.

You have to say

INTERFACE X = G(Y) ...

IMPORT X

You can't import "G(Y)" directly.  Saves having to worry too much about
name mangling.

Having a generic interface and a normal one with the same name is a common
pattern for me, at least.

You often have a single supertype and then many subtypes that are related
to that supertype by being extended with, say, a field of an arbitrary type.

Then you get...

INTERFACE Stuff; TYPE T ... END Stuff.

GENERIC INTERFACE Stuff(Specializing);
IMPORT Stuff;
TYPE T = Stuff.T OBJECT special : Specializing.T END;
END Stuff.

INTERFACE SpecialStuff = Stuff(Special)

Very convenient to use the same name at the top level, I think.

    Mika

>
>
>I doubt all but the first of these are legal=2C but I also don't think they=
> are very far fetched
>in terms of being reasonable constructs and not difficult to implement.
>
>
>And I'm not sure the presence of the '(' is enough disambiguation for a qui=
>ck human reader
>or a pleasantly simply enough implementation=2C but maybe.
>
>
>All that is to say=2C I don't think disallowing interface foo =3D foo(bar) =
>is so bad.
>
>
> - Jay
>
>From: hosking at cs.purdue.edu
>Date: Fri=2C 1 Jan 2010 14:43:36 -0500
>To: jkrell at elego.de
>CC: m3commit at elegosoft.com
>Subject: Re: [M3commit] CVS Update: cm3
>
>
>
>That's a bug in m3tk scope management.  Probably needs a ticket in the bugs=
> database...
>
>
>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:CVSROOT:	/usr/cvs
>Changes by:	jkrell at birch.	09/12/30 15:40:06
>
>Modified files:
>	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3=20
>	                              m3makefile=20
>Added files:
>	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg=20
>Removed files:
>	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg=20
>
>Log message:
>	go back to GenWord
>	the other front end (Olivetti m3-tk)
>	doesn't understand
>	INTERFACE Word =3D Word(WordRep) END Word.
>	but it does't understand
>	INTERFACE Word =3D GenWord(WordRep) END Word.
>
> 		 	   		  =
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I can understand that the name on the left isn't in scope "yet" on the righ=
>t=2C<br>but what is the algorithm for anyone else using IMPORT?<br><br><br>=
>import foo=3B<br>import foo(bar)=3B<br>import foo(bar) as foobar=3B<br>impo=
>rt foo(bar).T as fooT=3B<br><br><br>I doubt all but the first of these are =
>legal=2C but I also don't think they are very far fetched<br>in terms of be=
>ing reasonable constructs and not difficult to implement.<br><br><br>And I'=
>m not sure the presence of the '(' is enough disambiguation for a quick hum=
>an reader<br>or a pleasantly simply enough implementation=2C but maybe.<br>=
><br><br>All that is to say=2C I don't think disallowing interface foo =3D f=
>oo(bar) is so bad.<br><br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">=
>From: hosking at cs.purdue.edu<br>Date: Fri=2C 1 Jan 2010 14:43:36 -0500<br>To=
>: jkrell at elego.de<br>CC: m3commit at elegosoft.com<br>Subject: Re: [M3commit] =
>CVS Update: cm3<br><br>
>
><div><span class=3D"ecxApple-style-span" style=3D"border-collapse: separate=
>=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B=
> font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette=
>r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf=
>orm: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ec=
>xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=
>=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><div style=3D"word-wrap: break-wor=
>d=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: separat=
>e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=
>=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le=
>tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra=
>nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D=
>"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C=
> 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span=
>" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam=
>ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no=
>rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma=
>l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor=
>d-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-coll=
>apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font=
>-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n=
>ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=
>=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"><s=
>pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col=
>or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s=
>tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci=
>ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no=
>ne=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-=
>style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=
>=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font=
>-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h=
>eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n=
>ormal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D=
>"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve=
>tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo=
>nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-=
>indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:=
> 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: sepa=
>rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p=
>x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l=
>etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr=
>ansform: none=3B white-space: normal=3B word-spacing: 0px=3B"><div><span cl=
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B"><font class=3D"e=
>cxApple-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">That's a bug in =
>m3tk scope management. &nbsp=3BProbably needs a ticket in the bugs database=
>...</font></span></div></span></span></span></span></span></span></span></s=
>pan></div></span></span>
></div>
><br><div><div>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:</div><br class=
>=3D"ecxApple-interchange-newline"><blockquote><div>CVSROOT:<span class=3D"e=
>cxApple-tab-span" style=3D"white-space: pre=3B">	</span>/usr/cvs<br>Changes=
> by:<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span=
>>jkrell at birch.<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>09/12/30 15:40:06<br><br>Modified files:<br><span class=3D"ecx=
>Apple-tab-span" style=3D"white-space: pre=3B">	</span>cm3/m3-libs/m3core/sr=
>c/word/: Long.i3 Long.m3 Word.i3 Word.m3 <br><span class=3D"ecxApple-tab-sp=
>an" style=3D"white-space: pre=3B">	</span> &nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
>sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
>=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3Bm3makefile <br>Added fil=
>es:<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</s=
>pan>cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg <br>Removed files:<=
>br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>=
>cm3/m3-libs/m3core/src/word/: Word.ig Word.mg <br><br>Log message:<br><span=
> class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>go back =
>to GenWord<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>the other front end (Olivetti m3-tk)<br><span class=3D"ecxAppl=
>e-tab-span" style=3D"white-space: pre=3B">	</span>doesn't understand<br><sp=
>an class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERF=
>ACE Word =3D Word(WordRep) END Word.<br><span class=3D"ecxApple-tab-span" s=
>tyle=3D"white-space: pre=3B">	</span>but it does't understand<br><span clas=
>s=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERFACE Wor=
>d =3D GenWord(WordRep) END Word.<br></div></blockquote></div><br> 		 	   		=
>  </body>
></html>=
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_--


From jay.krell at cornell.edu  Sat Jan  2 00:05:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 23:05:44 +0000
Subject: [M3devel] C generating back end
Message-ID: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>


Fyi I finally looked at the 2.x implementation and the outputing of
C was implemented fairly directly at the m3front layer.
There wasn't the "M3CG" stuff.


Thus, the "easiest" way to get back such functionality would
probably be to "interleave" the old code and the new code within m3front.


The "cleaner" way is probably to implement a new M3CG though and
leave m3front unchanged.


I still think generating portable C a great way to achieve portability.
Better yet maybe, generate C++ and use its exception handling feature.
(ok, maybe generate both, in case some systems lack C++ support)


I realize there are several ways to view this though.

  gcc backend provides enough portability 
     imagine IA64_NT though. or Plan9. or even OpenBSD 
      or Darwin where there are long standing forks 
      (The OpenBSD patches are small and we carry/apply them.
      The Apple changes I think are mainly in the frontends
      which I think is how we get by.) 

     For efficient exception handling we should be able to use libunwind on most targets. 

  llvm would provide good portability and maybe other benefits like perf 
     less reach than gcc but hits the major platforms 
     difficult for me to get started with sorry 

  integrated backend could/should be ported around and is fast 
     a lot of work 
     I think the first steps here are to learn about mach-o and elf file formats
       as part of ports for other x86 targets. I've started a macho-dumper. 

  burg or others 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/98af7028/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  2 00:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 18:42:34 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
Message-ID: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>

On 1 Jan 2010, at 18:05, Jay K wrote:

> Fyi I finally looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such functionality would
> probably be to "interleave" the old code and the new code within m3front.

I'd like to avoid that sort of interleaving.

> The "cleaner" way is probably to implement a new M3CG though and
> leave m3front unchanged.

This is a much better plan.

> I still think generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception handling feature.
> (ok, maybe generate both, in case some systems lack C++ support)

We can use the gcc-backend exception handling support if anyone was prepared to work on it.

>  realize there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9. or even OpenBSD 
>       or Darwin where there are long standing forks 
>       (The OpenBSD patches are small and we carry/apply them.
>       The Apple changes I think are mainly in the frontends
>       which I think is how we get by.) 
> 
>      For efficient exception handling we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other benefits like perf 
>      less reach than gcc but hits the major platforms 
>      difficult for me to get started with sorry 
> 
>   integrated backend could/should be ported around and is fast 
>      a lot of work 
>      I think the first steps here are to learn about mach-o and elf file formats
>        as part of ports for other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 

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

From dabenavidesd at yahoo.es  Sat Jan  2 02:27:55 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 2 Jan 2010 01:27:55 +0000 (GMT)
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <694151.75147.qm@web23608.mail.ird.yahoo.com>

Hi all:
Olivetti had the the original development environment written with a C generating backend written in C for different operating system machines, they intended to realease it fully (probably it was) but performance showed was inferior to that of SRC environment at the time 2.x (Modula-3 to C written in Modula-3), which led to include Olivetti front end part as a library front end being part of the SRC distribution, later to deploy Network Objects high level intermediate code network logical layer.
Having a C backend this days wouldn't make sense if it was actually developed at some point, and up to a Professor remembers RMS wanted this to be donated to FSF so it could led to some sort to GPLed system, but there wasn't such a donation or haven't been done yet and it probably was related to the performance comparison (in the time of Olivetti and SRC 2.x systems) reason mentioned by Mick Jordan (see http://compilers.iecc.com/comparch/article/90-08-046 ) and later to M3CG (due SRC Modula-2+ system low level intermediate code) interface which has proven to be a good compromise between portability and performance.
If we could prove that Olivetti backend could be a plus in terms of M3 performance and portability to get it back and compare its actual performance with nowadays M3CG backend performance then this would have a point

Hope it helps, thanks in advance 
 

--- El vie, 1/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] C generating back end
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 1 de enero, 2010 18:42
> On 1 Jan
> 2010, at 18:05, Jay K
> wrote:
> Fyi I finally
> looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such
> functionality would
> probably be to "interleave" the old code and the
> new code within m3front.
> 
> I'd like to avoid that sort of
> interleaving.
> The
> "cleaner" way is probably to implement a new M3CG
> though and
> leave m3front unchanged.
> 
> This is a much better plan.
> I still think
> generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception
> handling feature.
> (ok, maybe generate both, in case some systems lack C++
> support)
> 
> We can use the gcc-backend exception handling
> support if anyone was prepared to work on it.
>  realize
> there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9.
> or even OpenBSD 
>       or Darwin where there are
> long standing forks 
>       (The OpenBSD patches are
> small and we carry/apply them.
>       The Apple changes I think
> are mainly in the frontends
>       which I think is how we get
> by.) 
> 
>      For efficient exception handling
> we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other
> benefits like perf 
>      less reach than gcc but hits the
> major platforms 
>      difficult for me to get started
> with sorry 
> 
>   integrated backend could/should be ported around and
> is fast 
>      a lot of work 
>      I think the first steps here are
> to learn about mach-o and elf file formats
>        as part of ports for
> other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 
> 
> 


      


From wagner at elegosoft.com  Sat Jan  2 11:54:06 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 02 Jan 2010 11:54:06 +0100
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with	-C
	option
In-Reply-To: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
Message-ID: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> What does -C do?

Make it a server process. From the manual:

      -C maxClients
                  Limits the number of simultaneous clients to maxClients.
                  Clients beyond the specified maximum are politely refused
                  service.

                  If this option is not specified, cvsupd serves one client in
                  the foreground and then exits.

Olaf

> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>
>> Any ideas? Interaction problem between threads and select?
>>
>> Olaf
>>
>> ----- Forwarded message from bugs at elego.de -----
>>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>>    From: CM3 <bugs at elego.de>
>> Reply-To: CM3 <bugs at elego.de>
>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>      To: @MISSING_DOMAIN
>>
>> #1080: CVSUPD server hangs if used with -C option
>> -----------------------------+----------------------------------------------
>>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>>      Type:  sw-bug          |           Status:  new
>>  Priority:  high            |        Milestone:
>> Component:  sys             |          Version:  5.8-RC3
>>  Severity:  critical        |         Keywords:
>>   Relnote:                  |     Confidential:  no
>>       Org:  Collabnet       |   Estimatedhours:  0
>>     Hours:  0               |         Billable:  0
>> Totalhours:  0               |
>> -----------------------------+----------------------------------------------
>> Htr:
>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
>>
>> Start the cvsupd server with -C option
>>
>> ./cvsupd -b /data/cvsupd -C 2
>>
>> Try cvsup client to connect to the sever
>>
>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>
>> The client connection will hang and after sometime we will get   
>> "Inactivity timeout"
>>
>>
>> Fix:
>>
>>
>>
>> Env:
>>
>>
>> -----------------------------+----------------------------------------------
>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
>> cvsup installed.
>>
>> The server starts find and there was no issues if I start the server
>> without -C option.
>>
>> Starting cvsupd server without -C option
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd
>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>
>> Then I did a client request as below
>>
>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>> Parsing supfile "/tmp/cvsupd.cfg"
>> Connecting to myserver.com
>> Connected to myserver.com
>> Rejected by server: Access denied
>> Will retry at 21:37:09
>>
>> So the request was successful and I get a valid error message at the
>> client.
>>
>> But when I start the server with -C option like the one as below, requests
>> from client are hanging and eventually getting "Inactivity timeout" after
>> sometime.
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>
>> When ever a new client connection was made, this daemon clones another
>> cvsupd process and it also hangs. So none of the client request were
>> processed.
>>
>> Strace of the main cvsupd server process, when a new client request was
>> fired.
>>
>> -----------------------------------
>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>> gettimeofday({1262103026, 146476}, NULL) = 0
>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> close(7)                                = 0
>> gettimeofday({1262103026, 147481}, NULL) = 0
>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
>> such file or directory)
>> write(5, "\0", 1)                       = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> clone(child_stack=0,
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> child_tidptr=0xb7f43708) = 6543
>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> close(6)                                = 0
>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
>> unavailable)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>
>> ------------------------------------
>>
>> gdb backtrace of the main cvsupd server process
>>
>> ------------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>> ../src/unix/Common/UnixC.c:301
>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
>> M3_A4bqCj_timeout=0xbfed9410) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:153
>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>> ------------------------------------------------
>>
>>
>> strace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>
>> -----------------------------------
>>
>> gdb backtrace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>> /lib/libpthread.so.0
>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>> ../src/FSServer.m3:231
>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:227
>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>>
>> -------------------------------------------
>>
>> So it looks like both the main and cloned cvsupd processes were waiting
>> for a response from the kernel call "__kernel_vsyscall ()". Under what
>> condition will this happen? Am I doing something wrong here?
>>
>> --
>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>> CM3 <http://projects.elego.de/cm3>
>> Critical Mass Modula3 Compiler
>>
>>
>> ----- End forwarded message -----
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Sat Jan  2 18:20:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:20:04 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F8044.2080403@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 
> Having a generic interface and a normal one with the same name is a common
> pattern for me, at least.
> 
> You often have a single supertype and then many subtypes that are related
> to that supertype by being extended with, say, a field of an arbitrary type.
> 
> Then you get...
> 
> INTERFACE Stuff; TYPE T ... END Stuff.
> 
> GENERIC INTERFACE Stuff(Specializing);
> IMPORT Stuff;
> TYPE T = Stuff.T OBJECT special : Specializing.T END;
> END Stuff.
> 
> INTERFACE SpecialStuff = Stuff(Special)
> 
> Very convenient to use the same name at the top level, I think.
> 
>     Mika

Yuck! I hate this.  One of the things I really hate about Java and C++ is
having many different ways in which a reference to an identifier is looked
up, depending on the context of the reference.  This is one of the big ways
a language gets obscenely overcomplicated without providing any useful benefits.

One of Modula-3's strengths is that when an unqualified identifier is
referenced, it is always looked up according to the same rules, no matter
what kind of thing it is.  Only afterwards are semantic rules applied like,
e.g., the context requires a type but the identifier is a constant.

Except for this example, which I had missed up until now.  IMPORT Stuff
(and also EXPORTS Stuff) looks up Stuff as a global name in a different
way from INTERFACE SpecialStuff = Stuff(Special).  Unfortunately, the language
fails to address this at all in 2.5.5, and the implementation managed to
get away with violating the principle.  So now we have a bit of a slip into
the evil world of junk programming languages.

As for its being convenient, it may save a bit of effort during the initial
coding phase, by not requiring you to think up distinct names, but it is a
cruel and inhuman punishment to inflict on the miserable but innocent wretch who
has to maintain  your code later.  And in just case someone needs to be reminded,
coding is short.  Maintenance is long, sometimes almost forever.

We really should amend the language to say that ordinary and generic interfaces
combined must all have distinct global names.  Likewise for ordinary and
generic modules.

> 


From rodney_bates at lcwb.coop  Sat Jan  2 18:42:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:42:34 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F858A.8070001@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 

On a separate issue, one of the things that the C++ template facility really
botched badly is that instantiations not only can be, but must be, anonymous.
So every single time you want to refer to it, you have to repeat the template
actuals list.  It makes for some very ponderous and confusing code to read,
especially if there are multiple instantiations involved.  It also makes the
semantic analysis unnecessarily difficult for both the human reader and compiler.

In Modula-3 an instantiation must be done once, giving it a simple name, with
the name used thereafter everywhere the instantiation is referred-to.


From jay.krell at cornell.edu  Sat Jan  2 20:18:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 19:18:58 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <4B3F858A.8070001@lcwb.coop>
References: <20091230144007.081152474001@birch.elegosoft.com>, ,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>,
	<20100101230223.355441A2080@async.async.caltech.edu>,
	<4B3F858A.8070001@lcwb.coop>
Message-ID: <COL101-W2278F183A7D8B3C0574A73E6760@phx.gbl>


> Date: Sat, 2 Jan 2010 11:42:34 -0600
> From: rodney
> On a separate issue, one of the things that the C++ template facility really
> botched badly is that instantiations not only can be, but must be, anonymous.


Can be, but not must be.


for types:
  typedef vector<int> vi_t.


for functions, well, usually the parameters are deduced and you
don't have to say them:


template <typename T> T max(const T& a, const T& b)
{
  return (a > b ? a : b);
}


max(1, 2);


If you have something like:


template <typename T> T* New() { return new T(); }

then you do have to say New<Foo>().
You could do something onerous like:
Foo* (*const NewFoo)() = New<T>;


There is a new feature that might enable:


const auto NewFoo = New<T>;



but really, deduction of function template parameters is a very good thing,
no need to fight it, and making the parameters explicit
for some scenarios is not so bad.


There are some very confusing things about templates:
  How much can be checked without instantiation?
  Which names are bound at template definition vs. instantiation?
  Can "template metaprogramming" be done in a more direct way instead
    of seemingly just being an accident?


And (with reverse spin) there are some very powerful things you can do with templates:
   template meta programming :) 
   very good levels of inlining where otherwise you'd have little choice but to use
     function pointers and have poor efficiency (though, not that you can't 
     implement things easily enough and have them at least work without templates)
   not sure the term, but have you seen how in C++ you can write:
     a = b + c + d + e;


where the types involves are vectors/matrices and it compiles down
to have no temporary vectors/matrices.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/76746498/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  2 20:35:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 2 Jan 2010 13:35:59 -0600
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
Message-ID: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>

So, what's changed recently to break this?  It must have been working  
relatively recently.

Sent from my iPhone

On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> What does -C do?
>
> Make it a server process. From the manual:
>
>     -C maxClients
>                 Limits the number of simultaneous clients to  
> maxClients.
>                 Clients beyond the specified maximum are politely  
> refused
>                 service.
>
>                 If this option is not specified, cvsupd serves one  
> client in
>                 the foreground and then exits.
>
> Olaf
>
>> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>>
>>> Any ideas? Interaction problem between threads and select?
>>>
>>> Olaf
>>>
>>> ----- Forwarded message from bugs at elego.de -----
>>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
>>>   From: CM3 <bugs at elego.de>
>>> Reply-To: CM3 <bugs at elego.de>
>>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>>     To: @MISSING_DOMAIN
>>>
>>> #1080: CVSUPD server hangs if used with -C option
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Reporter:  rajeshvadivelu  |            Owner:  wagner
>>>     Type:  sw-bug          |           Status:  new
>>> Priority:  high            |        Milestone:
>>> Component:  sys             |          Version:  5.8-RC3
>>> Severity:  critical        |         Keywords:
>>>  Relnote:                  |     Confidential:  no
>>>      Org:  Collabnet       |   Estimatedhours:  0
>>>    Hours:  0               |         Billable:  0
>>> Totalhours:  0               |
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Htr:
>>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
>>> package.
>>>
>>> Start the cvsupd server with -C option
>>>
>>> ./cvsupd -b /data/cvsupd -C 2
>>>
>>> Try cvsup client to connect to the sever
>>>
>>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>>
>>> The client connection will hang and after sometime we will get   
>>> "Inactivity timeout"
>>>
>>>
>>> Fix:
>>>
>>>
>>>
>>> Env:
>>>
>>>
>>> ----------------------------- 
>>> +----------------------------------------------
>>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
>>> my cvs
>>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
>>> the
>>> cvsup installed.
>>>
>>> The server starts find and there was no issues if I start the server
>>> without -C option.
>>>
>>> Starting cvsupd server without -C option
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd
>>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
>>> 21:02:46
>>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>>
>>> Then I did a client request as below
>>>
>>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>> Parsing supfile "/tmp/cvsupd.cfg"
>>> Connecting to myserver.com
>>> Connected to myserver.com
>>> Rejected by server: Access denied
>>> Will retry at 21:37:09
>>>
>>> So the request was successful and I get a valid error message at the
>>> client.
>>>
>>> But when I start the server with -C option like the one as below,  
>>> requests
>>> from client are hanging and eventually getting "Inactivity  
>>> timeout" after
>>> sometime.
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>>
>>> When ever a new client connection was made, this daemon clones  
>>> another
>>> cvsupd process and it also hangs. So none of the client request were
>>> processed.
>>>
>>> Strace of the main cvsupd server process, when a new client  
>>> request was
>>> fired.
>>>
>>> -----------------------------------
>>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
>>> 553000})
>>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>>> gettimeofday({1262103026, 146476}, NULL) = 0
>>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> close(7)                                = 0
>>> gettimeofday({1262103026, 147481}, NULL) = 0
>>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
>>> ENOENT (No
>>> such file or directory)
>>> write(5, "\0", 1)                       = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> clone(child_stack=0,
>>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>>> child_tidptr=0xb7f43708) = 6543
>>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> close(6)                                = 0
>>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>>
>>> ------------------------------------
>>>
>>> gdb backtrace of the main cvsupd server process
>>>
>>> ------------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>>> ../src/unix/Common/UnixC.c:301
>>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
>>> (M3_Cwb5VA_nfd=4,
>>> M3_A4bqCj_timeout=0xbfed9410) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
>>> '\001')
>>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
>>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:153
>>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>> ------------------------------------------------
>>>
>>>
>>> strace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>>
>>> -----------------------------------
>>>
>>> gdb backtrace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>>> /lib/libpthread.so.0
>>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
>>> M3_AicXUJ_alertable=0
>>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
>>> ThreadPThread.m3:280
>>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
>>> SigHandler.m3:243
>>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>>> ../src/FSServer.m3:231
>>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:227
>>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>>
>>> -------------------------------------------
>>>
>>> So it looks like both the main and cloned cvsupd processes were  
>>> waiting
>>> for a response from the kernel call "__kernel_vsyscall ()". Under  
>>> what
>>> condition will this happen? Am I doing something wrong here?
>>>
>>> --
>>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>>> CM3 <http://projects.elego.de/cm3>
>>> Critical Mass Modula3 Compiler
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>>
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
>>> ermany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
>>>  Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> any
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> rlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>


From jay.krell at cornell.edu  Sat Jan  2 22:42:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 21:42:22 +0000
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with
	-C	option
In-Reply-To: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
Message-ID: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>


 > It must have been working relatively recently.

This is probably the first time it has been tested since getting into our tree.

 - Jay

> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Sat, 2 Jan 2010 13:35:59 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C	option
> 
> So, what's changed recently to break this?  It must have been working  
> relatively recently.
> 
> Sent from my iPhone
> 
> On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> >
> >> What does -C do?
> >
> > Make it a server process. From the manual:
> >
> >     -C maxClients
> >                 Limits the number of simultaneous clients to  
> > maxClients.
> >                 Clients beyond the specified maximum are politely  
> > refused
> >                 service.
> >
> >                 If this option is not specified, cvsupd serves one  
> > client in
> >                 the foreground and then exits.
> >
> > Olaf
> >
> >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> >>
> >>> Any ideas? Interaction problem between threads and select?
> >>>
> >>> Olaf
> >>>
> >>> ----- Forwarded message from bugs at elego.de -----
> >>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
> >>>   From: CM3 <bugs at elego.de>
> >>> Reply-To: CM3 <bugs at elego.de>
> >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> >>>     To: @MISSING_DOMAIN
> >>>
> >>> #1080: CVSUPD server hangs if used with -C option
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Reporter:  rajeshvadivelu  |            Owner:  wagner
> >>>     Type:  sw-bug          |           Status:  new
> >>> Priority:  high            |        Milestone:
> >>> Component:  sys             |          Version:  5.8-RC3
> >>> Severity:  critical        |         Keywords:
> >>>  Relnote:                  |     Confidential:  no
> >>>      Org:  Collabnet       |   Estimatedhours:  0
> >>>    Hours:  0               |         Billable:  0
> >>> Totalhours:  0               |
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Htr:
> >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
> >>> package.
> >>>
> >>> Start the cvsupd server with -C option
> >>>
> >>> ./cvsupd -b /data/cvsupd -C 2
> >>>
> >>> Try cvsup client to connect to the sever
> >>>
> >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>>
> >>> The client connection will hang and after sometime we will get   
> >>> "Inactivity timeout"
> >>>
> >>>
> >>> Fix:
> >>>
> >>>
> >>>
> >>> Env:
> >>>
> >>>
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
> >>> my cvs
> >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
> >>> the
> >>> cvsup installed.
> >>>
> >>> The server starts find and there was no issues if I start the server
> >>> without -C option.
> >>>
> >>> Starting cvsupd server without -C option
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd
> >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
> >>> 21:02:46
> >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> >>>
> >>> Then I did a client request as below
> >>>
> >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>> Parsing supfile "/tmp/cvsupd.cfg"
> >>> Connecting to myserver.com
> >>> Connected to myserver.com
> >>> Rejected by server: Access denied
> >>> Will retry at 21:37:09
> >>>
> >>> So the request was successful and I get a valid error message at the
> >>> client.
> >>>
> >>> But when I start the server with -C option like the one as below,  
> >>> requests
> >>> from client are hanging and eventually getting "Inactivity  
> >>> timeout" after
> >>> sometime.
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> >>>
> >>> When ever a new client connection was made, this daemon clones  
> >>> another
> >>> cvsupd process and it also hangs. So none of the client request were
> >>> processed.
> >>>
> >>> Strace of the main cvsupd server process, when a new client  
> >>> request was
> >>> fired.
> >>>
> >>> -----------------------------------
> >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
> >>> 553000})
> >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> >>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> >>> gettimeofday({1262103026, 146476}, NULL) = 0
> >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> _llseek(7, 0, [0], SEEK_CUR)            = 0
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> close(7)                                = 0
> >>> gettimeofday({1262103026, 147481}, NULL) = 0
> >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
> >>> ENOENT (No
> >>> such file or directory)
> >>> write(5, "\0", 1)                       = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> clone(child_stack=0,
> >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> >>> child_tidptr=0xb7f43708) = 6543
> >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> >>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> close(6)                                = 0
> >>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>>
> >>> ------------------------------------
> >>>
> >>> gdb backtrace of the main cvsupd server process
> >>>
> >>> ------------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> >>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> >>> ../src/unix/Common/UnixC.c:301
> >>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
> >>> (M3_Cwb5VA_nfd=4,
> >>> M3_A4bqCj_timeout=0xbfed9410) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> >>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> >>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
> >>> '\001')
> >>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
> >>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> >>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> >>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:153
> >>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>> ------------------------------------------------
> >>>
> >>>
> >>> strace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> >>>
> >>> -----------------------------------
> >>>
> >>> gdb backtrace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> >>> /lib/libpthread.so.0
> >>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> >>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
> >>> M3_AicXUJ_alertable=0
> >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> >>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
> >>> ThreadPThread.m3:280
> >>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> >>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
> >>> SigHandler.m3:243
> >>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> >>> ../src/FSServer.m3:231
> >>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:227
> >>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>>
> >>> -------------------------------------------
> >>>
> >>> So it looks like both the main and cloned cvsupd processes were  
> >>> waiting
> >>> for a response from the kernel call "__kernel_vsyscall ()". Under  
> >>> what
> >>> condition will this happen? Am I doing something wrong here?
> >>>
> >>> --
> >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> >>> CM3 <http://projects.elego.de/cm3>
> >>> Critical Mass Modula3 Compiler
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>>
> >>>
> >>> --
> >>> Olaf Wagner -- elego Software Solutions GmbH
> >>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
> >>> ermany
> >>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
> >>>  Berlin
> >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> >>> DE163214194
> >>>
> >>
> >>
> >
> >
> >
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> >               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> > any
> > phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> > rlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> > DE163214194
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/c756c57e/attachment.html>

From hosking at cs.purdue.edu  Sun Jan  3 17:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Jan 2010 11:48:05 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
	<COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
Message-ID: <E842F070-580A-4D68-850F-DD4119515F35@cs.purdue.edu>

Can someone try with user threading to see if it is something in  
thread waiting?

Sent from my iPhone

On Jan 2, 2010, at 4:42 PM, Jay K <jay.krell at cornell.edu> wrote:

>  > It must have been working relatively recently.
>
> This is probably the first time it has been tested since getting  
> into our tree.
>
>  - Jay
>
> > From: hosking at cs.purdue.edu
> > To: wagner at elegosoft.com
> > Date: Sat, 2 Jan 2010 13:35:59 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if  
> used with -C	option
> >
> > So, what's changed recently to break this? It must have been working
> > relatively recently.
> >
> > Sent from my iPhone
> >
> > On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com>  
> wrote:
> >
> > > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > >
> > >> What does -C do?
> > >
> > > Make it a server process. From the manual:
> > >
> > > -C maxClients
> > > Limits the number of simultaneous clients to
> > > maxClients.
> > > Clients beyond the specified maximum are politely
> > > refused
> > > service.
> > >
> > > If this option is not specified, cvsupd serves one
> > > client in
> > > the foreground and then exits.
> > >
> > > Olaf
> > >
> > >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> > >>
> > >>> Any ideas? Interaction problem between threads and select?
> > >>>
> > >>> Olaf
> > >>>
> > >>> ----- Forwarded message from bugs at elego.de -----
> > >>> Date: Tue, 29 Dec 2009 16:23:23 -0000
> > >>> From: CM3 <bugs at elego.de>
> > >>> Reply-To: CM3 <bugs at elego.de>
> > >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> > >>> To: @MISSING_DOMAIN
> > >>>
> > >>> #1080: CVSUPD server hangs if used with -C option
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Reporter: rajeshvadivelu | Owner: wagner
> > >>> Type: sw-bug | Status: new
> > >>> Priority: high | Milestone:
> > >>> Component: sys | Version: 5.8-RC3
> > >>> Severity: critical | Keywords:
> > >>> Relnote: | Confidential: no
> > >>> Org: Collabnet | Estimatedhours: 0
> > >>> Hours: 0 | Billable: 0
> > >>> Totalhours: 0 |
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Htr:
> > >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz
> > >>> package.
> > >>>
> > >>> Start the cvsupd server with -C option
> > >>>
> > >>> ./cvsupd -b /data/cvsupd -C 2
> > >>>
> > >>> Try cvsup client to connect to the sever
> > >>>
> > >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>>
> > >>> The client connection will hang and after sometime we will get
> > >>> "Inactivity timeout"
> > >>>
> > >>>
> > >>> Fix:
> > >>>
> > >>>
> > >>>
> > >>> Env:
> > >>>
> > >>>
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror
> > >>> my cvs
> > >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to  
> get
> > >>> the
> > >>> cvsup installed.
> > >>>
> > >>> The server starts find and there was no issues if I start the  
> server
> > >>> without -C option.
> > >>>
> > >>> Starting cvsupd server without -C option
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd
> > >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> > >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30
> > >>> 21:02:46
> > >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> > >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> > >>>
> > >>> Then I did a client request as below
> > >>>
> > >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>> Parsing supfile "/tmp/cvsupd.cfg"
> > >>> Connecting to myserver.com
> > >>> Connected to myserver.com
> > >>> Rejected by server: Access denied
> > >>> Will retry at 21:37:09
> > >>>
> > >>> So the request was successful and I get a valid error message  
> at the
> > >>> client.
> > >>>
> > >>> But when I start the server with -C option like the one as  
> below,
> > >>> requests
> > >>> from client are hanging and eventually getting "Inactivity
> > >>> timeout" after
> > >>> sometime.
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> > >>>
> > >>> When ever a new client connection was made, this daemon clones
> > >>> another
> > >>> cvsupd process and it also hangs. So none of the client  
> request were
> > >>> processed.
> > >>>
> > >>> Strace of the main cvsupd server process, when a new client
> > >>> request was
> > >>> fired.
> > >>>
> > >>> -----------------------------------
> > >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0,
> > >>> 553000})
> > >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> > >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> > >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> > >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > >>> fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
> > >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > >>> gettimeofday({1262103026, 146476}, NULL) = 0
> > >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY| 
> O_LARGEFILE) = 7
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> _llseek(7, 0, [0], SEEK_CUR) = 0
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> close(7) = 0
> > >>> gettimeofday({1262103026, 147481}, NULL) = 0
> > >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1
> > >>> ENOENT (No
> > >>> such file or directory)
> > >>> write(5, "\0", 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> clone(child_stack=0,
> > >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> > >>> child_tidptr=0xb7f43708) = 6543
> > >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> > >>> futex(0x915a460, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> close(6) = 0
> > >>> accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> gdb backtrace of the main cvsupd server process
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> > >>> #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> > >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410)  
> at
> > >>> ../src/unix/Common/UnixC.c:301
> > >>> #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779
> > >>> (M3_Cwb5VA_nfd=4,
> > >>> M3_A4bqCj_timeout=0xbfed9410) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> > >>> #4 0x00f85c7a in ThreadPThread__XIOWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> > >>> M3_CtKayy_interval=1.7976931348623157e+308,  
> M3_AicXUJ_alertable=1
> > >>> '\001')
> > >>> at ../src/thread/PTHREAD/ThreadPThread.m3:936
> > >>> #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> > >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> > >>> #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> > >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> > >>> #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:153
> > >>> #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0)  
> at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>> ------------------------------------------------
> > >>>
> > >>>
> > >>> strace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> gdb backtrace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > >>> /lib/libpthread.so.0
> > >>> #2 0x00f886e6 in ThreadPThread__pthread_cond_wait  
> (cond=0x89c60b8,
> > >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> > >>> #3 0x00f81d9d in ThreadPThread__XWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,
> > >>> M3_AicXUJ_alertable=0
> > >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> > >>> #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> > >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/
> > >>> ThreadPThread.m3:280
> > >>> #5 0x00bd4e14 in SigHandler__ChangeState  
> (M3_BnMAgS_d=0xb7f9c4bc,
> > >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> > >>> #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/
> > >>> SigHandler.m3:243
> > >>> #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> > >>> ../src/FSServer.m3:231
> > >>> #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:227
> > >>> #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #10 0x00f717c8 in RTLinker__RunMainBody  
> (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>>
> > >>> -------------------------------------------
> > >>>
> > >>> So it looks like both the main and cloned cvsupd processes were
> > >>> waiting
> > >>> for a response from the kernel call "__kernel_vsyscall ()".  
> Under
> > >>> what
> > >>> condition will this happen? Am I doing something wrong here?
> > >>>
> > >>> --
> > >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> > >>> CM3 <http://projects.elego.de/cm3>
> > >>> Critical Mass Modula3 Compiler
> > >>>
> > >>>
> > >>> ----- End forwarded message -----
> > >>>
> > >>>
> > >>> --
> > >>> Olaf Wagner -- elego Software Solutions GmbH
> > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G
> > >>> ermany
> > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sit 
> z:
> > >>> Berlin
> > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > >>> DE163214194
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Olaf Wagner -- elego Software Solutions GmbH
> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ
> > > any
> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Be
> > > rlin
> > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > > DE163214194
> > >


From hendrik at topoi.pooq.com  Mon Jan  4 05:12:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 3 Jan 2010 23:12:22 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
	<0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <20100104041222.GD7180@topoi.pooq.com>

On Fri, Jan 01, 2010 at 06:42:34PM -0500, Tony Hosking wrote:
> On 1 Jan 2010, at 18:05, Jay K wrote:
> 
> > Fyi I finally looked at the 2.x implementation and the outputing of
> > C was implemented fairly directly at the m3front layer.
> > There wasn't the "M3CG" stuff.
> > 
> > 
> > Thus, the "easiest" way to get back such functionality would
> > probably be to "interleave" the old code and the new code within m3front.
> 
> I'd like to avoid that sort of interleaving.
> 
> > The "cleaner" way is probably to implement a new M3CG though and
> > leave m3front unchanged.
> 
> This is a much better plan.
> 
> > I still think generating portable C a great way to achieve portability.
> > Better yet maybe, generate C++ and use its exception handling feature.

There's a potential advantage in generating C++:  it might be possible 
to interoperate with C++.  Whether it's feasible to make the C++ 
readable and its contents stable is a big question, though.

-- hendrik


From jay.krell at cornell.edu  Mon Jan  4 12:50:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Jan 2010 11:50:47 +0000
Subject: [M3devel] exception handling and signal mask?
Message-ID: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>


"try" isn't supposed to save the signal mask, right?
I mean..like..finally doesn't restore it, right?
Nor does I suspect raise/except.


Specifically: Darwin.
There should be underscores in Target.m3 there?


Some of this /might/ be might fault.
In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.


Furthermore, um... you know (or if you don't, I'll tell you):


Many platforms have two versions of setjmp/longjmp.
One saves/restore the signal mask. One does not.
Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.

And then, furthermore, every system I've looked into recently except for NT
offers sigsetjmp/siglongjmp.
Their semantics when present are consistent.
Albeit less efficient.
sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.

So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..


Not saving the signal mask is potentially much faster, as it might require a syscall to get.
(Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)


I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
Not going ahead with sigsetjmp. Just yet.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100104/5ec01fea/attachment.html>

From hosking at cs.purdue.edu  Mon Jan  4 16:20:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Jan 2010 10:20:53 -0500
Subject: [M3devel] exception handling and signal mask?
In-Reply-To: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
References: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
Message-ID: <27F530A4-62ED-490E-83CA-E3045103B4E1@cs.purdue.edu>

On 4 Jan 2010, at 06:50, Jay K wrote:

> "try" isn't supposed to save the signal mask, right?
> I mean..like..finally doesn't restore it, right?
> Nor does I suspect raise/except.

Good question.   No, exception handling mechanisms should not be responsible for this.  The design principle is usually to make TRY as fast as possible at the expense of the exceptional case.  Signal mask restoration should be programmed explicitly in a FINALLY clause.

> Specifically: Darwin.
> There should be underscores in Target.m3 there?

So, short answer on Darwin is to prefer _setjmp/_longjmp.

Same on all other platforms.

> 
> 
> Some of this /might/ be might fault.
> In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.
> 
> 
> Furthermore, um... you know (or if you don't, I'll tell you):
> 
> 
> Many platforms have two versions of setjmp/longjmp.
> One saves/restore the signal mask. One does not.
> Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
> Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.
> 
> And then, furthermore, every system I've looked into recently except for NT
> offers sigsetjmp/siglongjmp.
> Their semantics when present are consistent.
> Albeit less efficient.
> sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
> They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.
> 
> So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..
> 
> 
> Not saving the signal mask is potentially much faster, as it might require a syscall to get.
> (Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)
> 
> 
> I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
> Not going ahead with sigsetjmp. Just yet.
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100104/12a92d60/attachment.html>

From hosking at cs.purdue.edu  Wed Jan  6 03:59:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Jan 2010 21:59:42 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
Message-ID: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>

Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question.  What say we clean things up, revert to the original clean language definition, and eliminate LONGINT?  It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away.  The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs.  These can be rewritten to something other than LONGINT.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Wed Jan  6 07:12:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 06:12:17 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
Message-ID: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>


Can I still have:
 TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
or
 TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
? defined in an interface, not in the language?
 
 
If so, probably ok.
 
 
(And can I also somehow get:
 TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
 TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
or
 TYPE UINT32 = [0..16_FFFFFFFF];
 TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
?
)
 
 
Even on 32 bit machines?
 
 
I know there is interface Word.
 
 
And then, what is the difference between:
 
 
 on 32bit:
   INTEGER vs. [16_80000000..16_7FFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFF] 
 
 
 on 64bit:
   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 

 
Any at all?
Just that array sizes are cardinal?
 
 
I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

From hosking at cs.purdue.edu  Wed Jan  6 08:06:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:06:34 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
Message-ID: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>

What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.

On 6 Jan 2010, at 01:12, Jay K wrote:

> 
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
> 
> 
> If so, probably ok.
> 
> 
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
> 
> 
> Even on 32 bit machines?
> 
> 
> I know there is interface Word.
> 
> 
> And then, what is the difference between:
> 
> 
> on 32bit:
>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFF] 
> 
> 
> on 64bit:
>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
> 
> 
> Any at all?
> Just that array sizes are cardinal?
> 
> 
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

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

From hosking at cs.purdue.edu  Wed Jan  6 08:11:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:11:53 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>

PS  Any type that *requires* 64-bit could be represented as:

ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]

or

RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END

Is there ever a need to treat these as 64-bit integers?

On 6 Jan 2010, at 02:06, Tony Hosking wrote:

> What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFF] 
>> 
>> 
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>> 
>>> 
>>> 
>>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>>> 
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  
> 

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

From jay.krell at cornell.edu  Wed Jan  6 09:01:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 08:01:12 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
Message-ID: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>


Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
 
 
As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
 
 
I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
 
 
Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
 
 
Not to mention inlining via special support in the frontend.
(I realize a good backend could do the same).
 
 
interface int64;
 
T = ARRAY[0..1] OF INTEGER.
 
PROCEDURE +(a,b:T):T;
PROCEDURE *(a,b:T):T;
PROCEDURE /(a,b:T):T;
 
 
?
 
 
etc...
 
 
Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Jan 2010 02:11:53 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> PS Any type that *requires* 64-bit could be represented as:
>
> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>
> or
>
> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>
> Is there ever a need to treat these as 64-bit integers?
>
> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>
> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>
> On 6 Jan 2010, at 01:12, Jay K wrote:
>
>
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
>
>
> If so, probably ok.
>
>
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
>
>
> Even on 32 bit machines?
>
>
> I know there is interface Word.
>
>
> And then, what is the difference between:
>
>
> on 32bit:
> INTEGER vs. [16_80000000..16_7FFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFF]
>
>
> on 64bit:
> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>
>
> Any at all?
> Just that array sizes are cardinal?
>
>
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan  6 13:28:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 12:28:02 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W23D9DB3D782C31760086AFE6720@phx.gbl>


Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we don't yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/26f1fbaf/attachment.html>

From jay.krell at cornell.edu  Wed Jan  6 14:17:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 13:17:34 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>


Was truncated!..edited slightly to avoid..


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000








Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/db5c80f2/attachment.html>

From mika at async.async.caltech.edu  Wed Jan  6 17:25:58 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 06 Jan 2010 08:25:58 -0800
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl> 
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <20100106162558.7B4101A2079@async.async.caltech.edu>

Forgot the #endif there?

(81)trs80:~>./a.out
48 4
(82)trs80:~>uname -a
FreeBSD trs80.async.caltech.edu 4.11-RELEASE FreeBSD 4.11-RELEASE #3: Mon Nov 21 20:27:08 PST 2005     root at trs80.async.caltech.edu:/usr/src/sys/compile/TRS80  i386

[lapdog:~] mika% cc jay.c
[lapdog:~] mika% ./a.out
768 4
[lapdog:~] mika% uname -a
Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
[lapdog:~] mika% 

Jay K writes:
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Was truncated!..edited slightly to avoid..
>
>
>From: jay.krell at cornell.edu
>To: m3devel at elegosoft.com
>Subject: double double double double checking jmp_buf size/alignment
>Date: Wed=2C 6 Jan 2010 12:28:02 +0000
>
>
>
>
>
>
>
>
>Getting this right is very important.
>  Well=2C we can overstate but it is wasteful.
>
>
>So anyone with any time=2C please compile/run this and send the "platform" =
>(uname -a) and the output=2C thanks.
>Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
>m3-sys/m3middle/src/Target.m3 and see if all three agree.
>
>
>I have checked a bunch of systems myself but extra checking is good.
>
>
>If you have a system we do not yet or any longer support=2C those are ok to=
>o.
> (e.g. Alpha_*=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)
>
>=20
>#include <setjmp.h>
>#include <stdio.h>
>
>#ifdef __GNUC__
>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B }) - sizeof(x))=
>)
>#else
>#define ALIGN_OF(x) ((int)__alignof(x))
>
>int main()
>{
>  printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIGN_OF(jmp_buf))=3B
>  return 0=3B
>}
>
>
>Thanks=2C
> - Jay
> 		 	   		  =
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Was truncated!..edited slightly to avoid..<br><br><br><hr id=3D"stopSpellin=
>g">From: jay.krell at cornell.edu<br>To: m3devel at elegosoft.com<br>Subject: dou=
>ble double double double checking jmp_buf size/alignment<br>Date: Wed=2C 6 =
>Jan 2010 12:28:02 +0000<br><br>
>
>
>
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Verdana=3B}
></style>
>
>
>Getting this right is very important.<br>&nbsp=3B Well=2C we can overstate =
>but it is wasteful.<br><br><br>So anyone with any time=2C please compile/ru=
>n this and send the "platform" (uname -a) and the output=2C thanks.<br>Or l=
>ook at m3-libs/m3core/src/C/*/Csetjmp.i3 and<br>m3-sys/m3middle/src/Target.=
>m3 and see if all three agree.<br><br><br>I have checked a bunch of systems=
> myself but extra checking is good.<br><br><br>If you have a system we do n=
>ot yet or any longer support=2C those are ok too.<br>&nbsp=3B(e.g. Alpha_*=
>=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)<br><br>&nbsp=3B<br>=
>#include &lt=3Bsetjmp.h&gt=3B<br>#include &lt=3Bstdio.h&gt=3B<br><br>#ifdef=
> __GNUC__<br>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B })=
> - sizeof(x)))<br>#else<br>#define ALIGN_OF(x) ((int)__alignof(x))<br><br>i=
>nt main()<br>{<br>&nbsp=3B printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIG=
>N_OF(jmp_buf))=3B<br>&nbsp=3B return 0=3B<br>}<br><br><br>Thanks=2C<br>&nbs=
>p=3B- Jay<br> 		 	   		  </body>
></html>=
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_--


From hosking at cs.purdue.edu  Wed Jan  6 17:42:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 11:42:56 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
Message-ID: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>

But my question is what are the current use-cases for LONGINT?  Do they justify retaining it?

On 6 Jan 2010, at 03:01, Jay K wrote:

> 
> Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
> 
> 
> As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
> 
> 
> I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
> 
> 
> Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
> 
> 
> Not to mention inlining via special support in the frontend.
> (I realize a good backend could do the same).
> 
> 
> interface int64;
> 
> T = ARRAY[0..1] OF INTEGER.
> 
> PROCEDURE +(a,b:T):T;
> PROCEDURE *(a,b:T):T;
> PROCEDURE /(a,b:T):T;
> 
> 
> ?
> 
> 
> etc...
> 
> 
> Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Jan 2010 02:11:53 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> PS Any type that *requires* 64-bit could be represented as:
>> 
>> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>> 
>> or
>> 
>> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>> 
>> Is there ever a need to treat these as 64-bit integers?
>> 
>> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>> 
>> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>> 
>> On 6 Jan 2010, at 01:12, Jay K wrote:
>> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>> INTEGER vs. [16_80000000..16_7FFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFF]
>> 
>> 
>> on 64bit:
>> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 		 	   		  

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

From rodney_bates at lcwb.coop  Wed Jan  6 18:49:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 06 Jan 2010 11:49:46 -0600
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
	<1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
Message-ID: <4B44CD3A.9000501@lcwb.coop>



Tony Hosking wrote:
> But my question is what are the current use-cases for LONGINT?  Do they 
> justify retaining it?
> 

I want to code stuff that requires arithmetic in > 2^32 range, and be
portable between 32- and 64-bit targets.  Using a record with two
INTEGERs on 32-bit machines and INTEGER on 64-bit machines would require
a lot of code differences between the targets, and the differences
can be pervasive.

OTOH, using the record on all machines will not take advantage of native
64-bit arithmetic when available.

Encapsulating the arithmetic in function calls also would add a lot of
overhead, unless we had a compiler that would inline them, which, as
I understand, we do not.  It's also not as readable.  I am a staunch
opponent of adding user-definable operator overloading to get this
readability advantage, because it interacts with all kinds of things
and makes the language just absurdly overcomplicated.  But LONGINT
arithmetic is language-defined and highly constrained overloading,
so the language complexity impact is much less.


>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>     
> 


From rcolebur at SCIRES.COM  Wed Jan  6 21:03:02 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Wed, 6 Jan 2010 15:03:02 -0500
Subject: [M3devel] double double double double checking
	jmp_buf	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76F734@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Results on the following platforms are all identical:

Windows 2000, Intel Pentium 3:  64 4
Windows XP, Intel Core Duo T2400:  64 4
Windows Vista, Intel Core2 Duo P9600:  64 4

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, January 06, 2010 8:18 AM
To: m3devel
Subject: Re: [M3devel] double double double double checking jmp_buf size/alignment

Was truncated!..edited slightly to avoid..

________________________________
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000

Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)


#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/15d709fb/attachment.html>

From jdp at polstra.com  Wed Jan  6 22:06:00 2010
From: jdp at polstra.com (John Polstra)
Date: Wed, 06 Jan 2010 13:06:00 -0800
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <4B44FB38.3040704@polstra.com>

File sizes and seek offsets (among other things) are 64 bits even on 
32-bit machines, and files these days are often larger than 4GB.  In 
many applications it is necessary to do arithmetic on such values. 
Also, the fact that Modula-3 traps integer overflows causes trouble when 
only 32 bits are used for file offsets.  I had to put an ugly 
work-around into CVSup to avoid an integer overflow fault caused by more 
than 4GB being sent on a TCP connection.

John

Tony Hosking wrote:
> What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>>
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>>
>>
>> If so, probably ok.
>>
>>
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>>
>>
>> Even on 32 bit machines?
>>
>>
>> I know there is interface Word.
>>
>>
>> And then, what is the difference between:
>>
>>
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFF]
>>
>>
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>>
>>
>> Any at all?
>> Just that array sizes are cardinal?
>>
>>
>> I don't know much about the language issues, but dealing with 64bit 
>> integers in 32bit Modula-3 ought to be about as easy and efficient as 
>> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
>> should be represented as 64bit integers, though they aren't yet..it 
>> seems to be a significant interface breaking change..though maybe 
>> range types aren't where LONGINT would be? I'll have to try that..
>>
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>>
>>>
>>>
>>> Now that Jay has carefully refactored all the C-dependent code, I'd 
>>> like to pose the following question. What say we clean things up, 
>>> revert to the original clean language definition, and eliminate 
>>> LONGINT? It was only ever there for compatibility with C headers 
>>> anyway, and these have all now been nicely abstracted away. The only 
>>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
>>> structs. These can be rewritten to something other than LONGINT.
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> 


From jay.krell at cornell.edu  Thu Jan  7 04:35:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 03:35:55 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <4B44FB38.3040704@polstra.com>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<4B44FB38.3040704@polstra.com>
Message-ID: <COL101-W37A4D23768FBED635EB116E6710@phx.gbl>


We still have a bug where merely browsing to a directory with a file > 4GB with the Trestle GUI raises an unhandled exception.
Ideally LONGINT or [0..16_7FFFFFFFFFFFFFFF or higher] would be the type for file sizes everywhere.
It is currently INTEGER and changing it to LONGINT breaks stuff. I'll try the subrange..maybe that'll compile...
I think I proposed changing the type to "double" but nobody including me is super keen on that.
Double does have an interesting property of offering far more range than a 32bit integer on all systems going way back...
 (53bits typically of precision within a 64bit double)

 - Jay


> Date: Wed, 6 Jan 2010 13:06:00 -0800
> From: jdp at polstra.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] A "radical" proposal:  drop LONGINT
> 
> File sizes and seek offsets (among other things) are 64 bits even on 
> 32-bit machines, and files these days are often larger than 4GB.  In 
> many applications it is necessary to do arithmetic on such values. 
> Also, the fact that Modula-3 traps integer overflows causes trouble when 
> only 32 bits are used for file offsets.  I had to put an ugly 
> work-around into CVSup to avoid an integer overflow fault caused by more 
> than 4GB being sent on a TCP connection.
> 
> John
> 
> Tony Hosking wrote:
> > What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> > machines INTEGER would still be 32-bit.
> > 
> > On 6 Jan 2010, at 01:12, Jay K wrote:
> > 
> >>
> >> Can I still have:
> >> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> or
> >> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> ? defined in an interface, not in the language?
> >>
> >>
> >> If so, probably ok.
> >>
> >>
> >> (And can I also somehow get:
> >> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> >> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> >> or
> >> TYPE UINT32 = [0..16_FFFFFFFF];
> >> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> >> ?
> >> )
> >>
> >>
> >> Even on 32 bit machines?
> >>
> >>
> >> I know there is interface Word.
> >>
> >>
> >> And then, what is the difference between:
> >>
> >>
> >> on 32bit:
> >>   INTEGER vs. [16_80000000..16_7FFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFF]
> >>
> >>
> >> on 64bit:
> >>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
> >>
> >>
> >> Any at all?
> >> Just that array sizes are cardinal?
> >>
> >>
> >> I don't know much about the language issues, but dealing with 64bit 
> >> integers in 32bit Modula-3 ought to be about as easy and efficient as 
> >> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
> >> should be represented as 64bit integers, though they aren't yet..it 
> >> seems to be a significant interface breaking change..though maybe 
> >> range types aren't where LONGINT would be? I'll have to try that..
> >>
> >>
> >> - Jay
> >>
> >>
> >> ________________________________
> >>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >>> Date: Tue, 5 Jan 2010 21:59:42 -0500
> >>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
> >>> Subject: [M3devel] A "radical" proposal: drop LONGINT
> >>>
> >>>
> >>>
> >>> Now that Jay has carefully refactored all the C-dependent code, I'd 
> >>> like to pose the following question. What say we clean things up, 
> >>> revert to the original clean language definition, and eliminate 
> >>> LONGINT? It was only ever there for compatibility with C headers 
> >>> anyway, and these have all now been nicely abstracted away. The only 
> >>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
> >>> structs. These can be rewritten to something other than LONGINT.
> >>>
> >>>
> >>> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >>> University
> >>> 305 N. University Street | West Lafayette | IN 47907 | USA
> >>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/7dd1b511/attachment.html>

From jay.krell at cornell.edu  Thu Jan  7 07:59:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 06:59:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
Message-ID: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>


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/20100107/16b32603/attachment.html>

From jay.krell at cornell.edu  Thu Jan  7 10:47:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 09:47:07 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>


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/20100107/dd342806/attachment.html>

From jay.krell at cornell.edu  Thu Jan  7 12:22:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 11:22:37 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>


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/20100107/6cc326a8/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/6cc326a8/attachment.txt>

From hendrik at topoi.pooq.com  Thu Jan  7 14:11:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 08:11:17 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <20100107131117.GA22266@topoi.pooq.com>

On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> 
> 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

In any case, is the proper type for file offsets [0..7fffffffffffffff] 
or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
effort to make that legal in Modula 3.

-- hendrik


From wagner at elegosoft.com  Thu Jan  7 14:52:10 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 07 Jan 2010 14:52:10 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>

Quoting hendrik at topoi.pooq.com:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>>
>> 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
>
> In any case, is the proper type for file offsets [0..7fffffffffffffff]
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> effort to make that legal in Modula 3.

Well, I don't think that should be any practical problem right now,
shouldn't it? But 32 bit offsets have been overcome for years even
on 32 bit systems, so I definitely think we should keep the LONGINT
type and even try to incompatibly change the internal file length
type (with due care and consideration of course).

And please not for the still unfinished release, but for the next
one.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Thu Jan  7 15:00:08 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 09:00:08 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <20100107140008.GA25288@topoi.pooq.com>

On Thu, Jan 07, 2010 at 02:52:10PM +0100, Olaf Wagner wrote:
> Quoting hendrik at topoi.pooq.com:
> 
> >In any case, is the proper type for file offsets [0..7fffffffffffffff]
> >or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> >effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it?

Not just yet.  But it will be, and I suspect Modula 3 will still be 
around then.

-- hendrik


From hosking at cs.purdue.edu  Thu Jan  7 16:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:12:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <82B392A0-160D-4CD3-A36C-A64DFE7605ED@cs.purdue.edu>

I've generally found it easy enough to fix clients so they use ORD(size) to convert LONGINT to INTEGER at the boundary between the library definitions and the application.  This means they will get a run-time error if they access a file of size > LAST(INTEGER), so more pervasive changes will be needed to handle larger files.  But that is the responsibility of the client code,  not the library.  The whole point of LONGINT was to support large file sizes.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 01:59, Jay K wrote:

> 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/20100107/67014ed0/attachment.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:13:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:13:58 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <E6BEA822-6DE6-45E5-BBE9-CE0DCD37664D@cs.purdue.edu>

On 7 Jan 2010, at 04:47, Jay K wrote:

> 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

I discourage both of these, just to emphasize that INTEGER and LONGINT are independent types.  

> Most of the toplevel users will end up throwing in ORD, as they
> require files to fit in memory/addressspace.

Right.

> 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
> 



From hosking at cs.purdue.edu  Thu Jan  7 16:20:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:20:38 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
Message-ID: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>

On 7 Jan 2010, at 06:22, Jay K wrote:

> 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.

Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.

The problem below comes because I made WordRep and LongRep hidden interfaces.  I've just reverted m3core/src/word/m3makefile so things will now work.

> 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
> 
> <1.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/62f5857e/attachment.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:21:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:21:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <D21111F3-7947-4E4A-BBD6-9EED9A238C3B@cs.purdue.edu>

It will need to be a LONGINT type:  [0L..16_7fffffffffffffffL]


On 7 Jan 2010, at 08:11, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/400b4b56/attachment.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:23:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:23:04 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>

On 7 Jan 2010, at 08:52, Olaf Wagner wrote:

> Well, I don't think that should be any practical problem right now,

> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).

I think I am now persuaded LONGINT should stay.  But, I don't understand what "incompatibly change the internal file length
type (with due care and consideration of course)" means?

> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hendrik at topoi.pooq.com  Thu Jan  7 17:46:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 11:46:20 -0500
Subject: [M3devel] Integers
Message-ID: <20100107164620.GA30061@topoi.pooq.com>

I have some questions as to the constraints that need to be placed on 
integral types.  These issues are fundamental to an understanding of the 
role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
about them.

Is there a need for an integer type that can contain all the sizes of 
integers that can be handled by the language?  I'll call it TOP just so 
I can talk about it easily.

If it is necessary, is TOP only needed to make the language definition 
clean and concise?  Conversely, is it necessary for TOP to be available 
to programmers?  Is it necessary for TOP to be efficiently implemented, 
or implemented at all?

Even if it is not available directly to programmers, are there language 
features that require it internally?

Is it necessary that, for every two integer subranges I and J, there 
exist an integer range K such that both I and J are subranges of K?

The most commonly used integral type is INTEGER.  It seems to be the 
type used by programmers by default when they don't want to think of 
the specific range they will need.  But is it necessary for the type 
called INTEGER to be TOP?  Or, is there is no maximum implemented 
integral type, is it still necessary for INTEGER to be a maximal 
integral type?

-- hendrik



From jay.krell at cornell.edu  Thu Jan  7 18:26:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 17:26:55 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>


> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);



after:
  a := ORD(Rd.Length(b));

  c := ORD(Rd.Index(b));


  Rd.Seek(b, VAL(d, LONGINT));




Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/3fe806a3/attachment.html>

From mika at async.async.caltech.edu  Thu Jan  7 18:47:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 09:47:28 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <20100107174728.3A3D41A207D@async.async.caltech.edu>

Jay K writes:
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
...
>One more compatible alternative might be to add LengthL=2C IndexL=2C SeekL?
>Maybe only break rd/wr implementers but not users?
>
>
>The reason I don't like that though is that it is even more of a no-op.
>Nobody will switch to the new functions.
>Similar to how "today" everybody will just ORD/VAL over the difference.

Isn't this what the <*OBSOLETE*> pragma is for?

     Mika

>
>
>To be clear though=2C the time for this change was 10 or 20 years ago.
>Now=2C 32bit systems are going away and with them this problem.
>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I think Op=
>enBSD..)
>
>
> - Jay
>
>
>> Date: Thu=2C 7 Jan 2010 14:52:10 +0100
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>>=20
>> Quoting hendrik at topoi.pooq.com:
>>=20
>> > On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=2C Jay K wrote:
>> >>
>> >> File.i3:
>> >>
>> >>
>> >>   Status =3D RECORD
>> >>     type: Type=3B
>> >>     modificationTime: Time.T=3B
>> >>     size: CARDINAL (* oops... *)
>> >>   END=3B
>> >>
>> >>
>> >> What to do?
>> >> [0.. higher than 7FFFFFFF] doesn't "just work".
>> >>    higher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"  =
>=20
>> >> on the end=2C
>> >>    which presumably has some relationship to turning it into a  =20
>> >> LONGINT=2C which
>> >>    causes users to fail to compile
>> >
>> > In any case=2C is the proper type for file offsets [0..7fffffffffffffff=
>]
>> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
>> > effort to make that legal in Modula 3.
>>=20
>> Well=2C I don't think that should be any practical problem right now=2C
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems=2C so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>>=20
>> And please not for the still unfinished release=2C but for the next
>> one.
>>=20
>> Olaf
>> --=20
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C G=
>ermany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86=
> 95
>>     http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: B=
>erlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=
>194
>>=20
> 		 	   		  =
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>&gt=3B Not in the current release<br><br>Agreed.<br><br><br>I think I'll ha=
>ve this done in the next few days=2C with the<br>major caveat that it does =
>break a lot of code. I'll fix the cm3 tree.<br><br><br>The breakage is roug=
>hly:<br><br><br>rd/wr users:<br>before:<br>&nbsp=3B a :=3D Rd.Length(b)=3B<=
>br>&nbsp=3B c :=3D Rd.Index(b)=3B<br>&nbsp=3B Rd.Seek(b=2C d)=3B<br>
><br><br>after:<br>&nbsp=3B a :=3D ORD(Rd.Length(b))=3B<br>
>&nbsp=3B c :=3D ORD(Rd.Index(b))=3B<br>
>
>&nbsp=3B Rd.Seek(b=2C VAL(d=2C LONGINT))=3B<br>
>
><br><br>Though I think the last line should just work without change.<br><b=
>r><br>rd/wr implementers:<br>&nbsp=3Bmore substantial changes=2C but still =
>similar=2C lots of ORD/VAL=2C and "L".<br><br><br>One more compatible alter=
>native might be to add LengthL=2C IndexL=2C SeekL?<br>Maybe only break rd/w=
>r implementers but not users?<br><br><br>The reason I don't like that thoug=
>h is that it is even more of a no-op.<br>Nobody will switch to the new func=
>tions.<br>Similar to how "today" everybody will just ORD/VAL over the diffe=
>rence.<br><br><br>To be clear though=2C the time for this change was 10 or =
>20 years ago.<br>Now=2C 32bit systems are going away and with them this pro=
>blem.<br>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I=
> think OpenBSD..)<br><br><br>&nbsp=3B- Jay<br><br><br>&gt=3B Date: Thu=2C 7=
> Jan 2010 14:52:10 +0100<br>&gt=3B From: wagner at elegosoft.com<br>&gt=3B To:=
> m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] what to do about fi=
>le sizes being 32bits?<br>&gt=3B <br>&gt=3B Quoting hendrik at topoi.pooq.com:=
><br>&gt=3B <br>&gt=3B &gt=3B On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=
>=2C Jay K wrote:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B File.i3:<br>=
>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   Status =
>=3D RECORD<br>&gt=3B &gt=3B&gt=3B     type: Type=3B<br>&gt=3B &gt=3B&gt=3B =
>    modificationTime: Time.T=3B<br>&gt=3B &gt=3B&gt=3B     size: CARDINAL (=
>* oops... *)<br>&gt=3B &gt=3B&gt=3B   END=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B What to do?<br>&gt=3B &gt=3B&gt=3B =
>[0.. higher than 7FFFFFFF] doesn't "just work".<br>&gt=3B &gt=3B&gt=3B    h=
>igher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"   <br>&gt=
>=3B &gt=3B&gt=3B on the end=2C<br>&gt=3B &gt=3B&gt=3B    which presumably h=
>as some relationship to turning it into a   <br>&gt=3B &gt=3B&gt=3B LONGINT=
>=2C which<br>&gt=3B &gt=3B&gt=3B    causes users to fail to compile<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B In any case=2C is the proper type for file offs=
>ets [0..7fffffffffffffff]<br>&gt=3B &gt=3B or [0..ffffffffffffffff]?  I sus=
>pect the latter.  It might take some<br>&gt=3B &gt=3B effort to make that l=
>egal in Modula 3.<br>&gt=3B <br>&gt=3B Well=2C I don't think that should be=
> any practical problem right now=2C<br>&gt=3B shouldn't it? But 32 bit offs=
>ets have been overcome for years even<br>&gt=3B on 32 bit systems=2C so I d=
>efinitely think we should keep the LONGINT<br>&gt=3B type and even try to i=
>ncompatibly change the internal file length<br>&gt=3B type (with due care a=
>nd consideration of course).<br>&gt=3B <br>&gt=3B And please not for the st=
>ill unfinished release=2C but for the next<br>&gt=3B one.<br>&gt=3B <br>&gt=
>=3B Olaf<br>&gt=3B -- <br>&gt=3B Olaf Wagner -- elego Software Solutions Gm=
>bH<br>&gt=3B                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 =
>Berlin=2C Germany<br>&gt=3B phone: +49 30 23 45 86 96  mobile: +49 177 2345=
> 869  fax: +49 30 23 45 86 95<br>&gt=3B     http://www.elegosoft.com | Gesc=
>h=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin<br>&gt=3B Handelregister: Amtsg=
>ericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>&gt=3B <br> 		 	=
>   		  </body>
></html>=
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_--


From hosking at cs.purdue.edu  Thu Jan  7 19:58:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 13:58:51 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100107164620.GA30061@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
Message-ID: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>

I think your confusion relates to understanding how the language defines "base" types.

You should understand that INTEGER and LONGINT have *different* base types.  This indicates that they have inherently different representations, and indeed, operations on INTEGER and operations on LONGINT are inherently different.

Every enumeration type similarly has a base type.  If it's range is expressed over INTEGER values then its base type is INTEGER.  If expressed over LONGINT then its base type is LONGINT.

I don't think I understand the rest of your questions.

On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:

> I have some questions as to the constraints that need to be placed on 
> integral types.  These issues are fundamental to an understanding of the 
> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> about them.
> 
> Is there a need for an integer type that can contain all the sizes of 
> integers that can be handled by the language?  I'll call it TOP just so 
> I can talk about it easily.
> 
> If it is necessary, is TOP only needed to make the language definition 
> clean and concise?  Conversely, is it necessary for TOP to be available 
> to programmers?  Is it necessary for TOP to be efficiently implemented, 
> or implemented at all?
> 
> Even if it is not available directly to programmers, are there language 
> features that require it internally?
> 
> Is it necessary that, for every two integer subranges I and J, there 
> exist an integer range K such that both I and J are subranges of K?
> 
> The most commonly used integral type is INTEGER.  It seems to be the 
> type used by programmers by default when they don't want to think of 
> the specific range they will need.  But is it necessary for the type 
> called INTEGER to be TOP?  Or, is there is no maximum implemented 
> integral type, is it still necessary for INTEGER to be a maximal 
> integral type?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/747bbe2e/attachment.html>

From hosking at cs.purdue.edu  Thu Jan  7 20:07:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:07:03 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>

Jay,

I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony

On 7 Jan 2010, at 12:26, Jay K wrote:

> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

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

From hosking at cs.purdue.edu  Thu Jan  7 20:17:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:17:40 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>

I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 14:07, Tony Hosking wrote:

> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
>> > Not in the current release
>> 
>> Agreed.
>> 
>> 
>> I think I'll have this done in the next few days, with the
>> major caveat that it does break a lot of code. I'll fix the cm3 tree.
>> 
>> 
>> The breakage is roughly:
>> 
>> 
>> rd/wr users:
>> before:
>>   a := Rd.Length(b);
>>   c := Rd.Index(b);
>>   Rd.Seek(b, d);
>> 
>> 
>> after:
>>   a := ORD(Rd.Length(b));
>>   c := ORD(Rd.Index(b));
>>   Rd.Seek(b, VAL(d, LONGINT));
>> 
>> 
>> Though I think the last line should just work without change.
>> 
>> 
>> rd/wr implementers:
>>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
>> 
>> 
>> One more compatible alternative might be to add LengthL, IndexL, SeekL?
>> Maybe only break rd/wr implementers but not users?
>> 
>> 
>> The reason I don't like that though is that it is even more of a no-op.
>> Nobody will switch to the new functions.
>> Similar to how "today" everybody will just ORD/VAL over the difference.
>> 
>> 
>> To be clear though, the time for this change was 10 or 20 years ago.
>> Now, 32bit systems are going away and with them this problem.
>> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
>> 
>> 
>>  - Jay
>> 
>> 
>> > Date: Thu, 7 Jan 2010 14:52:10 +0100
>> > From: wagner at elegosoft.com
>> > To: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
>> > 
>> > Quoting hendrik at topoi.pooq.com:
>> > 
>> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> > >>
>> > >> 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
>> > >
>> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
>> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
>> > > effort to make that legal in Modula 3.
>> > 
>> > Well, I don't think that should be any practical problem right now,
>> > shouldn't it? But 32 bit offsets have been overcome for years even
>> > on 32 bit systems, so I definitely think we should keep the LONGINT
>> > type and even try to incompatibly change the internal file length
>> > type (with due care and consideration of course).
>> > 
>> > And please not for the still unfinished release, but for the next
>> > one.
>> > 
>> > Olaf
>> > -- 
>> > Olaf Wagner -- elego Software Solutions GmbH
>> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/2b22053a/attachment.html>

From jay.krell at cornell.edu  Thu Jan  7 21:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:31:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
Message-ID: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>


Given that files are in fact larger than 4GB, why should we impose such a limit?

Doesn't it make for a pretty lame system?

 

Pretty much no existing 32bit C system for many years now any such limit and

C started going past these limits around 15 years ago.

 

It turns out changes I sent were pretty nearly done. I can now build all of "std"

with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".

 

 

 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:  +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:  +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 


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

From jay.krell at cornell.edu  Thu Jan  7 21:33:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:33:22 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>


I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,

and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).

This seems to be about the best we can do.

 

Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?

Therefore INTEGER and LONGINT somewhat interchangable?

 

 

Again, currently merely browsing to a directory with a large file raises an exception.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:07:03 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Thu Jan  7 22:33:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:33:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
Message-ID: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>

What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.

If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.

I am really starting to think the addition of LONGINT was a big mistake.

On 7 Jan 2010, at 15:31, Jay K wrote:

> Given that files are in fact larger than 4GB, why should we impose such a limit?
> Doesn't it make for a pretty lame system?
>  
> Pretty much no existing 32bit C system for many years now any such limit and
> C started going past these limits around 15 years ago.
>  
> It turns out changes I sent were pretty nearly done. I can now build all of "std"
> with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:17:40 -0500
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.
> 
> 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 7 Jan 2010, at 14:07, Tony Hosking wrote:
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone:  +49 30 23 45 86 96  +49 30 23 45 86 96 mobile:  +49 177 2345 869 +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 
> 

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

From hosking at cs.purdue.edu  Thu Jan  7 22:37:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:37:12 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
Message-ID: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>

On 7 Jan 2010, at 15:33, Jay K wrote:

> I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,
> and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).
> This seems to be about the best we can do.

I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger than address spaces.  If someone really wants to use an OS-specific file size that is bigger than an address space then they can use the C interfaces, along with LONGINT.  If they are working with Rd/Wr then they don't need to mess with the ugliness.

>  Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?
> Therefore INTEGER and LONGINT somewhat interchangable?

Again, this contradicts the design principles of the Modula-3 type system.

>  Again, currently merely browsing to a directory with a large file raises an exception.

What code?  Does it use C interfaces or the Modula-3 interfaces?

>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:07:03 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/6cd9744d/attachment.html>

From mika at async.async.caltech.edu  Fri Jan  8 01:31:10 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 16:31:10 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
	<D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>
Message-ID: <20100108003110.0BC1E1A207D@async.async.caltech.edu>

Tony Hosking writes:
>
>--Apple-Mail-29--1022292864
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=iso-8859-1
>
>On 7 Jan 2010, at 15:33, Jay K wrote:
>
>> I agree it isn't pretty but a big mistake was made many years ago, =
>assuming file sizes are no larger than address spaces,
>> and the current system might also not be so great (not allowing =
>comparing a LONGINT to "0" or assigning it from an INTEGER).
>> This seems to be about the best we can do.
>
>I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger =
>than address spaces.  If someone really wants to use an OS-specific file =
>size that is bigger than an address space then they can use the C =
>interfaces, along with LONGINT.  If they are working with Rd/Wr then =
>they don't need to mess with the ugliness.

Just to add my input to this discussion... 

I have programs that like to write huge log files (> 2GB), and with Wr.PutText
this is a problem.

But it's very easy to work around.  Use the RdWrReset interface implemented as
follows (not sure where I originally got this code from, Blair MacIntyre?):

MODULE RdWrReset;
IMPORT Rd AS R, Wr AS W;
IMPORT RdClass, WrClass;
<*NOWARN*>IMPORT UnsafeWr, UnsafeRd;

(* Since we need to use the Mutex properties of Rd.T and Wr.T, we
   should actually import UnsafeWr and UnsafeRd. We need to add the
   following revelations, as the comment in UnsafeRd points out, if we
   want to include both the Unsafe* and *Class interfaces. *)
REVEAL RdClass.Private <: MUTEX;
REVEAL WrClass.Private <: MUTEX;

PROCEDURE Rd (rd: R.T) =
  BEGIN
    LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END;
  END Rd;

PROCEDURE Wr (wr: W.T) =
  BEGIN
    LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END;
  END Wr;

BEGIN END RdWrReset.

So far this has sufficed for me...
    Mika


From jay.krell at cornell.edu  Fri Jan  8 02:07:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:07:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W19301B1547CB12BC8501ECE6700@phx.gbl>


 > As you are already aware, some systems have only 32-bit addressable files.

 

Really?!

I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.

4G has not been a large file size for quite a long time now.

FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.

Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.

 

 

 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.

 

 

I can build "std" now. It does escape pretty far, but it is actually fairly contained.

It would help a little of an INTEGER could be assigned to a LONGINT.

Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.

Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..

 

 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  

 

Isn't that pretty natural?

Aren't "file" one of the main things used with Rd/Wr?

Besides that, if you consider "streams", going beyond 4G seems even more limiting.

You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.

 

I agree that dealing with such large files can be difficult, depending on the algorithms.

But the "base" of the system shouldn't remove the ability for higher parts to do so.

 

 

And resorting to C seems unnecessary.

The operating system interfaces are essentially identical on Posix, as long you #define whatever.

They vary at the ABI level for compatibility.

 

 

Should I create a branch, or can we review the diffs and decide?

 

 

 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:   +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:   +49 177 2345 869  +49 177 2345 869   +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/7e7b9a43/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 02:09:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:09:11 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W17B8D1C035DBDB2940DF36E6700@phx.gbl>


To repeat myself, basically every system supports 64bit file sizes and they are easy to use from C.

In my opinion, a "systems" language is something you can do "anything" in.

Now, granted, the language isn't the issue here.

But conflation of libraries and languages is common and not entirely invalid.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:    +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96   mobile:    +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869   fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



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

From jay.krell at cornell.edu  Fri Jan  8 02:18:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:18:51 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W260CDC61EC90506D4D79D8E6700@phx.gbl>


[truncated]

To repeat myself, basically every system supports 64bit file

sizes and they are easy to use from C.
In my opinion, a "systems" language is something you

can do "anything" in.
Now, granted, the language isn't the issue here.
But conflation of libraries and languages is common

and not entirely invalid.
 
 
 - Jay
 






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 






From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?



What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001        +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484        +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:     +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96        +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96    mobile:     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869       +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869    fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/733c2790/attachment.html>

From rodney_bates at lcwb.coop  Fri Jan  8 02:22:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:22:00 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <4B4688B8.50701@lcwb.coop>

Full-range unsigned integers are a language designer's headache, because
there are conflicts no matter what you do.  The Modula-3 approach is to
use the operations in interface Word.i3 (and now Long.i3) on type
INTEGER (not CARDINAL, which has only half the range).  These apply
unsigned interpretation to values of type INTEGER.

hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 02:45:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:45:03 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B4688B8.50701@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>, <4B4688B8.50701@lcwb.coop>
Message-ID: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>


I understand "full range" is a problem, because, something like,

the set of operations isn't closed.

 

 

I believe you need to define multiple types and/or

multiple operations.

 

 

You need an ability to trap/fail on overflow.

You need an ability for silent wraparound on overflow.

You need perhaps a way to add precision as needed. Slow.

You need perhaps a way to specify arbitrarily high precision,

  and then, again, either trap/fail or silent wraparound.

 

 

Basically, in my opinion, having just "INTEGER" and just "+"

isn't nearly sufficient.

 

 

Not having operator overloading makes pretty much any solution painful to use.

 

 

We and C both have a compromise that covers most cases and

when people really need higher fixed or arbitrary precision, they

either give up the convenient "operator" syntax or use C++.

 

 

As I understand, in C, unsigned integers are defined to "silently wraparound"

and signed integers are implementation defined, could "trap" but in reality

all implementations "silently wraparound".

It is a point of unsafety though, beyond the more well known

buffer overflows, leaks, etc.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:22:00 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Full-range unsigned integers are a language designer's headache, because
> there are conflicts no matter what you do. The Modula-3 approach is to
> use the operations in interface Word.i3 (and now Long.i3) on type
> INTEGER (not CARDINAL, which has only half the range). These apply
> unsigned interpretation to values of type INTEGER.
> 
> hendrik at topoi.pooq.com wrote:
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >> 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
> > 
> > In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some 
> > effort to make that legal in Modula 3.
> > 
> > -- hendrik
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/21906409/attachment.html>

From rodney_bates at lcwb.coop  Fri Jan  8 02:35:20 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:35:20 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <4B468BD8.4020106@lcwb.coop>


I addressed all these details in my original LONGINT proposal, but it
didn't get much attention at the time.  That would have been October
of 2007.  I can't find the posts right now, because the link
http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
too many email account changes to be able to find it in my own
inboxes.

I proposed, and still do, that LONGINT be an ordinal type.  This has
the consequence, by preexisting rules, that INTEGER and LONGINT would
be assignable to each other.  This does not violate the preexisting
language precedent, in fact, it is exactly like the preexisting rules
for INTEGER and all its subtypes--they are assignable if the value is
in the LHS type.

This eliminates the necessity for the ORD and VAL conversions in most
places, where there are mixtures of the types.  Most places in the
language require only assignability, not type equality.  Exceptions
include passing to a VAR formal and use in a type definition of a new
type.

A consequence of existing rules is that there would be, if necessary,
runtime value checks.  In many cases, including the examples we are
discussing here, assigning a LONGINT to an INTEGER could well
introduce a bug when a value is out of range, but this is no different
from what happens when ORD/VAL are coded explicitly.

On the other side of this argument, the necessity of coding ORD/VAL
would point out statically, places where value range errors should be
ruled out by the programmer.  A conscientious programmer would then
make an informed decision whether to just insert ORD/VAL, or whether
it was necessary to change the INTEGER variable to LONGINT.  But
again, the already existing rules for subranges don't do this, so
making INTEGER and LONGINT assignable would be consistent.

Note that right now, the current implementation has a linguistic
contradiction in that, if subranges of LONGINT are allowed, then
LONGINT is an ordinal type, which implies LONGINT and INTEGER are
mutually assignable.  This could, of course be fixed in the language,
but I would prefer making the two types assignable.




Jay K wrote:
> 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
> 


From rodney_bates at lcwb.coop  Fri Jan  8 02:37:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:37:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
Message-ID: <4B468C63.9050404@lcwb.coop>



Tony Hosking wrote:
> On 7 Jan 2010, at 06:22, Jay K wrote:
> 
>> 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.
> 
> Again, I discourage this as not in the spirit of the Modula-3 type 
> system which abhors implicit casts.
> 
Indeed, Modula-3 has no implicit casts at all.  But it does have something
that sometimes accomplishes the same result in a way that is far simpler
to define and represents a higher level of abstraction, namely, the
concept of assignability.  A value, e.g. 10, can be in the value set of
many types (INTEGER, many of its subranges, and now LONGINT and many if
its subranges too).  If so, it can in certain carefully specified cases,
be assigned from one of these types to another, without any syntactically
explicit notation required of the programmer.

This represents the more abstract view that 10 is 10, as opposed to the
usual view that 10 sitting in a byte is not the same as 10 in a word.
Of course, at the machine level. they are not the same, but in Modula-3,
that is only a representation matter that the compiler must take care of,
not a high-level language matter that needs pages of rules to define.

It took me years to fully understand the implications of replacing implicit
type conversions by the assignability concept, but I now consider it one
of Modula-3's great ideas, even if it is a small thing.


From jay.krell at cornell.edu  Fri Jan  8 03:01:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:01:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <COL101-W41E4AFA2D1DDE2CD2C39D7E6700@phx.gbl>


I apologize for not paying close attention at the time.

That seems to make sense to me now.

 

 

There is at least an in-between version where INTEGER

is assignable to LONGINT.

 

 

In your proposal, the amount of source change required would be

I think very very little. Some code would "just work" with large files,

and some code would fail.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:35:20 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time. That would have been October
> of 2007. I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type. This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other. This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.
> 
> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types. Most places in the
> language require only assignability, not type equality. Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.
> 
> A consequence of existing rules is that there would be, if necessary,
> runtime value checks. In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.
> 
> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer. A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT. But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.
> 
> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable. This could, of course be fixed in the language,
> but I would prefer making the two types assignable.
> 
> 
> 
> 
> Jay K wrote:
> > 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/20100108/9394f4b3/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 02:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
Message-ID: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>


I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/3f0be214/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 03:25:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:25:56 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>, ,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>, ,
	<4B468C63.9050404@lcwb.coop>,
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <COL101-W55238865FDCA7966D9D371E6700@phx.gbl>


Here are some of the old messages. I haven't yet found a proposal.


https://mail.elegosoft.com/pipermail/m3devel/2007-July/000323.html
https://mail.elegosoft.com/pipermail/m3devel/2007-July/
https://mail.elegosoft.com/pipermail/m3devel/

You have to allow the exception for the certificate.


 - Jay



From: jay.krell at cornell.edu
To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?








I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ea64c1af/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 04:35:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 03:35:44 +0000
Subject: [M3devel] longint..revisited?
Message-ID: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>


I can't find Rodney's proposal but I think I understand
a lot of it from today's mail.


Can we revisit this?


My understanding is that Rodney's proposal
deems INTEGER assignable to LONGINT,
and vice versa, and that assignments of LONGINT
to INTEGER undergo runtime range checks,
can raise exceptions.


I assume it also follows that:


LONGINT can be added/subtracted/modded to INTEGER,
yielding LONGINT.


INTEGER MOD LONGINT would range check the LONGINT.


INC/DEC(LONGINT, INTEGER) would just work


INC/DEC(INTEGER, LONGINT) would range check.


The downside is that the chance for failure would be
silently injected into various places.


Another proposal would be that INTEGER is assignable to LONGINT,
but not vice versa. I really don't see why not.


   LONGINT := INTEGER  
   LONGINT + INTEGER => LONGINT  
  


LONGINT - INTEGER => LONGINT  
  


LONGINT * INTEGER => LONGINT  
   LONGINT / INTEGER => LONGINT  
  
LONGINT MOD INTEGER => INTEGER (think about it) 
   INC(LONGINT, INTEGER)
  

DEC(LONGINT, INTEGER)





all seem very reasonable.


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/50e11a68/attachment.html>

From hendrik at topoi.pooq.com  Fri Jan  8 04:53:44 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 22:53:44 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
Message-ID: <20100108035343.GA9556@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> 
> I understand "full range" is a problem, because, something like,
> the set of operations isn't closed.

What does this mean?  What exactly do you mean by "full range"?  And 
what do you mean by "closed"?

> 
> I believe you need to define multiple types and/or
> multiple operations.
> 
> You need an ability to trap/fail on overflow.
> 
> You need an ability for silent wraparound on overflow.
> You need perhaps a way to add precision as needed. Slow.
> You need perhaps a way to specify arbitrarily high precision,
>   and then, again, either trap/fail or silent wraparound.
> 
> Basically, in my opinion, having just "INTEGER" and just "+"
> isn't nearly sufficient.
> 
> Not having operator overloading makes pretty much any solution painful to use.

+ is defined on integers and reals.  If that's not an overload, why not 
have + defined on longint as well?

> We and C both have a compromise that covers most cases and
> when people really need higher fixed or arbitrary precision, they
> either give up the convenient "operator" syntax or use C++.
>  
> 
> As I understand, in C, unsigned integers are defined to "silently wraparound"

The wraparound unsigned integers are extremely useful.  The most common 
operations, +, *, and - have a clean, well-defined semantics as 
arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
identifies.

Suppose you have an expression involving +, -, * and integers in 
0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
If you evaluate it with nonwraparound arithmetic, you may get overflow.
Nonetheless, using wraparound arithmetic under these conditions will 
still give the right answer.

This makes wraparound integers useful for indexing strange arrays with, 
say, multiple subscripts in the rante 1000000000..1000000003.  
Intermediate results partway through subscript evaluations can overflow 
to their hearts' content, and you still get the right element in the 
end.

> 
> and signed integers are implementation defined, could "trap" but in reality
> all implementations "silently wraparound".
> It is a point of unsafety though, beyond the more well known
> buffer overflows, leaks, etc.
> 
>  - Jay
> 
>  
> > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Full-range unsigned integers are a language designer's headache, because
> > there are conflicts no matter what you do. The Modula-3 approach is to
> > use the operations in interface Word.i3 (and now Long.i3) on type
> > INTEGER (not CARDINAL, which has only half the range). These apply
> > unsigned interpretation to values of type INTEGER.

The problem with Word.i3 is that expressions involving these integers 
are so unreadable as to be seriously susceptible to error.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 05:03:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 23:03:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
Message-ID: <20100108040333.GB9556@topoi.pooq.com>

On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
> I think your confusion relates to understanding how the language 
> defines "base" types.
> 
> You should understand that INTEGER and LONGINT have *different* base 
> types.  This indicates that they have inherently different 
> representations,

What's implicit in this statment is that all the subranges of INTEGER 
have inherently the same representation.  Why is this inportant?  Are 
there, for example,  places in the language where you have a subrange 
but don't know what the subrange is?

> and indeed, operations on INTEGER and operations on 
> LONGINT are inherently different.

So in the language at present, there is no single type at the top of the 
integer type lattice (and it's not really a lattice).  There are, 
however, two maximal types.  Is this right?

> 
> Every enumeration type similarly has a base type.  If it's range is 
> expressed over INTEGER values then its base type is INTEGER.  If 
> expressed over LONGINT then its base type is LONGINT.
> 
> I don't think I understand the rest of your questions.

Where in the language is it important that INTEGER and LONGINT be 
different base types?  In other words, what advantages does this 
separation convey?

-- hendrik
> 
> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
> 
> > I have some questions as to the constraints that need to be placed on 
> > integral types.  These issues are fundamental to an understanding of the 
> > role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> > about them.
> > 
> > Is there a need for an integer type that can contain all the sizes of 
> > integers that can be handled by the language?  I'll call it TOP just so 
> > I can talk about it easily.
> > 
> > If it is necessary, is TOP only needed to make the language definition 
> > clean and concise?  Conversely, is it necessary for TOP to be available 
> > to programmers?  Is it necessary for TOP to be efficiently implemented, 
> > or implemented at all?
> > 
> > Even if it is not available directly to programmers, are there language 
> > features that require it internally?
> > 
> > Is it necessary that, for every two integer subranges I and J, there 
> > exist an integer range K such that both I and J are subranges of K?
> > 
> > The most commonly used integral type is INTEGER.  It seems to be the 
> > type used by programmers by default when they don't want to think of 
> > the specific range they will need.  But is it necessary for the type 
> > called INTEGER to be TOP?  Or, is there is no maximum implemented 
> > integral type, is it still necessary for INTEGER to be a maximal 
> > integral type?
> > 
> > -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 07:07:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:07:08 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W45DD659513608DE2BE3F86E6700@phx.gbl>


I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case, n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case, 2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0397073c/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 07:41:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:41:09 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W530411D2F9C6E2619BD794E6700@phx.gbl>


[truncated again, I have a knack for
aiming near 80 columns and therefore getting
the period right where the mail software truncates..]




From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 06:07:08 +0000








I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case,
    n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case,
   2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ae9ef910/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 08:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 07:44:53 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
Message-ID: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>


This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.

 

  LONGINT + INTEGER => LONGINT 

  LONGINT - INTEGER => LONGINT 

  LONGINT * INTEGER => LONGINT 

  LONGINT DIV INTEGER => LONGINT 

  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 

  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  

  LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  

  MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

  MAX(INTEGER, LONGINT) => LONGINT  

  LONGINT := INTEGER 

 

Other mixes are less obvious and would require runtime checks.

 

I think the backend will just work but I haven't tried that yet.

 (Truth be told, I can only affectively edit files on NT...)

 

Thoughts?

 

 - Jay 

 

Index: builtinOps/Dec.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
retrieving revision 1.9
diff -u -r1.9 Dec.m3
--- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
+++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
@@ -44,7 +44,7 @@
     IF (NUMBER (ce.args^) > 1) THEN
       IF Type.IsSubtype (t, LInt.T) THEN
         t := Type.Base (Expr.TypeOf (ce.args[1]));
-        IF (t # LInt.T) THEN
+        IF t # LInt.T AND t # Int.T THEN
           Error.Txt (name, "second argument must be a LONGINT");
         END;
       ELSE
Index: builtinOps/Max.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
retrieving revision 1.3
diff -u -r1.3 Max.m3
--- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
+++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
@@ -25,11 +25,14 @@
 
 PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     ta := Type.Base (Expr.TypeOf (ce.args[0]));
     tb := Type.Base (Expr.TypeOf (ce.args[1]));
 
-    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
+    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
+      resultType := LInt.T;
+    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
       Error.Txt (name, "incompatible argument types");
     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
       (* ok *)
@@ -39,7 +42,11 @@
       Error.Txt (name, "wrong argument types");
       ta := Int.T;
     END;
-    ce.type := ta;
+    IF resultType # NIL THEN
+      ce.type := resultType;
+    ELSE
+      ce.type := ta;
+    END;
   END DoCheck;
 
 PROCEDURE Compile (ce: CallExpr.T) =
Index: exprs/AddExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 AddExpr.m3
--- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
+++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -67,6 +67,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -74,8 +75,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
-      p.class := Class.cLINT
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -96,7 +98,11 @@
     ELSE
       ta := Expr.BadOperands ("\'+\'", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/DivExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 DivExpr.m3
--- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,7 +60,7 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF (ta = Int.T) AND (tb = Int.T) THEN
       p.type := Int.T;
-    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.type := LInt.T;
     ELSE
       p.type := Expr.BadOperands ("DIV", ta, tb);
Index: exprs/ModExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 ModExpr.m3
--- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,6 +60,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -67,8 +68,18 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
+
     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
       p.class := Class.cLINT;
+
+    (* The result of MOD cannot be higher than either of its inputs.
+     * small divided by big is 0 remainder small
+     * big divided by small has a remainder of at most small
+     *)
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cINT;
+      resultType := Int.T;
+
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -78,7 +89,11 @@
     ELSE p.class := Class.cERR;  ta := Int.T;
       ta := Expr.BadOperands ("MOD", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/MultiplyExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 MultiplyExpr.m3
--- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
+++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -66,6 +66,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -73,8 +74,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
       p.class := cINT;
-    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := cLINT;
+      resultType := LInt.T;
     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
       p.class := cREAL;
     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
@@ -90,7 +92,11 @@
       ta := Expr.BadOperands ("\'*\'", ta, tb);
       p.class := cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/SubtractExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
retrieving revision 1.4
diff -u -r1.4 SubtractExpr.m3
--- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
+++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -73,6 +73,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -80,8 +81,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -113,7 +115,11 @@
       ta := Expr.BadOperands ("\'-\'", ta, tb);
       p.class := Class.cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: types/Type.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
retrieving revision 1.8
diff -u -r1.8 Type.m3
--- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
+++ types/Type.m3 8 Jan 2010 07:35:43 -0000
@@ -543,6 +543,10 @@
     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
       RETURN TRUE;
     ELSIF IsOrdinal (a) THEN
+      (* INTEGER is assignable to LONGINT *)
+      IF a = LInt.T AND b = Int.T THEN
+        RETURN TRUE;
+      END;
       (* ordinal types:  OK if there is a common supertype
          and they have at least one member in common. *)
       IF IsEqual (Base(a), Base(b), NIL)






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/49a9d43f/attachment.html>

From wagner at elegosoft.com  Fri Jan  8 11:44:48 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 11:44:48 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
Message-ID: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>
>> Well, I don't think that should be any practical problem right now,
>
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems, so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>
> I think I am now persuaded LONGINT should stay.  But, I don't   
> understand what "incompatibly change the internal file length
> type (with due care and consideration of course)" means?

I only just got round to reading all those mails.

I meant changing the file lengths and offsets in all our libraries,
like Rd/Wr. Basically what Jay has started on right away ;-)

I agree that this should be done in a feature branch though.
Changes should be reviewed.
Regression tests need to be run on all platforms.

And of course we should all more or less agree that we want to do that.
I think it has been a mistake that we haven't been able to support
long file sizes in a consistent way throughout our code. Of course this
problem will vanish in some years when everybody is using 64 bit platforms.
But for embedded programming for example 32 bit processors may remain
useful and in use much longer.

I'm not sure if we should support assignability between INTEGER and
LONGINT, as Rodney's original proposal did. Probably yes, but I must
admit that I've been too little engaged in language theory for years now
so that I cannot really oversee the impacts.

Files with sizes larger than 4 GB get more and more common. Just think
of DVD images for example. And I don't think that it will be really
appreciated by users of M3 applications that they immediately crash
just because one has opened a directory browser based on the distributed
libraries :-)

Just my opinion of course. I don't really understand why you are so
drastically opposing LONGINT suddenly. Probably I haven't been able to
follow some of the arguments.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan  8 12:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 11:13:58 +0000
Subject: [M3devel] latest longint file size diffs
Message-ID: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>


Attached is my latest work here.
With the compiler changes (in the diff), I was able to
elminate most uses of VAL(expr, LONGINT).
There's something slightly off such that I had
to add a very small number, like two.

 

 

The compiler change is newer than earlier.

For example you can now assign CARDINAL to LONGINT.

I didn't do it, but you should also be able to add/subtract/etc.

mixing CARDINAL and LONGINT.

 


FOR statements also don't allow the level of mixing
that they should.


 

I'm hoping to get agreement soon just from the diffs

but if necessary I'll look how to create a branch.

My general worry about branches is developers just

go off on their own in a branch and it's impossible to

get anyone to look at it, they are busy enough with one branch,

let alone multiple..

 


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif8.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment.txt>

From wagner at elegosoft.com  Fri Jan  8 12:32:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 12:32:24 +0100
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <20100108123224.rryfffs1kw40k4sk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>
> The compiler change is newer than earlier.
>
> For example you can now assign CARDINAL to LONGINT.
>
> I didn't do it, but you should also be able to add/subtract/etc.
>
> mixing CARDINAL and LONGINT.
>
> FOR statements also don't allow the level of mixing
> that they should.
>
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
>
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..

I think in this case it makes sense, as we need to run full regression
tests on all target platforms IMO.

You just should mark the start of the branch with

   cvs tag branch_feature_longint_offset_start

then create the branch tag itself

   cvs tag -b branch_feature_longint_offset

update your workspace to that branch

   cvs up -r branch_feature_longint_offset

and finally commit the changes

   cvs commit

This all assumes you've started on a fairly recent trunk and
there are no conflicts.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Fri Jan  8 15:28:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 09:28:11 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <20100108142811.GA14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:44:53AM +0000, Jay K wrote:
> 
> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
> 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

No, it was correct.

    MIN( 5, -1000000000000000L) = -1000000000000000L
    So the result really needs to be LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:08:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:08:20 -0500
Subject: [M3devel] longint..revisited?
In-Reply-To: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
References: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
Message-ID: <49C29A52-F861-4875-A6B0-B77758F08781@cs.purdue.edu>

Again, this proposal raises serious problems regarding implicit coercions, against the design principals of the Modula-3 type system.

On 7 Jan 2010, at 22:35, Jay K wrote:

> I can't find Rodney's proposal but I think I understand
> a lot of it from today's mail.
> 
> 
> Can we revisit this?
> 
> 
> My understanding is that Rodney's proposal
> deems INTEGER assignable to LONGINT,
> and vice versa, and that assignments of LONGINT
> to INTEGER undergo runtime range checks,
> can raise exceptions.
> 
> 
> I assume it also follows that:
> 
> 
> LONGINT can be added/subtracted/modded to INTEGER,
> yielding LONGINT.
> 
> 
> INTEGER MOD LONGINT would range check the LONGINT.
> 
> 
> INC/DEC(LONGINT, INTEGER) would just work
> 
> 
> INC/DEC(INTEGER, LONGINT) would range check.
> 
> 
> The downside is that the chance for failure would be
> silently injected into various places.
> 
> 
> Another proposal would be that INTEGER is assignable to LONGINT,
> but not vice versa. I really don't see why not.
> 
> 
>    LONGINT := INTEGER  
>    LONGINT + INTEGER => LONGINT  
>    LONGINT - INTEGER => LONGINT  
>    LONGINT * INTEGER => LONGINT  
>    LONGINT / INTEGER => LONGINT  
>    LONGINT MOD INTEGER => INTEGER (think about it) 
>    INC(LONGINT, INTEGER)
>    DEC(LONGINT, INTEGER)
> 
> 
> all seem very reasonable.
> 
> 
>  - Jay
> 



From hosking at cs.purdue.edu  Fri Jan  8 17:17:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:17:07 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <D75FD9A8-3049-4942-95BD-B9DE79920AFA@cs.purdue.edu>

On 7 Jan 2010, at 23:03, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>> 
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?

A subrange always has a known base type.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?

Correct.  Here is the subtype rule for ordinals:

For ordinal types T and U, we have T <: U if they have the same base type and every member of T is a member of U. That is, subtyping on ordinal types reflects the subset relation on the value sets.

Currently, we have two possible base types for ordinals: INTEGER and LONGINT.  They are distinct, unrelated types.

>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>> 
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

It conveys specific information about what specific machine values and operations implement them.  They can (and usually do) require different code to operate on them.  From a programmer's perspective, I know that every operation on INTEGER base values will involve *natural* integer arithmetic.  For LONGINT I am much less sure, and may require even calling a library to perform the operation (if the machine doesn't naturally support LONGINT).

> 
> -- hendrik
>> 
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>> 
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>> 
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>> 
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>> 
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>> 
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>> 
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>> 
>>> -- hendrik
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/77e170c0/attachment.html>

From hosking at cs.purdue.edu  Fri Jan  8 17:26:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:26:07 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>

On 7 Jan 2010, at 20:35, Rodney M. Bates wrote:

> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time.  That would have been October
> of 2007.  I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type.

LONGINT *is* an ordinal type.  It just has a different base type than INTEGER so it is not subtype-related.

> This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other.  This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.

The question really is what should the top type be?

We don't want to have all ordinal types base themselves on LONGINT because then they will all incur LONGINT operations (which may be more expensive than the "natural" INTEGER operations).

> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types.  Most places in the
> language require only assignability, not type equality.  Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.

I really don't see how to accomodate this within the Modula-3 type system and its existing rules.

Now, we could introduce an explicit rule that says INTEGER <: LONGINT.  Then we can freely assign INTEGER values to LONGINT values.

> A consequence of existing rules is that there would be, if necessary,
> runtime value checks.  In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.

Allowing assignment of LONGINT to INTEGER requires an implicit range check on assignment, but perhaps that is OK.

> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer.  A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT.  But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.

In this case I prefer the need for explicit conversion just so that programmers are made aware.

> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable.  This could, of course be fixed in the language,
> but I would prefer making the two types assignable.

No, there is no contradiction in the current implementation.  It treats subranges of LONGINT as having base type LONGINT.   So they are unrelated to INTEGER based types.

> 
> 
> 
> 
> Jay K wrote:
>> 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



From hosking at cs.purdue.edu  Fri Jan  8 17:27:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:27:36 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
	<4B468C63.9050404@lcwb.coop>
Message-ID: <F1B2BC0B-A862-4361-8E39-88D6B0061444@cs.purdue.edu>

Agreed.

On 7 Jan 2010, at 20:37, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> On 7 Jan 2010, at 06:22, Jay K wrote:
>>> 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.
>> Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.
> Indeed, Modula-3 has no implicit casts at all.  But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability.  A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too).  If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0de78432/attachment.html>

From hosking at cs.purdue.edu  Fri Jan  8 17:29:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:29:33 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <303FF080-4129-4669-B264-151C32DE559F@cs.purdue.edu>

On 7 Jan 2010, at 22:53, hendrik at topoi.pooq.com wrote:

> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?

We do have + defined on LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:36:18 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>

I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?

Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).

On 8 Jan 2010, at 05:44, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>> 
>>> Well, I don't think that should be any practical problem right now,
>> 
>>> shouldn't it? But 32 bit offsets have been overcome for years even
>>> on 32 bit systems, so I definitely think we should keep the LONGINT
>>> type and even try to incompatibly change the internal file length
>>> type (with due care and consideration of course).
>> 
>> I think I am now persuaded LONGINT should stay.  But, I don't  understand what "incompatibly change the internal file length
>> type (with due care and consideration of course)" means?
> 
> I only just got round to reading all those mails.
> 
> I meant changing the file lengths and offsets in all our libraries,
> like Rd/Wr. Basically what Jay has started on right away ;-)
> 
> I agree that this should be done in a feature branch though.
> Changes should be reviewed.
> Regression tests need to be run on all platforms.
> 
> And of course we should all more or less agree that we want to do that.
> I think it has been a mistake that we haven't been able to support
> long file sizes in a consistent way throughout our code. Of course this
> problem will vanish in some years when everybody is using 64 bit platforms.
> But for embedded programming for example 32 bit processors may remain
> useful and in use much longer.
> 
> I'm not sure if we should support assignability between INTEGER and
> LONGINT, as Rodney's original proposal did. Probably yes, but I must
> admit that I've been too little engaged in language theory for years now
> so that I cannot really oversee the impacts.
> 
> Files with sizes larger than 4 GB get more and more common. Just think
> of DVD images for example. And I don't think that it will be really
> appreciated by users of M3 applications that they immediately crash
> just because one has opened a directory browser based on the distributed
> libraries :-)
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Fri Jan  8 18:00:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 12:00:01 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	? T <: U, or
	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	? T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 17:49:06 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:49:06 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <4B476202.7010004@lcwb.coop>



Jay K wrote:
> I don't believe currently "10" is assignable
> (or comparable) to LONGINT.
> You have to use 10L.

This is a bit subtle, and I should have been more explicit.  I didn't
mean the Modula-3 expression "10", I meant just the value ten.

 From 2.2:
------------------------------------------------------------------------------
Every expression has a unique type, but a value can be a member of many types.
For example, the value 6 is a member of both [0..9] and
INTEGER.  It would be ambiguous to talk about ``the type of a value''.
Thus the phrase ``type of x'' means ``type of the expression
x'', while ``x is a member of T'' means ``the value of
x is a member of T''.
------------------------------------------------------------------------------

The snippets of Modula-3 _code_ "10" and "10L"  are expressions.  Each has
both a value (which is the same) and a type (which is different).  The value
10 is a member of both types.

The 2.2 quote was written before we had LONGINT and its literals, so referring to
the value 6 wasn't as unclear.  Maybe it would be better to say that the
value 10 when stored in an INTEGER is a different abstract value than
10 stored in a LONGINT.  Then the two types would have disjoint value
sets.  But I think that would be a serious contradiction to the way
subranges work.

>  
>  
> I do believe any INTEGER or CARDINAL expression should be assignable
> to LONGINT, but I don't think it is implemented that way currently.
>  
>  
> And, then, I wonder if subranges are all we need, no LONGINT.
> But I don't understand the language well enough.
>  
>  
>  - Jay
> 


From rodney_bates at lcwb.coop  Fri Jan  8 17:53:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:53:42 -0600
Subject: [M3devel] LONGINT, my original proposal
Message-ID: <4B476316.4000005@lcwb.coop>

Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 64-bitProposal
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.ksh>

From rodney_bates at lcwb.coop  Fri Jan  8 18:10:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:10:28 -0600
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <4B476704.8010403@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>>
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?
> 

No, this is not implicit.  An implementation can (and probably should)
store a variable of a subrange type in a byte or two, if sufficient to
hold the range.  When the programmer assigns this to an INTEGER, the
compiler will have to make a representation change.  But is has the
necessary information to do this without huge trouble.

Similarly, the implementation _must_ store a subrange in a restricted
size field when it is a field or array element having a BITS type
derived from a subrange type.

What's unique about Modula-3 is that such representation changes are
left to the compiler, while the language merely views values as
sometimes belonging to more than one type, and allows such values to be
assigned when so.  The usual approach in other languages is to elevate
the representation change from a machine-level matter to a language-
level matter by treating it as an implicit type change in addition to
a representation change.  The result is always a lot of unnecessary
complexity in the language.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?
> 
>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>>
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

One thing that is very much needed in a language (not the only thing)
is a type that always matches the implementation's native arithmetic
size, which is most efficient.  If you don't distinguish this type,
it becomes either impossible or horribly convoluted to define arithmetic
so native machine arithmetic can be usually used where possible,
but multi-word arithmetic will be used where needed.

> 
> -- hendrik
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>>
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>>
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>>
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>>
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>>
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>>
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>>
>>> -- hendrik
> 


From mika at async.async.caltech.edu  Fri Jan  8 18:34:12 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 09:34:12 -0800
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu> 
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <20100108173412.8531F1A207A@async.async.caltech.edu>

Tony Hosking writes:
...
>A type T is assignable to a type U if:
>
>	=95 T <: U, or
>	=95 U <: T and T is an array or a reference type other than =
>ADDRESS (This restriction is lifted in unsafe modules.), or
>	=95 T and U are ordinal types with at least one member in =
>common.
>
>This suggests that we don't really need to say that INTEGER <: LONGINT.
>
>We can simply rely on the third clause regarding their both being =
>ordinal types with at least one member in common.  Then assignment =
>simply needs to test that the values are in range.
>

Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
the same "member"?

By a similar argument, you could make REAL and LONGREAL assignable.
Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
the same bit patterns, same as 0 and 0L for that matter, and I can add
that the way you do single-precision floating point on Alpha is by zeroing
a big chunk in the middle of your double-precision fp registers...)

I think I am with you on removing LONGINT from the language.  The proper
way of handling file sizes (or anything else that might be a bigger number
than a machine word) is through abstraction.  I have a suspicion that it's
probably a severe micro-optimization to worry about the efficiency of
operations on file sizes.  The thought that someone is adding automatic
type conversion to Modula-3, a la C, makes me feel slightly sick to
my stomach...

I confess that my position is influenced by the fact that I have written
many programs that generate Modula-3 code as an "intermediate language".
I really really really need M3 to be easy to understand to get this to
work well.  Also being able to parse interfaces and know precisely what
they mean is important to me.  If the rules start getting sloppy.. that
would really upset me.  On the other hand this means that if I'm faced
with a problem that doesn't really fit into M3 well, say, working in
arithmetic mod 2^(wordsize), my first instinct is not to demand changes
to the language definition but to write a code generator that takes
appropriate infix (or maybe more likely prefix) code and turns it into
the appropriate calls through the Word interface.  It's a pain, yes, 
but in the long run that's the right way, because you can do so much
more with that approach than just unsigned integers.

    Mika


From rcolebur at SCIRES.COM  Fri Jan  8 18:36:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 12:36:50 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA67@ATLEX02-SRV.SCIRES.LOCAL>

I agree with Tony that we need a clean proposal to debate.  I also agree with keeping the spirit of the Modula-3 language and type rules.

Randy Coleburn

-----Original Message-----
From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Friday, January 08, 2010 12:00 PM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] mixing INTEGER and LONGINT?

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	* T <: U, or
	* U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	* T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 18:33:52 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:33:52 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <4B476C80.4090601@lcwb.coop>



Jay K wrote:
> This simple diff in the front end allows the "obvious" mixing of INTEGER 
> and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT
>   LONGINT - INTEGER => LONGINT
>   LONGINT * INTEGER => LONGINT
>   LONGINT DIV INTEGER => LONGINT
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should 
> be INTEGER)
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct) 
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct) 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be 
> INTEGER) 
>   MAX(INTEGER, LONGINT) => LONGINT 
>   LONGINT := INTEGER

Making INTEGER and LONGINT mutually assignable (or even one-way
assignability of INTEGER to LONGINT) implies all of the above.
The arithmetic operators are defined as generalizations of Modula-3
procedures, with parameters of VALUE mode.  And the rule for VALUE
requires only that the actual be assignable to the formal, not
have identical type.  This is what I originally proposed.

Actually, with LONGINT in the picture, the arithmetic operators have
to be defined more carefully, in order to avoid or remove ambiguity in
resolution of builtin overloaded arithmetic operators. Particularly,
we have to eliminate the possibility that, e.g., an expression of the form
INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
operator, by assignability of INTEGER to LONGINT.  This would completely
the efficiency of native machine arithmetic.

Whatever we do, I feel very strongly that we should preserve consistency
with both the existing rules that assignment statements and passing
VALUE parameters require assignability.  That means that explicitly coded
VAL/ORD functions will be required either in both assignments and mixed
arithmetic, or neither.  The same applies to a number of other places
that require assignability.


>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 


From hosking at cs.purdue.edu  Fri Jan  8 19:00:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:00:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:

> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.

We have this.

> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.

>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.

> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.

We have this right now.

>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!

>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.

The current implementation illustrates that this is not a problem.

> 4. LONGINT # INTEGER.

We have this right now.

>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.

Agreed.

> 5. LONGINT is an ordinal type. 

We have this right now.

>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.

> 6. Neither LONGINT nor INTEGER is a subtype of the other.  

We have this right now.

>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.

Agreed.

> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.

We have this.

> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.

>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.

Agreed.

>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.

>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.

OK.  I think I see how to implement this...

> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.

> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.

We already support this.

> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.

Already supported.

> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.

>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.

> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.	

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.

> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.

This is the current implementation.

>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  

Agreed.

>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.

This is the current implementation.

>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.

Agreed.

> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).

> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation. 

> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.

Agreed.

> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.

>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).

> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range. 

This is the current implementation.

> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.

This is the current implementation.

> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here. 

This is the current implementation.

> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.

This is the current implementation.

> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.

>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.

Until we see the need I hesitate to implement it.

>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.

Agreed.

> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.

I just added these.

>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0c578d06/attachment.html>

From hosking at cs.purdue.edu  Fri Jan  8 19:08:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:08:46 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <3BB40DAB-60F8-461E-A9C8-FF80A81F74A8@cs.purdue.edu>

On 8 Jan 2010, at 12:34, Mika Nystrom wrote:

> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>> 
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>> 
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>> 
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>> 
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?

Yes, we could potentially do that.  It is straightforward because their significant bits are the same.

> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)

Not so reasonable, because their bits are different and need explicit conversion.

> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree with those sentiments.  While LONGINT can be accomodated (and more elegantly if we evolve towards Rodney's proposal -- see my other e-mail) I am still not convinced that it is worth all the complications.  If LONGINT is there only for large file sizes then abstraction is a *much* better way to go.  Why add a general-purpose type for a one-off use-case?

> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.

Agreed.

From hosking at cs.purdue.edu  Fri Jan  8 19:19:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:19:58 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B476C80.4090601@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<4B476C80.4090601@lcwb.coop>
Message-ID: <18553308-F36F-44B9-857F-E53B859B02C0@cs.purdue.edu>

To summarise the discussion so far...

1. Do we really need LONGINT?  Some have expressed a desire for it.  The only use-case so far is large file sizes.

2. If we do need LONGINT then Rodney's proposal seems sound apart from the question of resolution of the builtin overloaded arithmetic operators.  Rodney's proposal is that they resolve to the maximal type of their operands.  Jay, I am very concerned about your definitions for MOD/DIV below because I think they are inherently unintuitive (witness your own claims of "subtlety" -- Modula-3 should not ever have subtle semantics!).  I forget what the rules for C happen to be... (with good reason since I've never wanted to try to remember them and avoid mixed type operands like the plague!).  So, do I hear strong arguments for or against mixed type integer operands?

On 8 Jan 2010, at 12:33, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>   LONGINT + INTEGER => LONGINT
>>  LONGINT - INTEGER => LONGINT
>>  LONGINT * INTEGER => LONGINT
>>  LONGINT DIV INTEGER => LONGINT
>>  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)
>>  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)   MAX(INTEGER, LONGINT) => LONGINT   LONGINT := INTEGER
> 
> Making INTEGER and LONGINT mutually assignable (or even one-way
> assignability of INTEGER to LONGINT) implies all of the above.
> The arithmetic operators are defined as generalizations of Modula-3
> procedures, with parameters of VALUE mode.  And the rule for VALUE
> requires only that the actual be assignable to the formal, not
> have identical type.  This is what I originally proposed.
> 
> Actually, with LONGINT in the picture, the arithmetic operators have
> to be defined more carefully, in order to avoid or remove ambiguity in
> resolution of builtin overloaded arithmetic operators. Particularly,
> we have to eliminate the possibility that, e.g., an expression of the form
> INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
> operator, by assignability of INTEGER to LONGINT.  This would completely
> the efficiency of native machine arithmetic.
> 
> Whatever we do, I feel very strongly that we should preserve consistency
> with both the existing rules that assignment statements and passing
> VALUE parameters require assignability.  That means that explicitly coded
> VAL/ORD functions will be required either in both assignments and mixed
> arithmetic, or neither.  The same applies to a number of other places
> that require assignability.
> 
> 
>> Other mixes are less obvious and would require runtime checks.
>> I think the backend will just work but I haven't tried that yet.
>> (Truth be told, I can only affectively edit files on NT...)
>> Thoughts?
>>  - Jay
>> Index: builtinOps/Dec.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
>> retrieving revision 1.9
>> diff -u -r1.9 Dec.m3
>> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
>> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
>> @@ -44,7 +44,7 @@
>>     IF (NUMBER (ce.args^) > 1) THEN
>>       IF Type.IsSubtype (t, LInt.T) THEN
>>         t := Type.Base (Expr.TypeOf (ce.args[1]));
>> -        IF (t # LInt.T) THEN
>> +        IF t # LInt.T AND t # Int.T THEN
>>           Error.Txt (name, "second argument must be a LONGINT");
>>         END;
>>       ELSE
>> Index: builtinOps/Max.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 Max.m3
>> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
>> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
>> @@ -25,11 +25,14 @@
>>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     ta := Type.Base (Expr.TypeOf (ce.args[0]));
>>     tb := Type.Base (Expr.TypeOf (ce.args[1]));
>> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
>> +      resultType := LInt.T;
>> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>>       Error.Txt (name, "incompatible argument types");
>>     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>>       (* ok *)
>> @@ -39,7 +42,11 @@
>>       Error.Txt (name, "wrong argument types");
>>       ta := Int.T;
>>     END;
>> -    ce.type := ta;
>> +    IF resultType # NIL THEN
>> +      ce.type := resultType;
>> +    ELSE
>> +      ce.type := ta;
>> +    END;
>>   END DoCheck;
>>  PROCEDURE Compile (ce: CallExpr.T) =
>> Index: exprs/AddExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 AddExpr.m3
>> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
>> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -67,6 +67,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -74,8 +75,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
>> -      p.class := Class.cLINT
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -96,7 +98,11 @@
>>     ELSE
>>       ta := Expr.BadOperands ("\'+\'", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/DivExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 DivExpr.m3
>> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,7 +60,7 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF (ta = Int.T) AND (tb = Int.T) THEN
>>       p.type := Int.T;
>> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.type := LInt.T;
>>     ELSE
>>       p.type := Expr.BadOperands ("DIV", ta, tb);
>> Index: exprs/ModExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 ModExpr.m3
>> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,6 +60,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -67,8 +68,18 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> +
>>     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>>       p.class := Class.cLINT;
>> +
>> +    (* The result of MOD cannot be higher than either of its inputs.
>> +     * small divided by big is 0 remainder small
>> +     * big divided by small has a remainder of at most small
>> +     *)
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cINT;
>> +      resultType := Int.T;
>> +
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -78,7 +89,11 @@
>>     ELSE p.class := Class.cERR;  ta := Int.T;
>>       ta := Expr.BadOperands ("MOD", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/MultiplyExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 MultiplyExpr.m3
>> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
>> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -66,6 +66,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -73,8 +74,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>>       p.class := cINT;
>> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>>       p.class := cREAL;
>>     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
>> @@ -90,7 +92,11 @@
>>       ta := Expr.BadOperands ("\'*\'", ta, tb);
>>       p.class := cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/SubtractExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
>> retrieving revision 1.4
>> diff -u -r1.4 SubtractExpr.m3
>> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
>> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -73,6 +73,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -80,8 +81,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -113,7 +115,11 @@
>>       ta := Expr.BadOperands ("\'-\'", ta, tb);
>>       p.class := Class.cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: types/Type.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
>> retrieving revision 1.8
>> diff -u -r1.8 Type.m3
>> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
>> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
>> @@ -543,6 +543,10 @@
>>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>>       RETURN TRUE;
>>     ELSIF IsOrdinal (a) THEN
>> +      (* INTEGER is assignable to LONGINT *)
>> +      IF a = LInt.T AND b = Int.T THEN
>> +        RETURN TRUE;
>> +      END;
>>       (* ordinal types:  OK if there is a common supertype
>>          and they have at least one member in common. *)
>>       IF IsEqual (Base(a), Base(b), NIL)

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

From rcolebur at SCIRES.COM  Fri Jan  8 19:20:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 13:20:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>

Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in "cm3/doc" and the language posters in "cm3/doc/src_reports".

Randy Coleburn


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Friday, January 08, 2010 1:01 PM
To: Rodney M. Bates
Cc: m3devel
Subject: Re: [M3devel] LONGINT, my original proposal

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:


Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
A proposal for Modula-3 language changes to support an integer type
larger than the native size of the target processor.

This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.

Actual statements about the language are numbered.  Comments are
indented more deeply, following a numbered item they apply to.  Some
numbered items are labeled "NO CHANGE", and merely call attention to
the lack of a change, where it is relevant or calls for comment.

Changes to the language proper:

1. There is a new builtin type named LONGINT.

We have this.


2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


     The intent is that INTEGER will remain as the native integer
     size on the implemented processor.  LONGINT might be bigger, but
     not necessarily.  Typically, on a 32-bit processor, LONGINT
     would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.


3. There are new literals of type LONGINT, denoted by following a
   nonempty sequence of digits by either 'l' or 'L'.

We have this right now.


     Having distinctly spelled literals preserves Modula-3's clean
     system of referentially transparent typing, i.e, the type of
     every expression is determined by the expression alone, without
     regard to how it is used.  The 3 floating point types already
     follow this principle.  Literals of ambiguous type, combined
     with a system of implicit conversions taken from the context
     would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!


     I believe intuitively that Id, LOCK, and LOOP are not members of
     FOLLOW(Number), but need to check this mechanically.  It would
     mean that the new literals can not undermine any existing,
     compilable code.

The current implementation illustrates that this is not a problem.


4. LONGINT # INTEGER.

We have this right now.


     This is true regardless of whether their ranges are equal.  This
     keeps the typing independent of the implementation.  Doing
     otherwise could be a portability nightmare.

Agreed.


5. LONGINT is an ordinal type.

We have this right now.


     This means the existing rules of assignability will allow
     assignment between LONGINT and its subtypes and INTEGER and its
     subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.


6. Neither LONGINT nor INTEGER is a subtype of the other.

We have this right now.


     This is true regardless of whether their ranges are equal, in
     part for the same reason the types are unequal.

     Note that, for ordinal types, assignability doesn't actually use
     the subtype relation.  In fact, the one place I can find in the
     present language where subtypes matter for ordinal types is in
     the definition of signatures of operators, etc.  In 2.6.1,
     paragraph 5, operands must have a subtype of the type specified.
     Keeping LONGINT and INTEGER subtype-unrelated keeps this
     statement unambiguous and allows easy specification of the
     operators.

Agreed.


7. Prefix operators +, -, and ABS can take an operand having a
   subtype of LONGINT, in which case, their result has type LONGINT.

We have this.


8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.
   If either is a subtype of LONGINT, the result has type LONGINT,
   otherwise INTEGER.  The result is correct (i.e., no overflow
   occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.


     With assignment between different subranges, Modula-3 takes the
     view that this is not an implied type conversion at all.
     Instead, the rules have the effect that if the value is a member
     of the LHS type, then it's OK.  I think this is a brilliant
     piece of language design.  Compare to the many pages of
     description that C++ and Java require to define implied type
     conversions in assignments, and they only have a few
     integer-like types, whereas current Modula-3 has, typically,
     ~2^31 subrange types involved.  It's also less
     implementation-oriented, because it doesn't appeal to bit
     representations, etc.

Agreed.


     I resisted allowing mixed sizes of operands, until I realized we
     can do the same thing with operators as with assignment, i.e.,
     just require result values to be in range, without calling
     anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.


     A compiler can implement this by just doing the arithmetic in
     the same size as the result type.  This means if both operands
     are subtypes of INTEGER, (which will always be the case with
     existing code,) then the native arithmetic will be used, without
     loss of efficiency.

OK.  I think I see how to implement this...


9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.

     Again, a compiler can figure out how to generate code for this,
     with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.


10. The first parameter to FLOAT can have a subtype of either INTEGER
   or LONGINT.

We already support this.


11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
   parameter, which can be either LONGINT or INTEGER, and which
   specifies the result type of the operation.  If omitted, it
   defaults to INTEGER.  The result has this type.

     The default preserves existing code.

Already supported.


12. The result type of ORD is LONGINT if the parameter is a subtype of
   LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.


     There is really not much programmer value in applying ORD to a
     subtype of either INTEGER or LONGINT, since this is just an
     identity on the value.  It would provide an explicit, widening
     type conversion, and NARROW won't accomplish this, because it is
     only defined on reference types.  However, this rule provides
     consistency, and maybe would simplify some machine-generated
     source code scheme.

     This fails to support an implementation's effort to expand the
     number of values of an enumeration type beyond the current
     implied limitation of the positive native word values.  How
     tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.


13. The first parameter to VAL can be a subtype of either INTEGER or
   LONGINT.

     Beside generalizing the existing uses of VAL, this also allows
     explicit conversions between LONGINT and INTEGER, if there is
     any need for them.

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.


14. (NO CHANGE) The safe definitions of INC and DEC do not change.

     As a consequence of the changes to +, -, ORD, and VAL, the
     existing equivalent WITH-statement definition will generalize to
     mixes of any ordinal type for the first parameter and a subtype
     of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?


16. Neither LONGINT, nor any subtype thereof, can be used as the index
   type of an array type.

This is the current implementation.


     One could think about allowing this, but it would require a lot
     of other things to be generalized, and is unlikely to be of much
     use.

Agreed.


     After the world's having had to learn twice the hard way, what a
     mess that comes from addresses that are larger than the native
     arithmetic size, we are unlikely to see it again.  So, the only
     ways a longer LONGINT index type could be of any use are: 1)
     arrays of elements no bigger than a byte, that occupy more than
     half the entire addressable memory, and you want to avoid
     negative index values, or 2) arrays of packed elements less than
     byte size that occupy at least one eighth of the memory (or some
     mixture thereof).  All these cases also can occur only when
     using close to the maximum addressable virtual memory.  Not very
     likely.

     If you really need 64-bit array subscripts, you will have to use
     an implementation whose native size is 64 bits.

     This also avoids generalizing SUBARRAY, several procedures in
     required interface TEXT, more extensive generalization of
     NUMBER, etc.

17. Neither LONGINT, nor any subtype thereof, can be used as the base
   type of a set type.

This is the current implementation.


     This is similar to the array index limitation.  Sets on base
     types of long range are very unlikely, as they would be too bit.
     The assignability rules should make subranges of INTEGER
     relatively easy to use as set base types instead of short
     subranges of LONGINT.  This also obviates generalizing IN.

Agreed.


18. The result type of NUMBER is LONGCARD if its parameter is a
   subtype of LONGINT, otherwise INTEGER, as currently.

     NUMBER has always had the messy problem that its correct value
     can lie beyond the upper limit of its result type CARDINAL.
     Fortunately, it is rare to use it in cases where this happens.
     The expanded definition still has the equivalent problem, but it
     seems even less likely to actually happen.

     One could consider making NUMBER always return a LONGCARD, which
     would fix the problem for parameters that are INTEGER, but that
     would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).


19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation.


     If you really need 64-bit sizes or typecodes, you will have to
     use an implementation whose native size is 64 bits.

Agreed.


20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.


     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


Changes to required (AKA standard) interfaces:

21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
   Word.Rotate, and the CARDINAL parameters of Word.Extract and
   Word.Insert are unchanged.

     These are bit numbers.  There is no need for a longer range.

This is the current implementation.


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?


     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.

This is the current implementation.


23. (NO CHANGE) The Base and Precision values in required interfaces
   Real, LongReal, and Extended, keep the type INTEGER.

      There is no need for increased value range here.

This is the current implementation.


24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
    and Float.ILogb, whose result type is INTEGER, do not have LONGINT
    counterparts.

      It is difficult to imagine these values needing greater range.

This is the current implementation.


25. Fmt has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


26. Lex has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


27. There is a new required interface named LongAddress.  It is UNSAFE
   and contains procedures that are equivalents for the 5 unsafe
   ADDRESS arithmetic operations, with LONGINT substituted in place
   of INTEGER in their signatures.  These are given in 2.7 and
   include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.


     It is remotely conceivable that there could be a target whose
     native address size is longer than its native integer size
     (unlike the reverse.)  In such a case, these operations might be
     needed.

Until we see the need I hesitate to implement it.


     Four of them could be accommodated by just generalizing the
     INTEGER parameter to allow either INTEGER or LONGINT.  The
     remaining operator subtracts two ADDRESS operands and returns an
     INTEGER.  This can't be generalized using Modula-3's existing
     pattern of overload resolution of builtin operations.
     Redefining it to always do LONGINT arithmetic would violate the
     existing efficiency criterion.  Two separate operations are
     needed.

     This solution avoids complexity in the language proper, while
     still accommodating a rare requirement.  It could probably be
     left unimplemented unless/until such a target actually happens.

Agreed.


Changes to useful interfaces:

28. IO has new procedures PutLongInt and GetLongInt, parallel to
   PutInt and GetInt.

I just added these.


     I have not looked systematically at all the useful interfaces
     for other places that use CARDINAL and INTEGER and might need to
     be generalized.  (Can anyone point to a tool that will grep
     files in .ps or .pdf format, or something equivalent?)

     Note that changes in nonrequired interfaces should be
     implementable just by writing new/modified library code, without
     additional help from the compiler.

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

From hosking at cs.purdue.edu  Fri Jan  8 19:25:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:25:10 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <4020F84F-CF80-4C0B-8586-FD7D7AD8F052@cs.purdue.edu>

I've already made changes to cm3/doc/reference that match the current implementation (no implicit assignability).  I'm happy to adjust that to match what we eventually implement.

On 8 Jan 2010, at 13:20, Randy Coleburn wrote:

> Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in ?cm3/doc? and the language posters in ?cm3/doc/src_reports?.
>  
> Randy Coleburn
> 
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Friday, January 08, 2010 1:01 PM
> To: Rodney M. Bates
> Cc: m3devel
> Subject: Re: [M3devel] LONGINT, my original proposal
>  
> We already have much of this, but not all.  Notes below...
>  
> I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.
>  
> I am looking into making the changes to the current implementation that will bring this into being.
>  
> On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:
> 
> 
> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.
>  
> We have this.
> 
> 
> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>  
> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.
>  
> This is what we currently have.
> 
> 
> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.
>  
> We have this right now.
> 
> 
>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).
>  
> I wholeheartedly agree!
> 
> 
>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.
>  
> The current implementation illustrates that this is not a problem.
> 
> 
> 4. LONGINT # INTEGER.
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.
>  
> Agreed.
> 
> 
> 5. LONGINT is an ordinal type.
>  
> We have this right now.
> 
> 
>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.
>  
> I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.
> 
> 
> 6. Neither LONGINT nor INTEGER is a subtype of the other.  
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.
>  
> Agreed.
> 
> 
> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.
>  
> We have this.
> 
> 
> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.
>  
> I am uneasy about mixing parameter types in this way.
> I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.
> 
> 
>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.
>  
> Agreed.
> 
> 
>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.
>  
> This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.
> 
> 
>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.
>  
> OK.  I think I see how to implement this...
> 
> 
> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.
>  
> Same as above.  I think it can be implemented.
> 
> 
> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.
>  
> We already support this.
> 
> 
> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.
>  
> Already supported.
> 
> 
> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.
>  
> The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
> If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.
> 
> 
>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.
>  
> I see no problem with the maximum enumeration type values being restricted to natural integers.
> 
> 
> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.
>  
> The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
> Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.
> 
> 
> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.
>  
> [Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
> The current implementation does not allow mixing INTEGER/LONGINT operand and increments.
>  
> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.
>  
> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> 
> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.
>  
> This is the current implementation.
> 
> 
>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  
>  
> Agreed.
> 
> 
>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.
>  
> This is the current implementation.
> 
> 
>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.
>  
> Agreed.
> 
> 
> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.
>  
> The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).
> 
> 
> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.
>  
> This is the current implementation. 
>  
> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.
>  
> Agreed.
> 
> 
> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).
>  
> Agreed.
> 
> 
>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.
>  
> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
> 
> 
> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range.
>  
> This is the current implementation.
> 
> 
> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.
>  
> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> 
>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.
>  
> This is the current implementation.
> 
> 
> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here.
>  
> This is the current implementation.
> 
> 
> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.
>  
> This is the current implementation.
> 
> 
> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.
>  
> We currently do not support this.
> 
> 
>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.
>  
> Until we see the need I hesitate to implement it.
> 
> 
>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.
>  
> Agreed.
> 
> 
> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.
>  
> I just added these.
> 
> 
>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/849cd8b9/attachment.html>

From hendrik at topoi.pooq.com  Fri Jan  8 19:34:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:34:17 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <20100108183416.GC14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:53:42AM -0600, Rodney M. Bates wrote:
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>     type of a set type.
> 
>       This is similar to the array index limitation.  Sets on base
>       types of long range are very unlikely, as they would be too bit.

"too big", not "too bit"

>       The assignability rules should make subranges of INTEGER
>       relatively easy to use as set base types instead of short
>       subranges of LONGINT.  This also obviates generalizing IN.
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>     and contains procedures that are equivalents for the 5 unsafe
>     ADDRESS arithmetic operations, with LONGINT substituted in place
>     of INTEGER in their signatures.  These are given in 2.7 and
>     include a +, two overloaded meanings of -, an INC, and a DEC.
> 
>       It is remotely conceivable that there could be a target whose
>       native address size is longer than its native integer size
>       (unlike the reverse.)  In such a case, these operations might be
>       needed.

The IBM 360 had three-byte addresses, but a four-byte integer.
However, they had to be four-byte aligned, and were usually handled 
using four-byte operations.  However, OS code (in assembler) often 
stuffer various non-address flags in the extra byte, so except for 
its massive obsolescence, this would be a real consideration.  The IBM 
370 had special instructions for loading and storing the three address 
bytes of a machine word, making this a little cleaner.  I'm told a later 
version of this architecture switched to four-byte addresses, causing a 
very expensive rewrite of a huge amount of code.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 19:54:53 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:54:53 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <20100108185453.GD14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.

I could understand opposition to LONGINT if it were based on it being a 
kludge stuck in to quickly patch a problem while we spend time thinking 
about the real, elegant solution.  And having two types like INTEGER and 
LONGINT without one being a subrange of the other seems like a kludge to 
me, however necessary it also appears.

But let me ask a question.  Is there ever any need for a Modula 3 
compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
INTEGER is 32 bits?

(I might have asked "more than 12 bits" in the above question, but 
modern 23-bit machines may very well have 16-bit operations but not 
12-bit operations.)

-- hendrik

P.S.  As far as I know, I don't think the C standard ever specifies that 
arithmetic operations on its file offset type (Is it offset_t?  I 
forget.) have any relation whatsoever to actual file position?  As far 
as I know, it could be a count of the number of bytes to read to reach 
that position, or it could consist of cylinder, track, and sector 
numbers, or it could even be encrypted.  Fie on the C implementor that 
does any of these things, though.


From hendrik at topoi.pooq.com  Fri Jan  8 19:58:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:58:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
Message-ID: <20100108185841.GE14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
> 
> The question really is what should the top type be?
> 
> We don't want to have all ordinal types base themselves on LONGINT 
> because then they will all incur LONGINT operations (which may be more 
> expensive than the "natural" INTEGER operations).

Is it even necessary for a compiler to implement -128..127 as more than 
one byte?

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 20:04:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 14:04:09 -0500
Subject: [M3devel] Integers
In-Reply-To: <4B476704.8010403@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
Message-ID: <20100108190409.GF14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> 
> What's unique about Modula-3 is that such representation changes are
> left to the compiler, while the language merely views values as
> sometimes belonging to more than one type, and allows such values to be
> assigned when so.  The usual approach in other languages is to elevate
> the representation change from a machine-level matter to a language-
> level matter by treating it as an implicit type change in addition to
> a representation change.  The result is always a lot of unnecessary
> complexity in the language.
...
...
> >
> >Where in the language is it important that INTEGER and LONGINT be 
> >different base types?  In other words, what advantages does this 
> >separation convey?
> 
> One thing that is very much needed in a language (not the only thing)
> is a type that always matches the implementation's native arithmetic
> size, which is most efficient.  If you don't distinguish this type,
> it becomes either impossible or horribly convoluted to define arithmetic
> so native machine arithmetic can be usually used where possible,
> but multi-word arithmetic will be used where needed.

Yes.  You do need this type.  And you can even call it INTEGER.  But is 
there any reason it cannot be a predefined subrange type of LONGINT?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 20:32:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:32:56 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <7743770A-2B7E-4AF7-8F6C-EC44041717AE@cs.purdue.edu>

On 8 Jan 2010, at 13:54, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
>> 
>> Just my opinion of course. I don't really understand why you are so
>> drastically opposing LONGINT suddenly. Probably I haven't been able to
>> follow some of the arguments.
> 
> I could understand opposition to LONGINT if it were based on it being a 
> kludge stuck in to quickly patch a problem while we spend time thinking 
> about the real, elegant solution.  And having two types like INTEGER and 
> LONGINT without one being a subrange of the other seems like a kludge to 
> me, however necessary it also appears.

It really is kind of a kludge invented just for large files.

> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

[0..1024] has memory representation of 16 bits.  What's the point of the question?  Values of [0..1024] are INTEGER and operations on them are INTEGER typed.

> (I might have asked "more than 12 bits" in the above question, but 
> modern 23-bit machines may very well have 16-bit operations but not 
> 12-bit operations.)
> 
> -- hendrik
> 
> P.S.  As far as I know, I don't think the C standard ever specifies that 
> arithmetic operations on its file offset type (Is it offset_t?  I 
> forget.) have any relation whatsoever to actual file position?  As far 
> as I know, it could be a count of the number of bytes to read to reach 
> that position, or it could consist of cylinder, track, and sector 
> numbers, or it could even be encrypted.  Fie on the C implementor that 
> does any of these things, though.

Right, so this argues in favor of a cleaner abstraction of file offsets rather than LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 20:33:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:33:54 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185841.GE14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
	<20100108185841.GE14151@topoi.pooq.com>
Message-ID: <C5865D4D-441B-4410-B5A0-CA2A3F746C20@cs.purdue.edu>

They are stored as 1-byte values.  But the values of that type are INTEGERs and operated on as INTEGERs.

On 8 Jan 2010, at 13:58, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
>> 
>> The question really is what should the top type be?
>> 
>> We don't want to have all ordinal types base themselves on LONGINT 
>> because then they will all incur LONGINT operations (which may be more 
>> expensive than the "natural" INTEGER operations).
> 
> Is it even necessary for a compiler to implement -128..127 as more than 
> one byte?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/6b40fee7/attachment.html>

From hosking at cs.purdue.edu  Fri Jan  8 20:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:36:18 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108190409.GF14151@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
Message-ID: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>

On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> 
>> What's unique about Modula-3 is that such representation changes are
>> left to the compiler, while the language merely views values as
>> sometimes belonging to more than one type, and allows such values to be
>> assigned when so.  The usual approach in other languages is to elevate
>> the representation change from a machine-level matter to a language-
>> level matter by treating it as an implicit type change in addition to
>> a representation change.  The result is always a lot of unnecessary
>> complexity in the language.
> ...
> ...
>>> 
>>> Where in the language is it important that INTEGER and LONGINT be 
>>> different base types?  In other words, what advantages does this 
>>> separation convey?
>> 
>> One thing that is very much needed in a language (not the only thing)
>> is a type that always matches the implementation's native arithmetic
>> size, which is most efficient.  If you don't distinguish this type,
>> it becomes either impossible or horribly convoluted to define arithmetic
>> so native machine arithmetic can be usually used where possible,
>> but multi-word arithmetic will be used where needed.
> 
> Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> there any reason it cannot be a predefined subrange type of LONGINT?

I sense confusion here...

INTEGER is not a subrange type.
Neither is LONGINT.



From rodney_bates at lcwb.coop  Fri Jan  8 20:25:50 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:25:50 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <4B4786BE.3000607@lcwb.coop>



Tony Hosking wrote:
> Let's have a clean language proposal before thinking about implementing it...  ;-)
> 
> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
> 
> Looking further at the assignability rules:
> 
> A type T is assignable to a type U if:
> 
> 	? T <: U, or
> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
> 	? T and U are ordinal types with at least one member in common.
> 
> This suggests that we don't really need to say that INTEGER <: LONGINT.

I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
but it has some additional other consequences that I considered undesirable.  I don't
remember what they were off the top of my head, but could no doubt reconstruct them,
if anybody cares.

> 
> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
do one of:

1) Say LONGINT is not an ordinal type.

2) Say that 10 and 10L are not only expressions of different types, but
    also distinct values as well.  The low values of LONGINT and the
    corresponding values of INTEGER would not be the same.

3) Alter the definition of assignability, for example to say in the third clause,
    that T and U must have the same base type as well as a member in common.

Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
also mean there would be no subranges of LONGINT and probably eliminate several
other things you might expect to come along with LONGINT.

Doing 2) Seems like a big contradiction to the way subranges work and the existing
Modula-3 philosophy of types sometimes having overlapping value sets.

Which leaves 3), which I think is the only reasonable way to do this.

If we leave this as is, it will follow that assignment statements and mixed arithmetic
are legal and work the same way as with different subranges of the same base type.
Given the liberal assignability rules we already have, I don't think this is
necessarily a bad idea, despite my general bias toward requiring more stuff to
be explicit in code.  There are about 8 or 9 places, as I recall, that would be
affected because they require only assignability.

The definitions of the arithmetic operators would have to be treated with some care
to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
arithmetic, something we absolutely must avoid.  This points out where the analogy
to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
implementation is to expand the operands to the base type and do the arithmetic
in that size.  Here, we don't want that to happen unless at least one operand is
LONGINT.

On a side note, I do not believe the analogy to the floating types applies here.
With INTEGER/LONGINT, there is a very obvious and natural equivalence between
the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
different native machine floating types.  The messiness of floating representation
means you can't assume the exactly representable reals are the same for two different
floating types, even within some restricted value range.



> 
> On 8 Jan 2010, at 02:44, Jay K wrote:
> 
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>  
>>   LONGINT + INTEGER => LONGINT 
>>   LONGINT - INTEGER => LONGINT 
>>   LONGINT * INTEGER => LONGINT 
>>   LONGINT DIV INTEGER => LONGINT 
>>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>>   MAX(INTEGER, LONGINT) => LONGINT  
>>   LONGINT := INTEGER 
>>  
>> Other mixes are less obvious and would require runtime checks.
>>  
>> I think the backend will just work but I haven't tried that yet.
>>  (Truth be told, I can only affectively edit files on NT...)
>>  
>> Thoughts?
>>  
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:33:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:33:37 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
Message-ID: <4B478891.8010101@lcwb.coop>

Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
specific case where this community has seen significant need.  But I have a number of times
in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
new use cases will happen.  Especially, we can expect the proliferation of embedded devices
to create then.  And I really believe it can be done without a lot of violence to the
Language..

Tony Hosking wrote:
> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
> 
> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
> 
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:42:09 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:42:09 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <4B478A91.3090609@lcwb.coop>



Mika Nystrom wrote:
> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>>
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>>
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>>
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?
> 
> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)
> 
> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree, I hate the horrible complexities of implicit type conversions
in other languages.  But this doesn't have to be done by automatic type
conversion, just another instance of Modula-3's existing superior concept of
assignability between non-disjoint types.

> 
> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.
> 
>     Mika
> 

In my original proposal, I said:
-------------------------------------------------------------------------
This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.


-------------------------------------------------------------------------

I still believe we can do these things, and also that the changes
to the language are not too drastic.  They are mostly just more
instances of existing concepts.


From hosking at cs.purdue.edu  Fri Jan  8 21:40:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:40:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B478891.8010101@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
	<4B478891.8010101@lcwb.coop>
Message-ID: <597E64CD-7805-486C-AC7B-025A117C8B4E@cs.purdue.edu>

But should we really introduce restricted range multi-word arithmetic?
Why not instead make use of a general arbitrary range type like BigInteger.T?  (see the arithmetic package)

Again, I am acting devil's advocate here...

On 8 Jan 2010, at 14:33, Rodney M. Bates wrote:

> Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
> specific case where this community has seen significant need.  But I have a number of times
> in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
> new use cases will happen.  Especially, we can expect the proliferation of embedded devices
> to create then.  And I really believe it can be done without a lot of violence to the
> Language..
> 
> Tony Hosking wrote:
>> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
>> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
>> 

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

From hosking at cs.purdue.edu  Fri Jan  8 21:47:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:47:56 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B4786BE.3000607@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<4B4786BE.3000607@lcwb.coop>
Message-ID: <93B01681-30DB-4D5E-9429-131DCB74E794@cs.purdue.edu>

On 8 Jan 2010, at 14:25, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> Let's have a clean language proposal before thinking about implementing it...  ;-)
>> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
>> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
>> Looking further at the assignability rules:
>> A type T is assignable to a type U if:
>> 	? T <: U, or
>> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	? T and U are ordinal types with at least one member in common.
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> 
> I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
> but it has some additional other consequences that I considered undesirable.  I don't
> remember what they were off the top of my head, but could no doubt reconstruct them,
> if anybody cares.

Right, I much prefer assignability rule 3, rather than a subtype relationship.

>> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.
> 
> Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
> do one of:
> 
> 1) Say LONGINT is not an ordinal type.

Not necessarily.  See my definition of ORD/VAL in the update language spec.

> 2) Say that 10 and 10L are not only expressions of different types, but
>   also distinct values as well.  The low values of LONGINT and the
>   corresponding values of INTEGER would not be the same.

I don't think we need to say they are different values (in fact, they can be converted).  VAL(10, LONGINT) = 10L.

> 3) Alter the definition of assignability, for example to say in the third clause,
>   that T and U must have the same base type as well as a member in common.

In my definition both INTEGER and LONGINT *are* ordinal types so no need to change.

> Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
> also mean there would be no subranges of LONGINT and probably eliminate several
> other things you might expect to come along with LONGINT.

Agreed.

> Doing 2) Seems like a big contradiction to the way subranges work and the existing
> Modula-3 philosophy of types sometimes having overlapping value sets.

Agreed.

> Which leaves 3), which I think is the only reasonable way to do this.

I don't see the need if both are ordinal types.  They have some values in common.  So they are assignable.

> If we leave this as is, it will follow that assignment statements and mixed arithmetic
> are legal and work the same way as with different subranges of the same base type.
> Given the liberal assignability rules we already have, I don't think this is
> necessarily a bad idea, despite my general bias toward requiring more stuff to
> be explicit in code.  There are about 8 or 9 places, as I recall, that would be
> affected because they require only assignability.

So, in the current implementation we just don't have assignability and mixed arithmetic.

> The definitions of the arithmetic operators would have to be treated with some care
> to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
> arithmetic, something we absolutely must avoid.

Correct.

> This points out where the analogy
> to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
> implementation is to expand the operands to the base type and do the arithmetic
> in that size.

But that is exactly how the current implementation works.

> Here, we don't want that to happen unless at least one operand is
> LONGINT.

So, the base type yields the correct behavior.

> On a side note, I do not believe the analogy to the floating types applies here.
> With INTEGER/LONGINT, there is a very obvious and natural equivalence between
> the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
> different native machine floating types.  The messiness of floating representation
> means you can't assume the exactly representable reals are the same for two different
> floating types, even within some restricted value range.

Yes, that is why I am leaning in your direction: assignability plus mixed arithmetic.

> 
> 
> 
>> On 8 Jan 2010, at 02:44, Jay K wrote:
>>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>>   LONGINT + INTEGER => LONGINT   LONGINT - INTEGER => LONGINT   LONGINT * INTEGER => LONGINT   LONGINT DIV INTEGER => LONGINT   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)    LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)    MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)    MAX(INTEGER, LONGINT) => LONGINT    LONGINT := INTEGER  Other mixes are less obvious and would require runtime checks.
>>> I think the backend will just work but I haven't tried that yet.
>>> (Truth be told, I can only affectively edit files on NT...)
>>> Thoughts?
>>> 
>> 



From hosking at cs.purdue.edu  Fri Jan  8 21:51:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:51:13 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B478A91.3090609@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
	<4B478A91.3090609@lcwb.coop>
Message-ID: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>

Once more summarising the discussion so far.

*If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).

The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?

On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:

> 
> 
> Mika Nystrom wrote:
>> Tony Hosking writes:
>> ...
>>> A type T is assignable to a type U if:
>>> 
>>> 	=95 T <: U, or
>>> 	=95 U <: T and T is an array or a reference type other than =
>>> ADDRESS (This restriction is lifted in unsafe modules.), or
>>> 	=95 T and U are ordinal types with at least one member in =
>>> common.
>>> 
>>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>> 
>>> We can simply rely on the third clause regarding their both being =
>>> ordinal types with at least one member in common.  Then assignment =
>>> simply needs to test that the values are in range.
>>> 
>> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
>> the same "member"?
>> By a similar argument, you could make REAL and LONGREAL assignable.
>> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
>> the same bit patterns, same as 0 and 0L for that matter, and I can add
>> that the way you do single-precision floating point on Alpha is by zeroing
>> a big chunk in the middle of your double-precision fp registers...)
>> I think I am with you on removing LONGINT from the language.  The proper
>> way of handling file sizes (or anything else that might be a bigger number
>> than a machine word) is through abstraction.  I have a suspicion that it's
>> probably a severe micro-optimization to worry about the efficiency of
>> operations on file sizes.  The thought that someone is adding automatic
>> type conversion to Modula-3, a la C, makes me feel slightly sick to
>> my stomach...
> 
> I agree, I hate the horrible complexities of implicit type conversions
> in other languages.  But this doesn't have to be done by automatic type
> conversion, just another instance of Modula-3's existing superior concept of
> assignability between non-disjoint types.
> 
>> I confess that my position is influenced by the fact that I have written
>> many programs that generate Modula-3 code as an "intermediate language".
>> I really really really need M3 to be easy to understand to get this to
>> work well.  Also being able to parse interfaces and know precisely what
>> they mean is important to me.  If the rules start getting sloppy.. that
>> would really upset me.  On the other hand this means that if I'm faced
>> with a problem that doesn't really fit into M3 well, say, working in
>> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
>> to the language definition but to write a code generator that takes
>> appropriate infix (or maybe more likely prefix) code and turns it into
>> the appropriate calls through the Word interface.  It's a pain, yes, but in the long run that's the right way, because you can do so much
>> more with that approach than just unsigned integers.
>>    Mika
> 
> In my original proposal, I said:
> -------------------------------------------------------------------------
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> 
> -------------------------------------------------------------------------
> 
> I still believe we can do these things, and also that the changes
> to the language are not too drastic.  They are mostly just more
> instances of existing concepts.



From hendrik at topoi.pooq.com  Fri Jan  8 22:39:23 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:39:23 -0500
Subject: [M3devel] Integers
In-Reply-To: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
Message-ID: <20100108213923.GA9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> >> 
> >> What's unique about Modula-3 is that such representation changes are
> >> left to the compiler, while the language merely views values as
> >> sometimes belonging to more than one type, and allows such values to be
> >> assigned when so.  The usual approach in other languages is to elevate
> >> the representation change from a machine-level matter to a language-
> >> level matter by treating it as an implicit type change in addition to
> >> a representation change.  The result is always a lot of unnecessary
> >> complexity in the language.
> > ...
> > ...
> >>> 
> >>> Where in the language is it important that INTEGER and LONGINT be 
> >>> different base types?  In other words, what advantages does this 
> >>> separation convey?
> >> 
> >> One thing that is very much needed in a language (not the only thing)
> >> is a type that always matches the implementation's native arithmetic
> >> size, which is most efficient.  If you don't distinguish this type,
> >> it becomes either impossible or horribly convoluted to define arithmetic
> >> so native machine arithmetic can be usually used where possible,
> >> but multi-word arithmetic will be used where needed.
> > 
> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> > there any reason it cannot be a predefined subrange type of LONGINT?
> 
> I sense confusion here...
> 
> INTEGER is not a subrange type.

The question is not whether it is a subrange type.  It isn't.
The question is whether it could be.

> Neither is LONGINT.
> 

-- hendrik



From hosking at cs.purdue.edu  Fri Jan  8 22:47:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:47:00 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>

On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
> 
> The question is not whether it is a subrange type.  It isn't.
> The question is whether it could be.

I think that would result in major contradictions in the type system.



From mika at async.async.caltech.edu  Fri Jan  8 22:50:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 13:50:28 -0800
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com> 
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <20100108215028.40A651A207A@async.async.caltech.edu>


Hendrik, do you mean:

"INTEGER is that subrange of LONGINT that happens to be efficiently 
implementable on the target architecture"?

Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
choose it as I please when I configure/compile the compiler?

    Mika

hendrik at topoi.pooq.com writes:
>On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
>> 
>> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> >> 
>> >> What's unique about Modula-3 is that such representation changes are
>> >> left to the compiler, while the language merely views values as
>> >> sometimes belonging to more than one type, and allows such values to be
>> >> assigned when so.  The usual approach in other languages is to elevate
>> >> the representation change from a machine-level matter to a language-
>> >> level matter by treating it as an implicit type change in addition to
>> >> a representation change.  The result is always a lot of unnecessary
>> >> complexity in the language.
>> > ...
>> > ...
>> >>> 
>> >>> Where in the language is it important that INTEGER and LONGINT be 
>> >>> different base types?  In other words, what advantages does this 
>> >>> separation convey?
>> >> 
>> >> One thing that is very much needed in a language (not the only thing)
>> >> is a type that always matches the implementation's native arithmetic
>> >> size, which is most efficient.  If you don't distinguish this type,
>> >> it becomes either impossible or horribly convoluted to define arithmetic
>> >> so native machine arithmetic can be usually used where possible,
>> >> but multi-word arithmetic will be used where needed.
>> > 
>> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
>> > there any reason it cannot be a predefined subrange type of LONGINT?
>> 
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
>
>The question is not whether it is a subrange type.  It isn't.
>The question is whether it could be.
>
>> Neither is LONGINT.
>> 
>
>-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 22:50:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:50:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
Message-ID: <20100108215033.GB9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
> >> I sense confusion here...
> >> 
> >> INTEGER is not a subrange type.
> > 
> > The question is not whether it is a subrange type.  It isn't.
> > The question is whether it could be.
> 
> I think that would result in major contradictions in the type system.

Just what would the malign consequences be?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 22:53:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:53:29 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108215033.GB9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
Message-ID: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>

Then the base type of INTEGER would be LONGINT.

Thus, INTEGER operations would incur the expense of unnatural LONGINT operations.

That is unacceptable.

On 8 Jan 2010, at 16:50, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>>>> I sense confusion here...
>>>> 
>>>> INTEGER is not a subrange type.
>>> 
>>> The question is not whether it is a subrange type.  It isn't.
>>> The question is whether it could be.
>> 
>> I think that would result in major contradictions in the type system.
> 
> Just what would the malign consequences be?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/3e3aa509/attachment.html>

From jay.krell at cornell.edu  Fri Jan  8 23:30:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 22:30:57 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>,
	<20100108173412.8531F1A207A@async.async.caltech.edu>,
	<4B478A91.3090609@lcwb.coop>,
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
Message-ID: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>


 > The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?


Two of us addressed this.

The answer is not technically/scientifically pleasing.
The answer is simply that in-fix operators are more convenient and libraries are not.

Obviously the general clean answer is either:

   operator overloading on user defined types, making the library convenient 

   or maybe a language feature for fixed but arbitrary precision integers

    e.g. 

     int1024 = BITS 1024 for INTEGER

     or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]

     or uint1024 = [0..Word.LShift(1, 1024)]

 

 

and the compiler would be compelled to generate code for any precision.

 

 

These are both more work.

LONGINT is indeed a special case.

C compilers all provide it "long long" or "__int64".

File sizes are indeed probably the typical use case for C?

But also things like InterlockedCompareExchange64 of some "packed" format.

 

Personally I would gladly accept

 FileSize = [0..Word.LShift(1, 63 or 64)];

 

 

even so...the compiler/language feature could (initially) limit the "bits" to 64, but

still implement via this more general syntax and not some new special type/keyword.

 

 

This is the question floating around: maybe there are just integers of varying size/range.

 

 

Maybe the compiler can notice if the size is <= or > a natural size?

 

Mixed arithmetic would be possible among arbitrary pairs of sizes and have a simple

formula for the result. Assuming "silent wraparound", addition would just pick the larger of the two.

But then, what if I assign to an even larger type? Hm.

Then you want addition of n and m to produce max(n, m) + 1, and such.

Perhaps there is some rule..you know..checked narrowing..?

And the checks can be omitted if the assignment is to a larger type?

e.g.

LONGINT := INTEGER + INTEGER => no overflow check

LONGINT := LONGINT + LONGINT => overflow check

int1024 := LONGINT + LONGINT => no overflow check

?

 

 

In reality I think no code would use the wider := narrow + narrow.

But it seems technically reasonable.

 

 

In reality code either wants the overflow check, or a type that expands its precision as needed.

("bignum", etc.)

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 15:51:13 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] mixing INTEGER and LONGINT?
> 
> Once more summarising the discussion so far.
> 
> *If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).
> 
> The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?
> 
> On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:
> 
> > 
> > 
> > Mika Nystrom wrote:
> >> Tony Hosking writes:
> >> ...
> >>> A type T is assignable to a type U if:
> >>> 
> >>> =95 T <: U, or
> >>> =95 U <: T and T is an array or a reference type other than =
> >>> ADDRESS (This restriction is lifted in unsafe modules.), or
> >>> =95 T and U are ordinal types with at least one member in =
> >>> common.
> >>> 
> >>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> >>> 
> >>> We can simply rely on the third clause regarding their both being =
> >>> ordinal types with at least one member in common. Then assignment =
> >>> simply needs to test that the values are in range.
> >>> 
> >> Are you sure about this for INTEGER and LONGINT? I.e., are 0 and 0L
> >> the same "member"?
> >> By a similar argument, you could make REAL and LONGREAL assignable.
> >> Are 0.0d0 and 0.0e0 the same "thing"? (On almost all machines they have
> >> the same bit patterns, same as 0 and 0L for that matter, and I can add
> >> that the way you do single-precision floating point on Alpha is by zeroing
> >> a big chunk in the middle of your double-precision fp registers...)
> >> I think I am with you on removing LONGINT from the language. The proper
> >> way of handling file sizes (or anything else that might be a bigger number
> >> than a machine word) is through abstraction. I have a suspicion that it's
> >> probably a severe micro-optimization to worry about the efficiency of
> >> operations on file sizes. The thought that someone is adding automatic
> >> type conversion to Modula-3, a la C, makes me feel slightly sick to
> >> my stomach...
> > 
> > I agree, I hate the horrible complexities of implicit type conversions
> > in other languages. But this doesn't have to be done by automatic type
> > conversion, just another instance of Modula-3's existing superior concept of
> > assignability between non-disjoint types.
> > 
> >> I confess that my position is influenced by the fact that I have written
> >> many programs that generate Modula-3 code as an "intermediate language".
> >> I really really really need M3 to be easy to understand to get this to
> >> work well. Also being able to parse interfaces and know precisely what
> >> they mean is important to me. If the rules start getting sloppy.. that
> >> would really upset me. On the other hand this means that if I'm faced
> >> with a problem that doesn't really fit into M3 well, say, working in
> >> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> >> to the language definition but to write a code generator that takes
> >> appropriate infix (or maybe more likely prefix) code and turns it into
> >> the appropriate calls through the Word interface. It's a pain, yes, but in the long run that's the right way, because you can do so much
> >> more with that approach than just unsigned integers.
> >> Mika
> > 
> > In my original proposal, I said:
> > -------------------------------------------------------------------------
> > This proposal satisfies (I believe) the following principles:
> > 
> > The static correctness and type analysis of existing code written to
> > the current language definition will not change with the new
> > definition. This also implies that the new language definition will
> > not introduce new type mismatches that would make existing pickles
> > unreadable.
> > 
> > The runtime semantics and time and space efficiency of existing code
> > written to the current language definition will also not change with
> > the new definition, if the native word size of the implementation does
> > not change. Of course, porting existing code to an implementation
> > with different native word size can change the runtime semantics by
> > changing the supported value range, with or without language change.
> > 
> > The static type analysis of programs written to the modified language
> > definition will be independent of the implementation, particularly, of
> > the native word size. This prevents inadvertently writing code that
> > is highly nonportable among different native word sizes.
> > 
> > The new, not-necessarily-native integer type does not extend to
> > certain existing uses of INTEGER and CARDINAL that are of unlikely
> > utility and would add complexity.
> > 
> > 
> > -------------------------------------------------------------------------
> > 
> > I still believe we can do these things, and also that the changes
> > to the language are not too drastic. They are mostly just more
> > instances of existing concepts.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0ec29705/attachment.html>

From hendrik at topoi.pooq.com  Sat Jan  9 00:05:05 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:05:05 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108215028.40A651A207A@async.async.caltech.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
Message-ID: <20100108230505.GC9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
> 
> Hendrik, do you mean:
> 
> "INTEGER is that subrange of LONGINT that happens to be efficiently 
> implementable on the target architecture"?
> 
> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
> choose it as I please when I configure/compile the compiler?
> 
>     Mika

I've just been thinking of that.  Why even have a size for LONGINT?  Why 
not allow the programmer to use only subranges of LONGINT?  The 
arithmetic operations all have the property that you can compute 
subranges for the reults given subranges for the operands.  So 
intermediate results are all bounded in size, you can compute without 
overflow happening ... until you get to narrow the final result for 
assignment to whatever variable you want to 
assign it to.

I suspect there are compiler optimisations (well, let's ne honest, 
call them ameliorations) that could be performed to move the final 
range-truncate-check backward through the series of operations and limit 
the number of unnecessary bits that have been computed.  These 
ameliorations are likely to be more effective if no range check need be 
performed on final assignment (but there's always a conflict between 
amelioration and run-time checks, isn't there?)

We could do this for LONGINT completely independent of whatever we do 
with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
INTEGER is what you use when you particularly want to use 
machine-efficient data and operations.  LONGINT is what you use when 
that's not enough, and you want to statically specify the size of 
integer you need, and pay the price.  What with machines having carry 
and overflow flags, add-with-carry instructions, it chould be possible 
to generate reasonably efficient code anyway, without the full overhead 
of run-time-determined number sizes.

Most machines already have integer multiply instructions that return a 
double-length product.  It's such a pity to waste them.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 00:11:54 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:11:54 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
	<COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
Message-ID: <20100108231154.GD9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:30:57PM +0000, Jay K wrote:
> 
>  > The question remains: is LONGINT necessary or simply a kludge 
>  > better satisfied by arbitrary precision arithmetic like 
>  > BigInteger.T?
> 
> 
> Two of us addressed this.
> 
> The answer is not technically/scientifically pleasing.
> The answer is simply that in-fix operators are more convenient and 
> libraries are not.
> 
> Obviously the general clean answer is either:
> 
>    operator overloading on user defined types, making the library convenient 
> 
>    or maybe a language feature for fixed but arbitrary precision integers

Why not make LONGINT the base type for all these fixed but arbitrary 
precision integers.  But don't allow anyone to declare a variable of 
type LONGINT, so we never have to specify a size for it, and its 
subranges can be as large as anyone pleases.

>     e.g. 
      e.g. 
> 
> 
>      int1024 = BITS 1024 for INTEGER
       int1024 = BITS 1024 for LONGINT
 
>      or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]
       or uint1024 = BITS 1024 for [0..Word.LShift(1L, 1024)]
> 
>      or uint1024 = [0..Word.LShift(1, 1024)]
       or uint1024 = [0..Word.LShift(1L, 1024)]
> 
> and the compiler would be compelled to generate code for any precision.
> 
> These are both more work.
> 
> LONGINT is indeed a special case.

But if we let it be finite but unbounded it's a rather different special 
case.

-- hendrik


From hosking at cs.purdue.edu  Sat Jan  9 01:53:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 19:53:07 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108230505.GC9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
Message-ID: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>

I think what you are advocating is Rodney's proposal + assignability of INTEGER and LONGINT + mixed arithmetic.

On 8 Jan 2010, at 18:05, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
>> 
>> Hendrik, do you mean:
>> 
>> "INTEGER is that subrange of LONGINT that happens to be efficiently 
>> implementable on the target architecture"?
>> 
>> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
>> choose it as I please when I configure/compile the compiler?
>> 
>>    Mika
> 
> I've just been thinking of that.  Why even have a size for LONGINT?  Why 
> not allow the programmer to use only subranges of LONGINT?  The 
> arithmetic operations all have the property that you can compute 
> subranges for the reults given subranges for the operands.  So 
> intermediate results are all bounded in size, you can compute without 
> overflow happening ... until you get to narrow the final result for 
> assignment to whatever variable you want to 
> assign it to.
> 
> I suspect there are compiler optimisations (well, let's ne honest, 
> call them ameliorations) that could be performed to move the final 
> range-truncate-check backward through the series of operations and limit 
> the number of unnecessary bits that have been computed.  These 
> ameliorations are likely to be more effective if no range check need be 
> performed on final assignment (but there's always a conflict between 
> amelioration and run-time checks, isn't there?)
> 
> We could do this for LONGINT completely independent of whatever we do 
> with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
> INTEGER is what you use when you particularly want to use 
> machine-efficient data and operations.  LONGINT is what you use when 
> that's not enough, and you want to statically specify the size of 
> integer you need, and pay the price.  What with machines having carry 
> and overflow flags, add-with-carry instructions, it chould be possible 
> to generate reasonably efficient code anyway, without the full overhead 
> of run-time-determined number sizes.
> 
> Most machines already have integer multiply instructions that return a 
> double-length product.  It's such a pity to waste them.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/7661b06f/attachment.html>

From hendrik at topoi.pooq.com  Sat Jan  9 02:33:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:33:42 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
Message-ID: <20100109013342.GA23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> I think what you are advocating is Rodney's proposal + assignability 
> of INTEGER and LONGINT + mixed arithmetic.

I thought Rodney's propsal still had the compiler impose a bound on the 
size of LONGINT.  Or did I miss something?

I'm proposing to let the programmer use subranges of LONGINT that are as 
long as he wishes.  And if the computer runs out of virtual memory to 
store one of the programmer's long integers, well, that's the computer 
imposing the limit, not the language.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 02:40:31 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:40:31 -0500
Subject: [M3devel] Integers
In-Reply-To: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
	<7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
Message-ID: <20100109014030.GB23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:53:29PM -0500, Tony Hosking wrote:
> Then the base type of INTEGER would be LONGINT.
> 
> Thus, INTEGER operations would incur the expense of unnatural LONGINT 
> operations.

I get it.  It's not a matter of the size of the INTEGERs; it's a matter 
of the operations on them -- that operations on INTEGERs are limited to 
whatever size the computer processes efficiently, and that this limit is 
*checked* (at least in principle) for reliability.

-- hendrik

> 
> That is unacceptable.


From hendrik at topoi.pooq.com  Sat Jan  9 02:44:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:44:37 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <20100109014437.GC23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > I think what you are advocating is Rodney's proposal + assignability 
> > of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).

-- hendrik
> 
> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.


From jay.krell at cornell.edu  Sat Jan  9 03:09:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:09:13 +0000
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>,
	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>, <20100108190409.GF14151@topoi.pooq.com>,
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>,
	<20100108213923.GA9749@topoi.pooq.com>,
	<20100108215028.40A651A207A@async.async.caltech.edu>,
	<20100108230505.GC9749@topoi.pooq.com>,
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>,
	<20100109013342.GA23519@topoi.pooq.com>,
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <COL101-W8A809232A5F6A9D4948D2E66F0@phx.gbl>


I hear Hendrik proposing that "LONGINT" is the name for fixed arbitrary precision integers.

That it might even have a name. Or the user has to mention it in order to acknowledge

he is using something potentially inefficient.

 

 

 FileSize = BITS 64 FOR LONGINT;

 FileSize = [1..LongInt.LShift(1, 63)];

 FileSize = LONGINT[64];

 or such 

 

This is not a bad idea.

 

I think the "real" problem here is a multitude of options/scenarios and

a lack of vocabulary.

As I said, there is a time/place for "silent wraparound", for trapping overflow,

for extending precision to fit.

 

Also I'm surprised you can't mix REAL and LONGREAL.

 

Also I don't think INTEGER + LONGINT is all that confusing or, as I said, subtle.

It isn't /immediately/ obvious how to deal with MIN, MAX, MOD, DIV, but

it is still not that tricky.

 

MIN(INTEGER, LONGINT) is INTEGER. Not that difficult to figure out why.

 At least one of the inputs fits in an integer and the result is the smaller input.

 

MAX(INTEGER, LONGINT) is LONGINT, ditto.

  One of the inputs might not fit in an INTEGER and the result is the larger input.

 

INTEGER DIV LONGINT is INTEGER

BIG DIV SMALL1 is SMALL2

SMALL DIV BIG is 0 remainder SMALL.

 

LONGINT DIV INTEGER is LONGINT

Prove with one simple case:

BIG1 DIV 2 is BIG2.

Easier BIG1 DIV 1 is BIG1.

 

Consider: LONGINT MOD INTEGER and INTEGER MOD LONGINT

SMALL divided by BIG is, again, 0 remainder SMALL, INTEGER

BIG divided by SMALL1 is SMALL2, remainder [0..SMALL1 - 1] which is INTEGER.

 

That is, division either gives you 0 and remainder = first number.

Or it gives you non-zero and remainder is less than the second number.

  50 divided by 100 is 0 remainder 50.

  109 divided by 10 is 10 remainder 9

 

FOR loops also should allow mixing.

 

 - Jay

 
> Date: Fri, 8 Jan 2010 20:44:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT (was: Re: Integers
> 
> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > > I think what you are advocating is Rodney's proposal + assignability 
> > > of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT. Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
> > 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes. And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/49c07b7c/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 03:16:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:16:57 +0000
Subject: [M3devel] still need a branch for longint changes?
Message-ID: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>


Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay

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

From hosking at cs.purdue.edu  Sat Jan  9 03:23:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:23:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
Message-ID: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>

Please hold off on mainline changes.  I don't think we have reached consensus yet...

The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.

On 8 Jan 2010, at 21:16, Jay K wrote:

> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/902c8d90/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  9 03:28:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:28:59 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <7A1B4E83-A69C-43CA-9932-38B974B22B60@cs.purdue.edu>

I'm not sure how this would all work exactly...  It would make LONGINT a very strange beast indeed, compared to the other ordinal types.

On 8 Jan 2010, at 20:44, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability 
>>> of INTEGER and LONGINT + mixed arithmetic.
>> 
>> I thought Rodney's propsal still had the compiler impose a bound on the 
>> size of LONGINT.  Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
>> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as 
>> long as he wishes.  And if the computer runs out of virtual memory to 
>> store one of the programmer's long integers, well, that's the computer 
>> imposing the limit, not the language.

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

From hosking at cs.purdue.edu  Sat Jan  9 03:32:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:32:47 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>

On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>> I think what you are advocating is Rodney's proposal + assignability 
>> of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

Yes, it would.

> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.

But there is still the question as to what *representation* is used to decide the particular operation to apply.

I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.

Just for fun, I suggest you take some time to watch the talk Growing a Language, by Guy Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/f9495a09/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 03:36:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:36:54 +0000
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>


I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.

And mixed arithmetic is available, and assignability INTEGER to LONGINT.

I have that implemented. It is a little onerous for Rd/Wr uses, but ok.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 8 Jan 2010 21:23:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] still need a branch for longint changes?


Please hold off on mainline changes.  I don't think we have reached consensus yet...


The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.



On 8 Jan 2010, at 21:16, Jay K wrote:

Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/0d2b4846/attachment.html>

From hendrik at topoi.pooq.com  Sat Jan  9 04:00:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:00:41 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <20100109030040.GA28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:32:47PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >> I think what you are advocating is Rodney's proposal + assignability 
> >> of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes.  And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine 
> representation based on the range of values in the subrange (much as 
> it does currently).

That's exactly what I propose.

> But if you really want to have an arbitrary range type I would argue 
> it is much better to implement it as a library than as a primitive 
> type.

That's fine if I have no static limit on the size of the integers.  Like 
if I want to have an open array.  Or even an array that I can resize 
dynamically.  But for the common case where I know exactly what the 
limits are, static is better.

(and that's the case with file offsets, for example)

What's easier for the compiler writer is another matter, of course.

> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele

I'll try and find it.  I seem to remember seeing the text somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 04:03:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:03:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <20100109030314.GB28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:23:15PM -0500, Tony Hosking wrote:
> Please hold off on mainline changes.  I don't think we have reached 
> consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  
> I'm leaning towards allowing it, but want to hear from others.

Not to mention the question whether the conpiler should impose a static 
bound on LONGINT.

-- hendrik


From jay.krell at cornell.edu  Sat Jan  9 04:54:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 03:54:31 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108142811.GA14151@topoi.pooq.com>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>,
	<20100108142811.GA14151@topoi.pooq.com>
Message-ID: <COL101-W1340FFFD0FCE25D04F7C2EE66F0@phx.gbl>


Oops, of course, thank you.
I'll update my changes...maybe check them into a branch..

 - Jay

> From: hendrik

>     MIN( 5, -1000000000000000L) = -1000000000000000L
>     So the result really needs to be LONGINT.

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

From hosking at cs.purdue.edu  Sat Jan  9 06:06:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:06:07 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
	<COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
Message-ID: <77A73750-12DF-4BB2-B6AF-6919FC2687FE@cs.purdue.edu>

So, thinking about things some more I am very much less inclined to believe that mixed operand arithmetic makes any sense, though assignability with run-time range checks seems fine.

With mixed operand arithmetic we get to some very strange places:

LAST(INTEGER) + 1 = FIRST(INTEGER)

is true because of overflow under the standard Modula-3 implementation.

But,

LAST(INTEGER) + 1L = FIRST(INTEGER)

is false because the arithmetic will be performed as LONGINT.

The trivial presence of "1L" instead of "1" has a huge impact on the semantics.  That seems really dangerous.

Much better (if wordier) to require explicit conversion (as currently implemented) to preserve sanity.

Thus,

VAL(LAST(INTEGER), LONGINT) + 1L = VAL(FIRST(INTEGER), LONGINT)

is false, as the programmer rightly expects, because he/she will be explicitly (because of the conversions) aware that LONGINT arithmetic is taking place.

On 8 Jan 2010, at 21:36, Jay K wrote:

> I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.
> And mixed arithmetic is available, and assignability INTEGER to LONGINT.
> I have that implemented. It is a little onerous for Rd/Wr uses, but ok.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 21:23:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] still need a branch for longint changes?
> 
> Please hold off on mainline changes.  I don't think we have reached consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.
> 
> On 8 Jan 2010, at 21:16, Jay K wrote:
> 
> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 
> 
> 



From hosking at cs.purdue.edu  Sat Jan  9 06:37:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:37:42 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>

Looking at your code, I think the assignability test for ordinals should be more like:

      IF (IsEqual (Base(a), Base(b), NIL)
          OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
          OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

That way CARDINAL and other subranges fall right out.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 8 Jan 2010, at 06:13, Jay K wrote:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>  
>  
> The compiler change is newer than earlier.
> For example you can now assign CARDINAL to LONGINT.
> I didn't do it, but you should also be able to add/subtract/etc.
> mixing CARDINAL and LONGINT.
>  
> 
> FOR statements also don't allow the level of mixing
> that they should.
> 
>  
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..
>  
> 
>  - Jay
> <dif8.txt>



From jay.krell at cornell.edu  Sat Jan  9 06:50:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 05:50:06 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
Message-ID: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>


I don't know the precedence but agreed:


>           OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>           OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Also, I really think mixed arithmetic is ok.

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
>       IF (IsEqual (Base(a), Base(b), NIL)
>           OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>           OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> >  
> >  
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> >  
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> >  
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> >  
> > 
> >  - Jay
> > <dif8.txt>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/f180057b/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  9 07:03:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 01:03:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
Message-ID: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>

On 9 Jan 2010, at 00:50, Jay K wrote:

> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.

> Also, I really think mixed arithmetic is ok.

But are you ok with:

(LAST(INTEGER) + 1) = FIRST(INTEGER)

while

(LAST(INTEGER) + 1L) # FIRST(INTEGER)

?

I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 

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

From jay.krell at cornell.edu  Sat Jan  9 07:59:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 06:59:52 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>


I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/71f3af0e/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 08:01:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:01:47 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>


 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 08:52:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:52:29 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	, , <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W589E03B28FAE7C3BAF1521E66F0@phx.gbl>


ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];

VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs








 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 10:04:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:04:03 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W177E347253C078605A975CE66F0@phx.gbl>


Uh, maybe all ordinal types that overlap in any values are assignable?

 

 

PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if they have at least one member in common. *)
      IF GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;
    ELSIF IsSubtype (a, b) THEN
      (* may be ok, but must narrow rhs before doing the assignment *)
      RETURN IsSubtype (b, Reff.T)
          OR ArrayType.Split (b, i, e)
          OR (IsSubtype (b, Addr.T)
              AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
    ELSE
      RETURN FALSE;
    END;
  END IsAssignable;


 

?

I'll try it out.

 

 

What is an ordinal type?, I wonder, the compiler implementation:

 

 

PROCEDURE IsOrdinal (t: T): BOOLEAN =
  VAR u := Check (t);  c := u.info.class;
  BEGIN
    RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
           OR (c = Class.Enum) OR (c = Class.Error)
           OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
  END IsOrdinal;


 

 - Jay





 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 07:52:29 +0000



ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];
VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




 > (LAST(INTEGER) + 1) = FIRST(INTEGER)

ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000



I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




On 9 Jan 2010, at 00:50, Jay K wrote:


I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.



Yes, that would be why.


Also, I really think mixed arithmetic is ok.



But are you ok with:


(LAST(INTEGER) + 1) = FIRST(INTEGER)


while


(LAST(INTEGER) + 1L) # FIRST(INTEGER)


?


I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!



 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3191062e/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 10:34:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:34:06 +0000
Subject: [M3devel] index array by longint?
Message-ID: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>


Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

  Or really, with runtime bounds check against the array size.

 

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

 

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/7d9b10b0/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 11:22:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 10:22:21 +0000
Subject: [M3devel] another longint variant
Message-ID: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>


[attached]

In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.

 


Specifically:

  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)

 


  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length

   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then

 


  no VAL or ORD needed


 

  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"

 


  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment.txt>

From hosking at cs.purdue.edu  Sat Jan  9 19:24:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:24:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <0D79BD22-2EB9-4EC8-A453-CC2E0A66AA8C@cs.purdue.edu>

The patch I sent to you yesterday will achieve checked assignment of LONGINT to/from INTEGER.

On 9 Jan 2010, at 04:04, Jay K wrote:

> Uh, maybe all ordinal types that overlap in any values are assignable?
>  
>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127 
> 
> either:
>   is true
>   or false 
>   or raises an exception 
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127 
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;   
>   INTEGER first := 16_80; 
>   INTEGER p1 := max + 1; 
>   LONGINT p1L := max + 1L; 
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.
> 
> Yes, that would be why.
> 
> Also, I really think mixed arithmetic is ok.
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!
> 
> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 
> 
> 

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

From hosking at cs.purdue.edu  Sat Jan  9 19:25:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:25:23 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <CC8493F7-82F9-4004-8B0F-D470B1FFDCC1@cs.purdue.edu>

I think having assignability let's you do what you need.  The range check on assignment will then allow you to index...

On 9 Jan 2010, at 04:34, Jay K wrote:

> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sat Jan  9 19:30:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:30:55 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
Message-ID: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...

On 9 Jan 2010, at 05:22, Jay K wrote:

> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/59f2afbb/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 20:33:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 19:33:45 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
Message-ID: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>


I don't believe that suffices but I can check again.

 

 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/992ac302/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  9 20:52:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 14:52:19 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
Message-ID: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>

It should suffice for assignability...

On 9 Jan 2010, at 14:33, Jay K wrote:

> I don't believe that suffices but I can check again.
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 

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

From rodney_bates at lcwb.coop  Sat Jan  9 20:50:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 13:50:25 -0600
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <4B48DE01.8040303@lcwb.coop>



Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> <mailto:hendrik at topoi.pooq.com> wrote:
> 
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability
>>> of INTEGER and LONGINT + mixed arithmetic.
>>
>> I thought Rodney's propsal still had the compiler impose a bound on the
>> size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as
>> long as he wishes.  And if the computer runs out of virtual memory to
>> store one of the programmer's long integers, well, that's the computer
>> imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to 
> decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine representation 
> based on the range of values in the subrange (much as it does currently).
> But if you really want to have an arbitrary range type I would argue it 
> is much better to implement it as a library than as a primitive type.

This I agree with wholeheartedly.  Don't we already have some math libraries
for things like this, or maybe rational arithmetic, etc?


> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele 
> <http://video.google.com/videoplay?docid=-8860158196198824415>


From jay.krell at cornell.edu  Sat Jan  9 21:17:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:17:32 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
Message-ID: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>


[replacing periods with semicolons to avoid truncation..]

 

 

Right..I was going to say..as an overall change, like if we

want mixed operations, it really doesn't suffice;

Many of my m3front changes were in direct response

to compilation errors and fixed them;

 

 

I'm sure as well that just allowing assignability doesn't make the rd/wr

change particuarly small/smooth. You need mixed operations,

indexing, new, or else sprinkle ORD around;

 

 

There's a particular characteristic I should point out in the rd/wr code;

Maybe rd/wr should be modified..but it probably can't;

In particular, my understanding of rd/wr is that the maintain two

"numbers" (integer or longint, depending on how everything is resolved);

These numbers indicate the file offset that is at the start of the buffer

and at the end of the buffer. In a new world they need to be LONGINT;

However their "span", their difference, describes an

in-memory buffer size. Therefore their difference is always INTEGER

or CARDINAL, not LONGINT. It'd be super cool, but probably not

possible, if the language let you declare this somehow.

THEN mixed operations and such wouldn't be needed,

if the compiler new that subtracting these two integers

yielded an INTEGER, and possibly inserted checks of that;

But this is probably just a lazy user view and not realistic

for the language.

 

 

For assignability I think your change does work but mine was less wordy

and maybe more general;

The preexisting code allowed I believe any non-LONGINT ordinal

type to be assigned to any non-LONGINT ordinal type if there

are any overlapping values. Specifically really,

non-ordinal types with same base type and anyoverlap.

I removed the base type check;

This makes enums <=> longint, integer subranges <=> longint, etc;

 

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 14:52:19 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant




It should suffice for assignability...


On 9 Jan 2010, at 14:33, Jay K wrote:

I don't believe that suffices but I can check again.
 
 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/067315ea/attachment.html>

From jay.krell at cornell.edu  Sat Jan  9 21:20:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:20:32 +0000
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>,<4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>,
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>,
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <COL101-W417229BE8A4B934A7D89EBE66F0@phx.gbl>


Yes we have some such libraries;

The "problem" is that libraries are inconvenient and in-fix operatores are convenient;

You either need to:

   accept that and use what works

   or make the language amenable to more convenient libraries

    (i.e. provide for operator overloading in the language)

   or make more stuff "built in" / "special"

 

 

We will probably just do the first.

LONGINT will probably just always be exactly 64bits, no more, no less,

and have the same overflow features as INTEGER;

 

It'd be nifty for me if the frontend learned to do arbitrary precision

integer arithmetic, because then NT386 would get a working LONGINT that way;

But that's not a valid reason. :)

 

 - Jay


 
> Date: Sat, 9 Jan 2010 13:50:25 -0600
> From: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT
> 
> 
> 
> Tony Hosking wrote:
> > On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> > <mailto:hendrik at topoi.pooq.com> wrote:
> > 
> >> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >>> I think what you are advocating is Rodney's proposal + assignability
> >>> of INTEGER and LONGINT + mixed arithmetic.
> >>
> >> I thought Rodney's propsal still had the compiler impose a bound on the
> >> size of LONGINT. Or did I miss something?
> > 
> > Yes, it would.
> > 
> >> I'm proposing to let the programmer use subranges of LONGINT that are as
> >> long as he wishes. And if the computer runs out of virtual memory to
> >> store one of the programmer's long integers, well, that's the computer
> >> imposing the limit, not the language.
> > 
> > But there is still the question as to what *representation* is used to 
> > decide the particular operation to apply.
> > 
> > I suppose the compiler could choose a particular machine representation 
> > based on the range of values in the subrange (much as it does currently).
> > But if you really want to have an arbitrary range type I would argue it 
> > is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly. Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?
> 
> 
> > 
> > Just for fun, I suggest you take some time to watch the talk Growing a 
> > Language, by Guy Steele 
> > <http://video.google.com/videoplay?docid=-8860158196198824415>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3432e1d0/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  9 21:21:43 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:21:43 -0500
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <B79AEE7D-4178-44E1-AD26-29488EC8FC40@cs.purdue.edu>

On 9 Jan 2010, at 14:50, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com <mailto:hendrik at topoi.pooq.com> wrote:
>>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>>> I think what you are advocating is Rodney's proposal + assignability
>>>> of INTEGER and LONGINT + mixed arithmetic.
>>> 
>>> I thought Rodney's propsal still had the compiler impose a bound on the
>>> size of LONGINT.  Or did I miss something?
>> Yes, it would.
>>> I'm proposing to let the programmer use subranges of LONGINT that are as
>>> long as he wishes.  And if the computer runs out of virtual memory to
>>> store one of the programmer's long integers, well, that's the computer
>>> imposing the limit, not the language.
>> But there is still the question as to what *representation* is used to decide the particular operation to apply.
>> I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
>> But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly.  Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?

Yes, the arithmetic package (m3-libs/arithmetic).

From hosking at cs.purdue.edu  Sat Jan  9 21:54:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:54:22 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>

On 9 Jan 2010, at 15:17, Jay K wrote:

> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;

I'd like precise examples.

>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.

>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.

That would be tricky...

>  For assignability I think your change does work but mine was less wordy
> and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.

> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;

That's what broke it.

> This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?

I really want to see the impact of not allowing mixed arithmetic while having assignability.

> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/19f37b03/attachment.html>

From rodney_bates at lcwb.coop  Sat Jan  9 23:15:16 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 16:15:16 -0600
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <4B48FFF4.8050307@lcwb.coop>



Tony Hosking wrote: (excerpted)
>........................................
>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
> 
> Currently, direct comparison between LONGINT and INTEGER is not 
> permitted.  If it were then this would be true.
> 


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

> 
>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>    like" (but is not equal to) [0..LAST(LONGINT)].
>>
>>      The current CARDINAL has an interesting history.  Originally, it
>>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>>      was later changed to be "just like" the subrange, i.e., the two
>>      are not the same type, but have the same properties in every
>>      other respect.  The only reason for the change had to do with
>>      reading pickles, which are completely defined and implemented as
>>      library code.  The change did affect the type analysis of the
>>      language, nevertheless.
>>
>>      We should preserve this property for LONGCARD too.
> 
> Currently there is no implementation of LONGCARD.  I argue that we don't 
> need LONGCARD (since, as discussed below, NUMBER should stay typed as 
> CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

>> 20. The statement that the upperbound of a FOR loop should not be
>>    LAST(INTEGER) also applies to LAST(LONGINT).
> 
> Agreed.
> 
>>      Note that the existing definition of FOR otherwise generalizes
>>      to LONGINT without change.
> 
> The current implementation does not permit the range values to be 
> different types (both must be INTEGER or LONGINT), and the step value 
> must also match.  Will we permit any mixing of values?  If so, I assume 
> that we use the maximal type of the expressions (LONGINT if any one is 
> LONGINT, INTEGER otherwise).
>

I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


>> 22. There is a new required interface LongWord.  It almost exactly
>>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>    new functions ToWord and FromWord, that conversion between the two
>>    types, using unsigned interpretations of the values.  ToInt may
>>    produce a checked runtime error, if the result value is not in the
>>    range of an unsigned interpretation of INTEGER.
> 
> This is the current implementation, but we do not support ToWord and 
> FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

> 
>>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>      consistency.  This means simple assignability tests and
>>      assignments between the types will use signed interpretations.
>>      So different functions are needed to do size changes with
>>      unsigned interpretation.
> 
> This is the current implementation.
> 
>


From hosking at cs.purdue.edu  Sat Jan  9 23:45:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:45:09 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B48FFF4.8050307@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
Message-ID: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>

Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote: (excerpted)
>> ........................................
>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
> I remember there was some vexing problem about what the result type
> should be for FIRST and LAST, but not the details.  It seems to
> me now that the only thing that makes any sense is to preserve the
> existing rule that it is the base type of the argument type.
> This is really necessary to preserve existing semantics of the
> language and of existing code.
> 
> This original proposal seems to be silent on the matter, which I suppose
> means I intended it as a NO CHANGE.  I guess, if
> mixed relations are allowed, then I can't think of a problem
> with this.  Even if mixed relations are disallowed, this range
> constraint could be expressed with explicit conversions, I suppose.
> 
> .......................................................................
> 
>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>> 
>>>     The current CARDINAL has an interesting history.  Originally, it
>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>     was later changed to be "just like" the subrange, i.e., the two
>>>     are not the same type, but have the same properties in every
>>>     other respect.  The only reason for the change had to do with
>>>     reading pickles, which are completely defined and implemented as
>>>     library code.  The change did affect the type analysis of the
>>>     language, nevertheless.
>>> 
>>>     We should preserve this property for LONGCARD too.
>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> LONGCARD is needed for pickles (and for no other reason, that I can
> think of).  The problem is that if a record or object has a field of
> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
> the type to be different on different target machines, making a pickle
> written on, say a 32-bit machine unreadable on a 64-bit machine.
> LONGCARD can be treated as the same type regardless of word size,
> allowing the automatic size changes pickles already does for INTEGER,
> CARDINAL, and LONGINT to extend to this subrange too.
> 
> (Note: If you try to extend this size-changing by pickles to arbitrary
> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
> are jumping head first into a tar pit.  I've thought about it just enough
> to conclude I wanted to step back.)
> 
> .......................................................................
> 
>>> 20. The statement that the upperbound of a FOR loop should not be
>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>> Agreed.
>>>     Note that the existing definition of FOR otherwise generalizes
>>>     to LONGINT without change.
>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>> 
> 
> I think allowing mixtures here is going too far.  Moreover, the existing
> rule for FOR already requires the same base type for the two bounds, unlike
> the assignability rule for operators, so unless we change an existing
> language rule here, this form of mixing is not allowed.
> 
> Note that the step value is "integer-valued" unconditionally, i.e.,
> even if the bounds have, say, an enumeration type.  Taken literally, I
> would say this would allow its type to be INTEGER, LONGINT, or any subrange
> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
> a use.
> 
> ......................................................................
> 
> 
>>> 22. There is a new required interface LongWord.  It almost exactly
>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>   new functions ToWord and FromWord, that conversion between the two
>>>   types, using unsigned interpretations of the values.  ToInt may
>>>   produce a checked runtime error, if the result value is not in the
>>>   range of an unsigned interpretation of INTEGER.
>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> All the operations in Word apply an unsigned interpretation to the bits
> of the word, whereas the operators and functions in the language apply
> signed.  Unsigned expansion is different(zero extend) from signed (sign
> extend).  FromWord would do the unsigned, while VAL would do the signed.
> 
> Similarly, for contracting, the value range check is different.  Signed
> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
> 32 are all zero.
> 
>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>     consistency.  This means simple assignability tests and
>>>     assignments between the types will use signed interpretations.
>>>     So different functions are needed to do size changes with
>>>     unsigned interpretation.
>> This is the current implementation.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/179319ae/attachment.html>

From hosking at cs.purdue.edu  Sat Jan  9 23:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:48:05 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <337A4383-95A2-4767-8A9E-4C8EEE88B5AC@cs.purdue.edu>

Actually, that doesn't make sense -- it is an empty subrange.

On 9 Jan 2010, at 17:45, Tony Hosking wrote:

> Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:
> 
>> 
>> 
>> Tony Hosking wrote: (excerpted)
>>> ........................................
>>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
>> 
>> 
>> I remember there was some vexing problem about what the result type
>> should be for FIRST and LAST, but not the details.  It seems to
>> me now that the only thing that makes any sense is to preserve the
>> existing rule that it is the base type of the argument type.
>> This is really necessary to preserve existing semantics of the
>> language and of existing code.
>> 
>> This original proposal seems to be silent on the matter, which I suppose
>> means I intended it as a NO CHANGE.  I guess, if
>> mixed relations are allowed, then I can't think of a problem
>> with this.  Even if mixed relations are disallowed, this range
>> constraint could be expressed with explicit conversions, I suppose.
>> 
>> .......................................................................
>> 
>>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>>> 
>>>>     The current CARDINAL has an interesting history.  Originally, it
>>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>>     was later changed to be "just like" the subrange, i.e., the two
>>>>     are not the same type, but have the same properties in every
>>>>     other respect.  The only reason for the change had to do with
>>>>     reading pickles, which are completely defined and implemented as
>>>>     library code.  The change did affect the type analysis of the
>>>>     language, nevertheless.
>>>> 
>>>>     We should preserve this property for LONGCARD too.
>>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
>> 
>> LONGCARD is needed for pickles (and for no other reason, that I can
>> think of).  The problem is that if a record or object has a field of
>> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
>> the type to be different on different target machines, making a pickle
>> written on, say a 32-bit machine unreadable on a 64-bit machine.
>> LONGCARD can be treated as the same type regardless of word size,
>> allowing the automatic size changes pickles already does for INTEGER,
>> CARDINAL, and LONGINT to extend to this subrange too.
>> 
>> (Note: If you try to extend this size-changing by pickles to arbitrary
>> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
>> are jumping head first into a tar pit.  I've thought about it just enough
>> to conclude I wanted to step back.)
>> 
>> .......................................................................
>> 
>>>> 20. The statement that the upperbound of a FOR loop should not be
>>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>>> Agreed.
>>>>     Note that the existing definition of FOR otherwise generalizes
>>>>     to LONGINT without change.
>>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>>> 
>> 
>> I think allowing mixtures here is going too far.  Moreover, the existing
>> rule for FOR already requires the same base type for the two bounds, unlike
>> the assignability rule for operators, so unless we change an existing
>> language rule here, this form of mixing is not allowed.
>> 
>> Note that the step value is "integer-valued" unconditionally, i.e.,
>> even if the bounds have, say, an enumeration type.  Taken literally, I
>> would say this would allow its type to be INTEGER, LONGINT, or any subrange
>> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
>> a use.
>> 
>> ......................................................................
>> 
>> 
>>>> 22. There is a new required interface LongWord.  It almost exactly
>>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>>   new functions ToWord and FromWord, that conversion between the two
>>>>   types, using unsigned interpretations of the values.  ToInt may
>>>>   produce a checked runtime error, if the result value is not in the
>>>>   range of an unsigned interpretation of INTEGER.
>>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
>> 
>> All the operations in Word apply an unsigned interpretation to the bits
>> of the word, whereas the operators and functions in the language apply
>> signed.  Unsigned expansion is different(zero extend) from signed (sign
>> extend).  FromWord would do the unsigned, while VAL would do the signed.
>> 
>> Similarly, for contracting, the value range check is different.  Signed
>> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
>> 32 are all zero.
>> 
>>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>>     consistency.  This means simple assignability tests and
>>>>     assignments between the types will use signed interpretations.
>>>>     So different functions are needed to do size changes with
>>>>     unsigned interpretation.
>>> This is the current implementation.
>>> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 00:47:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:47:16 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W503E27DAB92E218864CB0BE66F0@phx.gbl>


On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


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

From jay.krell at cornell.edu  Sun Jan 10 00:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:48:41 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W345C207A34D36A982DD968E66F0@phx.gbl>


Sorry, right, I read 16_FFFFFFFF as 16_7FFFFFFFF.
Is this "not full range" thing we've been vaguly mentioning.
Guessing, I think it is easier to define with the "half range".
"All cardinals fit in integers" ?
Something like that?
No range check needed moving between them?

 - Jay






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] LONGINT, my original proposal
Date: Sat, 9 Jan 2010 23:47:16 +0000








On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


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

From jay.krell at cornell.edu  Sun Jan 10 01:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:05:23 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
Message-ID: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>


Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:12:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:12:06 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	, , <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>


 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:15:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:15:33 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>


Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000








 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From hosking at cs.purdue.edu  Sun Jan 10 01:21:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 19:21:38 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
Message-ID: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>

On 9 Jan 2010, at 19:15, Jay K wrote:

> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.

I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/2db04789/attachment.html>

From mika at async.async.caltech.edu  Sun Jan 10 01:25:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 09 Jan 2010 16:25:52 -0800
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl> 
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
Message-ID: <20100110002552.683AA1A2078@async.async.caltech.edu>

Jay K writes:
>--_953e6126-a89e-4966-8f22-5ccff92e7117_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
> > I believe Rodney said something like "mixed operations follow from assig=
>nability"=3B
> > and from a language point of view=2C that may be true=2C just not from t=
>he point of view=3B
>
>I meant to say=2C not from the language implementation point of view.
>
>Again=2C if I can assign and then add=2C might as well just allow add?
>Ditto assign and index=2C assign and multiply=2C etc.
>

The problem is that it's sometimes ambiguous what the result type is.

If you want to get into this kind of mess, why don't you just program in C...

I think this area is probably one of the reasons some people *like* Modula-3.
We don't want to have to guess what an expression means... it should be obvious.
If there are "promotion rules" it's just not that obvious.  I'm reminded of one
time when I was missing a prototype in a C program.............. ok that story
could go on and on.

    Mika



From jay.krell at cornell.edu  Sun Jan 10 01:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:31:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	,,<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	,,<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	,,<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	, , <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>


I noticed unary plus doesn't seem to be valid for LONGINT.
That is fixed among my other diffs.

I understand it matters little to take this "algorithmic" approach to determining
if an AddExpr is valid. We haven't yet agreed it will even change from current,
though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
and then add it, or vice versa, why not just allow the direct addition?
Force the programmer through hoops so the code is much clearer?
Or too verbose?

 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 19:21:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 19:15, Jay K wrote:Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000

 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>



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

From rodney_bates at lcwb.coop  Sun Jan 10 02:29:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 19:29:32 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
	<COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
Message-ID: <4B492D7C.9070800@lcwb.coop>



Jay K wrote:
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?

Whether mixed comparison is allowed or an explicit conversion is coded
before comparing, the representation conversion of the value of p1 to
LONGINT will do a sign extension, because INTEGER and LONGINT are
both signed.  Or rather, all the builtin operations apply signed
interpretation.

If instead, you converted p1 to LONGINT via the Long.FromWord I proposed,
then it would be a zero extension.  This can only be done explicitly.

The comparison would always be done in 16 bits, unless you explicitly
converted the LONGINT operand.down to 8 first.

> 
> 
> And heck, shouldn't max + 1 already throw an exception?

This is a separate issue.  I have always been very skeptical about silently
ignoring overflow.  But all the questions about INTEGER and LONGINT really
hinge only on the question of when does an overflow occur, not what happens
when it does.

> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From jay.krell at cornell.edu  Sun Jan 10 03:05:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 02:05:24 +0000
Subject: [M3devel] IsAssignable
Message-ID: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>


Current:


PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if there is a common supertype
         and they have at least one member in common. *)
      IF IsEqual (Base(a), Base(b), NIL)
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

my proposed:




PROCEDURE IsAssignable (a, b: T): BOOLEAN =

  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;

  BEGIN

    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN

      RETURN TRUE;

    ELSIF IsOrdinal (a) THEN

      (* ordinal types:  OK if they have at least one member in common. *)

      IF GetBounds (a, min_a, max_a)

         AND GetBounds (b, min_b, max_b) THEN

        (* check for a non-empty intersection *)

        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;

        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;

        RETURN TInt.LE (min, max);

      ELSE

        RETURN FALSE;

      END;



Your proposed:

> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN

What's the point of checking the types? Given that they are both ordinal?
To restrict certain assignments?
Aren't the base types of any ordinal type either Int.T or LInt.T?
 So the check will always be true?
I have to check.


 - Jay

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

From rodney_bates at lcwb.coop  Sun Jan 10 03:34:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:34:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <4B493CBF.4080302@lcwb.coop>



hendrik at topoi.pooq.com wrote:
>> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

And:

 > Is it even necessary for a compiler to implement -128..127 as more than
 > one byte?


And:

 >> One thing that is very much needed in a language (not the only thing)
 >> is a type that always matches the implementation's native arithmetic
 >> size, which is most efficient.  If you don't distinguish this type,
 >> it becomes either impossible or horribly convoluted to define arithmetic
 >> so native machine arithmetic can be usually used where possible,
 >> but multi-word arithmetic will be used where needed.
 >
 > Yes.  You do need this type.  And you can even call it INTEGER.  But is
 > there any reason it cannot be a predefined subrange type of LONGINT?

When storing a value in a variable, the compiler can store subranges in fields
just big enough to hold the value range, or somewhere between that size and
the size of the base type.  Sometimes, like -128..127, it probably should store
it in a byte, and if the type is BITS 10 FOR 0..1023 and it's a field or array
element, it must store in exactly 10 bits.

But the question that creates trouble is not how many bits to store variables
in, but how many bits to do arithmetic in.  This affects when/whether overflows
can occur.  I define an overflow as a case where the mathematically correct
value is, for whatever reason, not what you get.  By "mathematically
correct", I mean in the system of (unbounded) integers, not a modular arithmetic.
The usual reason you don't get the correct value is that it won't fit in the
field you are doing arithmetic in.

What happens then is an orthogonal question.  Is there an exception?  Do we
have a code like a NaN?  Does it wrap modulo the word size? random bits?
But our problems with INTEGER and LONGINT have only to do with when does an
overflow happen.

In Modula-3 and with only INTEGER and its subranges, the arithmetic is always
done in the full range of INTEGER, even if the operands have subrange types.
This follows from the facts that:

1) The language defines (for the + example) only + (x,y: INTEGER) : INTEGER,
    but not any + operations on any subrange(s) of INTEGER.

2) The operands of + have no parameter mode specified, which means the mode
    is VALUE.

3) The rule for VALUE mode is that the actual parameter need only be assignable
    to the formal, not necessarily of the same type.

So if we have VAR a: [0..10];  VAR b: [20..30];, then the expression a+b
is evaluated by effectively doing the assignments x:=a, y:=b to the formals
x and y of +, before evaluating the +.  At the machine level, the compiler will
have to do a representation conversion of each subrange by expanding it to
a full integer, then do the add on these, with an INTEGER result.  And the
range of INTEGER then determines when overflows occur.  Moreover, a reasonable
implementation will choose the range of INTEGER to match the native machine
arithmetic of the target machine, which is the most efficient arithmetic
available.

This is about as near to tidy a way as possible to cope with the very untidy
fact that computer arithmetic on what we call "integers" is different from the
integers of mathematics.

Now suppose we need a larger-than-native range arithmetic for selected purposes.
If we try to do it by just having one integer type that is as large as anybody
could want and then let programmers choose a subrange othat happens
to match the target's native arithmetic, whenever that is enough range,
it gets a lot uglier.  Storing variables of this subrange in native words
will work fine.

But the size arithmetic is done in is the problem.  The only way to preserve
the relative tidiness  of the system of subranges would be to have every
subrange value's representation expanded to the largest size, then do
the arithmetic in that size.  But this loses the efficiency of native
arithmetic on _every_ operation, something we just can't afford.

So INTEGER has to have some special properties that arbitrary subranges
do not, namely that it is a size arithmetic is done in, if neither operand
has a larger range.  Having two distinct base types is a lot cleaner
and less misleading than trying to pretend that INTEGER is just a particular
case of a subrange.

This is messy.  But it's about the best we can do, given the difference
between efficient hardware "integer" arithmetic and the integer arithmetic
of mathematics.

Note that you can't fix this by trying to use the value range of where the
final expression result is to be assigned/passed/whatever.  Then the rules
just get a whole lot more complicated (for programmer and compiler alike),
and the cases where overflow can occur get a lot harder to anticipate.  And the
likelihood they are what is wanted is not good either.  You might have a
distant chance at this if an expression could have at most one operator,
but multiple operators and intermediate results make it a tar pit.




From hendrik at topoi.pooq.com  Sun Jan 10 03:57:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 21:57:56 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <20100110025755.GA17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
> Do you recall why CARDINAL is defined to behave like 
> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?

It's so that all CARDINALs are INTEGERs, presumably back when it was 
thought important to have only one base type on top of the type 
hierarchy.  I've always thought that was a mistake.

The simplest way to avoid that with LONGINT is to let programmers use 
only subranges of LONGINT, and to impose no limit on those subranges 
except for mamory capacity.

This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
either.

-- hendrik


From rodney_bates at lcwb.coop  Sun Jan 10 03:44:26 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:44:26 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <4B493F0A.7030500@lcwb.coop>



Jay K wrote:
> Uh, maybe all ordinal types that overlap in any values are assignable?
>  

Yes, exactly.  From 2.3.1:

   "A type T is _assignable_ to a type U if:
   .. <two other cases,> ..
   or T and U are ordinal types with at least one member in common."

For an _expression_ to be assignable to T, some additional things must
be checked, some of them at runtime.

>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = 
> Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127
> 
> either:
>   is true
>   or false
>   or raises an exception
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the 
> comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently 
> implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:04:13 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:04:13 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <20100110030412.GB17629@topoi.pooq.com>

On Sun, Jan 10, 2010 at 12:05:23AM +0000, Jay K wrote:
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?

Let's add -16_080000003L to +16_7ffffffff.
The sum should be 4.
What you propose will give overflow when assigning LONGINT to INTEGER.
You have to do the addition as LONGINT and then assign the sum to 
INTEGER.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 10 04:07:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:07:25 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <20100110030725.GC17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 07:21:38PM -0500, Tony Hosking wrote:
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> > Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> > However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> > FooExpr.m3 file, not just delegate to IsAssignable;
> > Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> > the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get 
> carried away thinking there'll be more.

There will be more, sooner or later.  Let's design for more, even if we 
don't implement it all right away.

-- hendrik



From rodney_bates at lcwb.coop  Sun Jan 10 03:54:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:54:51 -0600
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <4B49417B.7060806@lcwb.coop>

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
     denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
     designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
     to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a 
> common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:28:28 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:28:28 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B493CBF.4080302@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
	<4B493CBF.4080302@lcwb.coop>
Message-ID: <20100110032828.GD17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 08:34:39PM -0600, Rodney M. Bates wrote:
> 
> 
> But the question that creates trouble is not how many bits to store 
> variables
> in, but how many bits to do arithmetic in.  This affects when/whether 
> overflows
> can occur.  I define an overflow as a case where the mathematically correct
> value is, for whatever reason, not what you get.  By "mathematically
> correct", I mean in the system of (unbounded) integers, not a modular 
> arithmetic.
> The usual reason you don't get the correct value is that it won't fit in the
> field you are doing arithmetic in.
> 
> In Modula-3 and with only INTEGER and its subranges, the arithmetic is 
> always
> done in the full range of INTEGER, even if the operands have subrange types.
...
...
> 
> But the size arithmetic is done in is the problem.  The only way to preserve
> the relative tidiness  of the system of subranges would be to have every
> subrange value's representation expanded to the largest size, then do
> the arithmetic in that size.  But this loses the efficiency of native
> arithmetic on _every_ operation, something we just can't afford.
> 
> So INTEGER has to have some special properties that arbitrary subranges
> do not, namely that it is a size arithmetic is done in, if neither operand
> has a larger range.  Having two distinct base types is a lot cleaner
> and less misleading than trying to pretend that INTEGER is just a particular
> case of a subrange.
> 
> This is messy.  But it's about the best we can do, given the difference
> between efficient hardware "integer" arithmetic and the integer arithmetic
> of mathematics.
> 
> Note that you can't fix this by trying to use the value range of where the
> final expression result is to be assigned/passed/whatever.  Then the rules
> just get a whole lot more complicated (for programmer and compiler alike),
> and the cases where overflow can occur get a lot harder to anticipate.  And 
> the
> likelihood they are what is wanted is not good either.  You might have a
> distant chance at this if an expression could have at most one operator,
> but multiple operators and intermediate results make it a tar pit.
> 
> 

GOt that.  INTEGER is not a subrange of LONGINT because its arithmetic 
is different.

And the reason INTEGER has all its restrictions is simply to be 
able to use efficient machine arithmetic, and to make it clear that 
efficient machine arithmetic will be used.  This is why we don't 
expand "every subrange value's representation ... to the largest size, 
then do the arithmetic in that size."

But it is quite possible to performs operation on LONGINT subranges to 
produce results that are as long as necessary to be mathematically 
exact, because the whole point of LONGINT is to use it for numbers that 
do not fit the word size for the most efficient machine arithmetic.  
We're want to use subranges of LONGINT that match the requirements of 
an application, whether those subranges fit the most desirable machine 
word size or not.

-- hendrik



From hosking at cs.purdue.edu  Sun Jan 10 05:12:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:12:22 -0500
Subject: [M3devel] IsAssignable
In-Reply-To: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
References: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
Message-ID: <B816E60E-8AEB-4CD5-97C7-54FA0B235ED3@cs.purdue.edu>

Base type of an enumeration is itself!

On 9 Jan 2010, at 21:05, Jay K wrote:

> Current:
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if there is a common supertype
>          and they have at least one member in common. *)
>       IF IsEqual (Base(a), Base(b), NIL)
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> my proposed:
> 
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> 
> Your proposed:
> 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> 
> What's the point of checking the types? Given that they are both ordinal?
> To restrict certain assignments?
> Aren't the base types of any ordinal type either Int.T or LInt.T?
>  So the check will always be true?
> I have to check.
> 
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/42598f72/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:13:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:13:13 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <20100110025755.GA17629@topoi.pooq.com>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
	<20100110025755.GA17629@topoi.pooq.com>
Message-ID: <9CFA3CF7-98EE-430E-B0C3-8575FBF1A732@cs.purdue.edu>

That is a drastic (and I think fatal) departure from the spirit of the language.

On 9 Jan 2010, at 21:57, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
>> Do you recall why CARDINAL is defined to behave like 
>> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> It's so that all CARDINALs are INTEGERs, presumably back when it was 
> thought important to have only one base type on top of the type 
> hierarchy.  I've always thought that was a mistake.
> 
> The simplest way to avoid that with LONGINT is to let programmers use 
> only subranges of LONGINT, and to impose no limit on those subranges 
> except for mamory capacity.
> 
> This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
> either.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Sun Jan 10 05:14:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:14:57 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, , ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, , ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
	<COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
Message-ID: <4440BF94-9372-4A3E-B0BF-03A5DFEA7E45@cs.purdue.edu>

On 9 Jan 2010, at 19:31, Jay K wrote:

> I noticed unary plus doesn't seem to be valid for LONGINT.
> That is fixed among my other diffs.
> 
> I understand it matters little to take this "algorithmic" approach to determining
> if an AddExpr is valid. We haven't yet agreed it will even change from current,
> though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
> and then add it, or vice versa, why not just allow the direct addition?
> Force the programmer through hoops so the code is much clearer?

Yes, clarity is important.

> Or too verbose?

Verbosity is sometimes valuable.  It spells things out.

> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 19:21:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
> 
> I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/5f1ae41d/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:16:37 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:16:37 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <CD3E8BA5-E655-4253-A4CE-52A3FECBE3C2@cs.purdue.edu>

Hear, hear!

On 9 Jan 2010, at 19:25, Mika Nystrom wrote:

> Jay K writes:
>> --_953e6126-a89e-4966-8f22-5ccff92e7117_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>>> I believe Rodney said something like "mixed operations follow from assig=
>> nability"=3B
>>> and from a language point of view=2C that may be true=2C just not from t=
>> he point of view=3B
>> 
>> I meant to say=2C not from the language implementation point of view.
>> 
>> Again=2C if I can assign and then add=2C might as well just allow add?
>> Ditto assign and index=2C assign and multiply=2C etc.
>> 
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious.  I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
>    Mika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/1f6e1958/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:22:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:22:44 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <4B49417B.7060806@lcwb.coop>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
	<4B49417B.7060806@lcwb.coop>
Message-ID: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>

That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.

For example:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

did not result in a run-time error.  I think I have fixed that now (commit to come).

But, even worse:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;

also does not give a run-time error.

The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!

On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
>> Index array by longint?
>> With runtime check that it is <= LAST(INTEGER)?
>>  Or really, with runtime bounds check against the array size.
>> Seems reasonable?
>> Aids the rd/wr change.
>> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>>   - Jay

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

From hosking at cs.purdue.edu  Sun Jan 10 05:33:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:33:57 -0500
Subject: [M3devel] Integer overflow
Message-ID: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>

So, in my experiments with range checking on integers, I have been playing with the overflow case:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

Should this fail at runtime with a range check error?

The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).

If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From hosking at cs.purdue.edu  Sun Jan 10 05:38:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:38:42 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <B808326A-8BD2-416B-8F7D-032FCA29E05E@cs.purdue.edu>

One take on this is that it certainly lets you check for overflow explicitly! ;-)

On the other hand, it seems unreasonable that you could end up with a CARDINAL holding a negative value!

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 05:42:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 04:42:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
Message-ID: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>


There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?



That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
    designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
    to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
  Or really, with runtime bounds check against the array size.
 Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
   - Jay

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

From hosking at cs.purdue.edu  Sun Jan 10 05:45:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:45:29 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>

Even under the interpretation for INC that yields:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;

the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.

In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 



From hosking at cs.purdue.edu  Sun Jan 10 05:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:46:39 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
Message-ID: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>

I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.

On 9 Jan 2010, at 23:42, Jay K wrote:

> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 07:11:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 06:11:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
Message-ID: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;
c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay



Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu



I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
On 9 Jan 2010, at 23:42, Jay K wrote:There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?

That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
 Or really, with runtime bounds check against the array size.
Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
  - Jay


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

From hosking at cs.purdue.edu  Sun Jan 10 08:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 02:37:45 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
Message-ID: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>

Try to frame this in terms of assignability...

If the operators themselves were typed then there would be no problem.

But when they aren't we get into a real mess trying to remember what the promotion rules are.

On 10 Jan 2010, at 01:11, Jay K wrote:

> I don't think there is madness here.
> I believe the half range of CARDINAL helps avoid it.
> A confusing point in C is comparison that includes conversion
> is magnitude or sign preserving -- comparing int and unsigned.
> 
> Back to Modula-3:
> 
> a := b;
> c := a + d;
> 
> vs.
> 
> c := b + d;
> 
> 
> are different?
> Isn't that strange?
> 
> 
> Compare with
> a : = b;
> c := d[a];
> 
> and
> 
> c := d[b];
> 
> we have decided they are the same, among others.
> 
> 
> There's something about "kinda sorta transitive" here.
> Or, like, "why should I have to move values through temporaries in some
> cases but not others?"
> 
>  - Jay
> 
> 
> 
> Subject: Re: [M3devel] index array by longint?
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:46:39 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
> 
> On 9 Jan 2010, at 23:42, Jay K wrote:
> 
> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 08:58:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 07:58:56 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>, ,
	<4B49417B.7060806@lcwb.coop>, ,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>,
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>, ,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>,
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>,
	<3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
Message-ID: <COL101-W39FE16CBEE45212C4E6979E66E0@phx.gbl>


It is easy to frame in terms of assignability?

  a + b is legal if a is assignable to b, or b is assignable to a  

 

If you don't allow INTEGER := LONGINT,

then you can say, like:

 

a + b is legal if a is assignable to b or b is assignable a (or both);

if a and b are of different type, and only one is assignable to the

other, then the result type is that of the assignable-to type.

 

If INTEGER := LONGINT, then I'm not sure how to formally

define the result. Something informal:

a + b is legal if a or b is assignable to the other

the result type is the "larger" or "wider" type -- whatever that means;

However, I think there is an easy enough to define set of rules.

It varies for each operator though.

 

Basically, first, the notion of "larger" or "wider" isn't

all that unscientific. It needs a little honing though;

 

 

a + b is legal if a is assignable to b or b is assignable to a (or both).

If a and b are of the same type, that is the result type.

If a and b are of different types, but one of their types can

  represent without loss all the values of the other type,

  then that is the result type.

If a and b are of different types, and neither type can represent

  all of the values of the other type, then the result type is

   INTEGER if it can represent all the members of the types of a and b,

   else LONGINT.

 

 

The result type is stated in terms of the input types.

Not in terms of the output range.

This is a general fact of life with addition anyway.

The result of adding two integers is an integer, even though integer

cannot hold the output range.

 

 

I have a strong suspicion that we would be more satisified

with our rules if overflow checking was present.

 

 

Heck, maybe we'd have something wierd where INTEGER + INTEGER

actually yielded LONGINT, but then LONGINT is assignable to INTEGER?

The overflow check would actually be at the assignment/narrowing?

Heck, it's not like double precision arithmetic is even so expensive?

 

 

What do you mean by, reworded, "the operators aren't typed"

 

 

- Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 02:37:45 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




Try to frame this in terms of assignability...


If the operators themselves were typed then there would be no problem.


But when they aren't we get into a real mess trying to remember what the promotion rules are.


On 10 Jan 2010, at 01:11, Jay K wrote:


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;

c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay





Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu


I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.





On 9 Jan 2010, at 23:42, Jay K wrote:

There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.


For example:


VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;


did not result in a run-time error.  I think I have fixed that now (commit to come).


But, even worse:


VAR s: CARDINAL := LAST(INTEGER);

BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;


also does not give a run-time error.


The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!



On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:

Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

 Or really, with runtime bounds check against the array size.

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

  - Jay



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

From jay.krell at cornell.edu  Sun Jan 10 09:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 08:55:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>,
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63918AA105D02C46D86E5AE66E0@phx.gbl>


> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.


You were using a bad compiler or at least bad switches:

C:\>type t.c


void F1()
{
 F2();
}

C:\>cl -c -W4 -WX t.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
t.c(5) : error C2220: warning treated as error - no 'object' file generated
t.c(5) : warning C4013: 'F2' undefined; assuming extern returning int

 

and C++ always errors.


 - Jay

 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant 
> Date: Sat, 9 Jan 2010 16:25:52 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >--_953e6126-a89e-4966-8f22-5ccff92e7117_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> > > I believe Rodney said something like "mixed operations follow from assig=
> >nability"=3B
> > > and from a language point of view=2C that may be true=2C just not from t=
> >he point of view=3B
> >
> >I meant to say=2C not from the language implementation point of view.
> >
> >Again=2C if I can assign and then add=2C might as well just allow add?
> >Ditto assign and index=2C assign and multiply=2C etc.
> >
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
> Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5f4fff7d/attachment.html>

From jay.krell at cornell.edu  Sun Jan 10 10:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>


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/d57d8efd/attachment.html>

From jay.krell at cornell.edu  Sun Jan 10 10:52:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:52:32 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <COL101-W1505A74E8F75378C40431DE66E0@phx.gbl>


Well, I have to take that back.

I'm reading Rodney's proposal.

  https://mail.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.txt 

 

Notable so far:

  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.

  He defines ORD as possibly returning LONGINT. Which breaks my assertion below.

  But he doesn't allow indexing an array by LONGINT.

  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?

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?



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/e9197775/attachment.html>

From jay.krell at cornell.edu  Sun Jan 10 11:26:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken
Message-ID: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>


Tony, with the recent changes:

 

1)

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...


 

2) If I fix that by removing cas/casp more completely:


 

C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3

(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>

 

looks like maybe an off by one problem?

Since the pointer is near valid memory?

Any ideas?

I'll poke around.

 

 

Going back to the release branch versions fixes this.

 

 

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

From jay.krell at cornell.edu  Sun Jan 10 11:38:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:38:52 +0000
Subject: [M3devel] m3front broken
In-Reply-To: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
References: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
Message-ID: <COL101-W56F490C4603C9ADBA56B01E66E0@phx.gbl>


nevermind, I see the problem, fix shortly

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken



Tony, with the recent changes:
 
1)
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...

 
2) If I fix that by removing cas/casp more completely:

 
C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3
(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>
 
looks like maybe an off by one problem?
Since the pointer is near valid memory?
Any ideas?
I'll poke around.
 
 
Going back to the release branch versions fixes this.
 
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/82998d8b/attachment.html>

From jay.krell at cornell.edu  Sun Jan 10 12:29:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 11:29:21 +0000
Subject: [M3devel] yet another longint rendition -- just mutual
 assignability, result is very tedious
Message-ID: <COL101-W345041876AF820EABD01D9E66E0@phx.gbl>


These diffs show what you can do if you merely allow assignability between

integer and longint, both ways.

  The compiler diff is included.

This is just what it takes to get libm3 to compile, having

changed a few integer to longint.

It's pretty awful in my opinion.

No changed made outside m3front and libm3, and there

  would surely be "many" needed, like the first set of diffs I sent.

  (I think those were written with no compiler change at all.)

 

I believe people wanted to see what this looks like.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment.txt>

From hosking at cs.purdue.edu  Sun Jan 10 15:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 09:30:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>

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 | Mobile +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/280301a9/attachment.html>

From rcolebur at SCIRES.COM  Sun Jan 10 21:00:58 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Sun, 10 Jan 2010 15:00:58 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100110051218.2F3C42474001@birch.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>

I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


From hosking at cs.purdue.edu  Sun Jan 10 21:23:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:23:28 -0500
Subject: [M3devel] Integer literals
Message-ID: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>

One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).

It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)

Here's how things would work with subrange types.

A subrange written as currently

[lo .. hi]

would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.

A subrange with base type LONGINT would be written explicitly:

[lo .. hi] OF LONGINT

The constants lo/hi must both be in range for LONGINT.

We could also support the form:

[lo .. hi] OF INTEGER

just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.

Here we are allowing the programmer to state explicitly what the base type of the subrange should be.

Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Sun Jan 10 21:34:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:34:59 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W6B928C524DCF7E4AF027AE66E0@phx.gbl>


> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 

 

Have you seen the resulting diffs?

 

 

Would we just say, that the initial rd/wr interface was so wrong, that there

is a lot of "incorrect" code, so the ugly diff is the result?

That newer code wouldn't be so initially wrong, so would remain not so ugly?

Maybe.

 

 

VAR a:LONGINT;

      b:INTEGER;

INC(a, b);

 

 

doesn't that make perfect sense to even the most casual reader?

Many current proposals don't allow it.

  Though Randy's does allow it.

 

 

Indexing by LONGINT is also trivial.

Just do the usual range check and go.

Indexing by INTEGER also has a range check.

One difference would be that a subrange of LONGINTs that are all greater than LAST(INTEGER) could be a stack error, just as some indexing by INTEGER subranges can also be a static error (e.g. if the array element size times the all the elements of the subrange or enum are larger than the address space).

 

 

 > We need correct and maintainable software, especially at the systems level

 

Nearly all systems level software is written in a language or languages that manage to zero extend or sign extend integers to wider integers.

The Modula-3 compiler/runtime/garbage collector is the biggest exception I can think of, but so far it can't really handle large files.

 

 

 - Jay

 
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sun, 10 Jan 2010 15:00:58 -0500
> Subject: [M3devel] the LONGINT proposal
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1. LONGINT should be a distinct type different from INTEGER.
> 
> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 3. Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake. I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions. We need correct and maintainable software, especially at the systems level. Whatever is decided about LONGINT, we need to keep to the original design tenants of the language. 
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type. That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance. Programs should be written to run forever or until their job is completed or they are commanded to stop. 
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal. Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all? To me this keeps the discussion focused rather than the many different emails. Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects. Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing. Who should be involved in such votes? Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/a6f5921b/attachment.html>

From hendrik at topoi.pooq.com  Sun Jan 10 21:38:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 15:38:32 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <20100110203832.GA16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

And what would be the type of 2000000000 + 2000000000?  Overflow because 
2000000000 is an INTEGER?
Whereas 3000000000 + 3000000000 would end up being LONGINT?

The only solutions I see for this problem are:

(a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

or

(b) Let operations on integers automatically produce values of 
sufficiently large ranges to be able to contain the results.

(b) seems to be incompatible with the use of the most efficient integer 
operations on a machinem=, which are of fixed bit-width.

(a) is what's proposed for the LONGINT extension.

It would be possible to combine (a) and (b), using (b) only for LONGINT, 
but you seem to be dead set against this.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Sun Jan 10 21:42:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:42:55 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:

> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn

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

From jay.krell at cornell.edu  Sun Jan 10 21:43:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:43:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>


Seems fine either way.

Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
 

 

And then, if that is true, mixing should be allowed..widen any constituents

in an expression to the widest type.

 

 

I realize mixing floating point and integer is less natural, nothing about

floating point is natural really, though on a 32bit platform

LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 

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

From jay.krell at cornell.edu  Sun Jan 10 21:45:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:45:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
Message-ID: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>


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/e5dd2ebf/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 10 21:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:48:21 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100110203832.GA16635@topoi.pooq.com>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<20100110203832.GA16635@topoi.pooq.com>
Message-ID: <63BBCB94-EB03-45FE-B13A-4AC4F273E538@cs.purdue.edu>

On 10 Jan 2010, at 15:38, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
>> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> 
>> Here's how things would work with subrange types.
>> 
>> A subrange written as currently
>> 
>> [lo .. hi]
>> 
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> 
>> A subrange with base type LONGINT would be written explicitly:
>> 
>> [lo .. hi] OF LONGINT
>> 
>> The constants lo/hi must both be in range for LONGINT.
>> 
>> We could also support the form:
>> 
>> [lo .. hi] OF INTEGER
>> 
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> 
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
>> 
>> Literals would be be range-checked when used as arithmetic operands or 
>> in assignment, with compile-time checks that they are in range 
>> ("compatible") with the types of the other operands or the destination 
>> of the assignment.
> 
> And what would be the type of 2000000000 + 2000000000?  Overflow because 
> 2000000000 is an INTEGER?

Constant expressions would retain their "value" nature so long as the expression can be computed at compile-time without overflow up to the precision of LONGINT.

> Whereas 3000000000 + 3000000000 would end up being LONGINT?
> 
> The only solutions I see for this problem are:
> 
> (a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

This is the current implementation.  0 and 0L are the same value as INTEGER and LONGINT.

> 
> or
> 
> (b) Let operations on integers automatically produce values of 
> sufficiently large ranges to be able to contain the results.

Problematic because it imposes expensive operations on natural integers.

> (b) seems to be incompatible with the use of the most efficient integer 
> operations on a machinem=, which are of fixed bit-width.

Right.

> (a) is what's proposed for the LONGINT extension.

Not just proposed.  Implemented now for over a year.

> It would be possible to combine (a) and (b), using (b) only for LONGINT, 
> but you seem to be dead set against this.

Indeed, I am.

> 
> -- hendrik
> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 



From hosking at cs.purdue.edu  Sun Jan 10 21:51:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:51:17 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
Message-ID: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>

No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.

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

> Seems fine either way.
> Assignability gives us, which we were missing before, VAR a:LONGINT := 0;
> 
> 
>  > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
>  > do have incompatible value representations).
>  
>  
> I keep seeing this and am surprised.
> Isn't it the case that REAL <= LONGREAL <= EXTENDED
> in terms of precision and range?
> LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
> EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
>  
>  
> And then, if that is true, mixing should be allowed..widen any constituents
> in an expression to the widest type.
>  
>  
> I realize mixing floating point and integer is less natural, nothing about
> floating point is natural really, though on a 32bit platform
> LONGREAL can hold all INTEGERS..
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 15:23:28 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] Integer literals
> 
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> 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
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sun Jan 10 21:52:16 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:52:16 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <ED3D3FD1-0327-4B52-9559-864AD7BEEE52@cs.purdue.edu>

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.html>

From jay.krell at cornell.edu  Sun Jan 10 21:53:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:53:12 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>


(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.html>

From jay.krell at cornell.edu  Sun Jan 10 22:00:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 21:00:15 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>,
	<95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
Message-ID: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>


Hm..these hardware conversions..yeah they do exist.

But they are fast and lossless.

Depending on the instruction set, they aren't even avoidable.

  e.g. x86 I think usually does double arithmetic.

        68K maybe extended.

But to be clear, they tend to be a single instruction each, load or move.

Every INTEGER can be represented in a LONGINT, by sign extension.

Every REAL can be represented as LONGREAL. 

And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

 I was surprised by that actually, stepping through some hash table code,

   but it is just the way it is. There's I guess no integer division and

   the floating point is done with 64 or more bits of precision, so it works.

 

 

As long as conversion is fast and lossless..?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:51:17 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Integer literals




No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.


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

Seems fine either way.
Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not); 
 
And then, if that is true, mixing should be allowed..widen any constituents
in an expression to the widest type.
 
 
I realize mixing floating point and integer is less natural, nothing about
floating point is natural really, though on a 32bit platform
LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 


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

From hosking at cs.purdue.edu  Sun Jan 10 22:06:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:06:06 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
Message-ID: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>

Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.

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

> (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/a37318d7/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 10 22:08:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:08:18 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
References: <20100110164332.0c09a257.dimonax@att.net>
Message-ID: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>

This guy is trying to subscribe to m3devel.  Can someone help him?

Begin forwarded message:

> From: Chris <dimonax at att.net>
> Date: 10 January 2010 16:43:32 EST
> To: Tony Hosking <hosking at cs.purdue.edu>
> Subject: Re: CM3 development Inquiry.
> 
> On Fri, 8 Jan 2010 13:01:21 -0500
> Tony Hosking <hosking at cs.purdue.edu> wrote:
> 
>> Did you manage to subscribe?
> 
> I put in another subscription request just after your previous reply, and I'm still waiting. I wonder if the confirmation e-mail is getting through. Nonetheless, I'll keep trying.
> 
> 
> -- 
> Chris <dimonax at att.net>

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

From jay.krell at cornell.edu  Sun Jan 10 23:02:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:02:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	,,<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	,,<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	, , <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
Message-ID: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>


Is it really just me who finds the choices all fairly obvious?

You do the math in the wider type. Is that really surprising?

  Am I just, like, brain washed with years of assumptions?

That's what Rodney's proposal said.

In the case of MOD and DIV, you can pause for thought

and maybe make them return a narrower type, but

if you just want to be simple and stay wide, that's ok.

 

 - Jay


 


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




Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.


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

(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      +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      +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/085ab3d2/attachment.html>

From hendrik at topoi.pooq.com  Sun Jan 10 23:11:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 17:11:37 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
Message-ID: <20100110221137.GB16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> 
> And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

Just for clarity, do you mean the Itanium here?

-- hendrik


From jay.krell at cornell.edu  Sun Jan 10 23:22:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:22:00 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100110221137.GB16635@topoi.pooq.com>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>,
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>,
	<20100110221137.GB16635@topoi.pooq.com>
Message-ID: <COL101-W30198A34B16863265449FCE66E0@phx.gbl>


Yes of course.

  echo %PROCESSOR_ARCHITECTURE%  

 

 - Jay


 
> Date: Sun, 10 Jan 2010 17:11:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> > 
> > And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?
> 
> Just for clarity, do you mean the Itanium here?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/0fab823d/attachment.html>

From jayk123 at hotmail.com  Mon Jan 11 05:58:13 2010
From: jayk123 at hotmail.com (jayk123 at hotmail.com)
Date: Sun, 10 Jan 2010 20:58:13 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, , ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, , ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
	<COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
Message-ID: <BLU0-SMTP21D313FA40787E6A124A47E66D0@phx.gbl>

To repeat myself: you can reason about + via assignability, sort of.  
Of the two input types, you see which is assignable to which, and  
conceptually assign the inputs to two temporaries of that type.  
Assuming longint *not* assignable to integer, done. If it is  
assignable, pick the type that can guaranteeably hold all values of  
the two inputs.

In terms of implict vs. explict..I fallback to my usual claim: what  
people already probably think of as simple very often is not. The "red  
flag" of "complexity", I find, is raised very quickly, when people  
just don't like something.

I think there might be another way though. What if rd/wr users had to  
change *lots* of types from integer and cardinal to longint..and index  
by longint allowed? Maybe maybe that'd have a "pleasant" outcome. But  
still, given that NUMBER returns CARDINAL, still must end up mixing  
somehow, either via implicit or explicit conversion/assignment.


Btw are C's rules really so different or complicated? Don't they look  
like "assignability" too? The one problem I know of is in comparison  
if "full range" unsigned types with signed types. There are two  
equally good/bad options: I think called "sign preserving" and  
"magnitude preserving" aka "magnitude losing" and "sign losing".  
Either a large positive number becomes negative or a negative number  
becomes a large positive. I believe avoidance of this problem is why  
CARDINAL is "half range".


  - Jay (phone)

On Jan 10, 2010, at 2:02 PM, Jay K <jay.krell at cornell.edu> wrote:

> Is it really just me who finds the choices all fairly obvious?
> You do the math in the wider type. Is that really surprising?
>   Am I just, like, brain washed with years of assumptions?
> That's what Rodney's proposal said.
> In the case of MOD and DIV, you can pause for thought
> and maybe make them return a narrower type, but
> if you just want to be simple and stay wide, that's ok.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 16:06:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>
> Consider the following:  + is overloaded to perform both INTEGER and  
> LONGINT addition.  When invoking + we choose the appropriate  
> operation based on its operand types.  Why do you think it is  
> reasonable to assume that LONGINT+INTEGER should perform LONGINT +  
> instead of INTEGER +?  It is an *arbitrary* choice that you make  
> which should give us pause in imposing that arbitrary choice in the  
> language because it violates the principle of least surprise.  Don't  
> impose arbitrary choices that may confuse the programmer.
> Prohibiting mixed-operand operations prevents bugs arising when one  
> programmer inadvertently assumes that his personal arbitrary choice  
> is not the one that the language actually implements.
>
> Assignability is different in that the assignment operation is  
> unambiguously tied to the type of its left-hand-side.  Assignment  
> forces a value into a particular representation -- that of the pre- 
> allocated "storage" designated by the LHS.  If the value is not  
> compatible with that representation then we can raise a run-time  
> error.
>
> On 10 Jan 2010, at 15:53, Jay K wrote:
>
> (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 
>       +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 
>       +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/b9b6e1d0/attachment.html>

From rcolebur at SCIRES.COM  Mon Jan 11 07:11:52 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 01:11:52 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:


I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/7e2517c3/attachment.html>

From wagner at elegosoft.com  Mon Jan 11 10:51:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 10:51:34 +0100
Subject: [M3devel] Truncation problem fixed,
	was: Re:  another longint	variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <20100111105134.4zr9fs0lc00wsok8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> [replacing periods with semicolons to avoid truncation..]

Mike has made a change some days ago that should fix the truncation
of mails at certain periods. If anybody experiences this again,
you should let him know.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Mon Jan 11 11:52:57 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 11:52:57 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
Message-ID: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> This guy is trying to subscribe to m3devel.  Can someone help him?
>
> Begin forwarded message:
>
>> From: Chris <dimonax at att.net>
>> Date: 10 January 2010 16:43:32 EST
>> To: Tony Hosking <hosking at cs.purdue.edu>
>> Subject: Re: CM3 development Inquiry.
>>
>> On Fri, 8 Jan 2010 13:01:21 -0500
>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>
>>> Did you manage to subscribe?
>>
>> I put in another subscription request just after your previous   
>> reply, and I'm still waiting. I wonder if the confirmation e-mail   
>> is getting through. Nonetheless, I'll keep trying.

Unfortunately the address does not work:

This is the mail system at host mx0.elegosoft.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
     521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
     Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
     command)

If he really wants to join, he needs another mail address, but I cannot
tell him that.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Jan 11 13:17:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:17:56 +0000
Subject: [M3devel] some more "crazy" proposals
Message-ID: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>


1) change file/rd/wr sizes to be BigInteger.T

and/or

2) Introduce SeekL, IndexL, StatusL, etc.
default implementation calls Seek/Index/Status and does checked truncation.
Clients gradually port to LONGINT or BigInteger.T.
Completely source compatible.


3) BigInteger.T is The multiple-INTEGER precision type??
No compiler/language change??


I might try these out, and then go the extra step and port the file dialog to avoid the exception..
see what it all looks like...

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/3b5d2620/attachment.html>

From jay.krell at cornell.edu  Mon Jan 11 13:14:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:14:06 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>


Randy I won't cover everything but on some of these matters you are not alone.
In particular, INTEGER and LONGINT are different types, in the current
implementation, and I think in all proposals.


It is quite striking how the current implemtation makes them completely different.
However many proposals do allow assignability which does make it a bit
blurry to a user what different types mean.
One thing that I bet will always remain though, is that VAR parameters of INTEGER
cannot "bind" to LONGINT, and vice versa.
The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
without a cast, even if int and long are both 32bit.
That is, in C and C++, int and long are different types, just as in Modula-3,
INTEGER and LONGINT are different types.


Which goes to show one of my agendas: C isn't as bad as people think.
It isn't safe, granted. There is no formal module system, but
people are actually usually rigorous in their use of the informal system.
As well, one of the goals I have espoused is that UNSAFE Modula-3 be
not more unsafe than C. Which is why I don't like procedures to return ADDRESS
and expect every caller to cast/loophole -- that is just more unsafe than things should be.


I have some familiarity with 8 and 16 bit integers.
We can perhaps claim that there is a hypothetical system
with 16bit INTEGER and 32bit LONGINT?
And that our proposals do work in such a system?


There is some disagreement floating around apparently on even what
to call the INTEGER <=> LONGINT conversions.
Currently ORD converts to INTEGER.
Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.


I believe I saw a proposal that the converesions be named after the type:
  INTEGER(expr), LONGINT(expr).

That kind of smacks to me of "too hard to search for".

Here is a crazy verbose suggestion:
 LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

and allow it in safe modules?
At least it is existing syntax with roughly the desired meaning,
except that LOOPHOLE is and sounds unsafe.

CAST(expr, type)
CONVERT(expr, type)
?

I'm just making up words here of course.
VAL or ORD seem sufficient, esp. if you can specify the type.

gotta go,
 - Jay


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 01:11:52 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal
















Tony:

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope (see below).  Using differently named conversion operators would
lesson some of the ugliness of ORD/VAL and also prevent confusion with their
intended use as enumeration/INTEGER conversions.

 

Read on for the long-winded version?

 

According to NELSON (SPwM3), ORD and VAL convert between enumerations
and INTEGERs, and INTEGER is all integers represented by the implementation. 
So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit
processors.  

 

Today we see 32-bit and 64-bit processors as predominant, but I
remember the day when 8-bit and 16-bit were the norm.  Someday we may see
128-bit processors as the norm.  

 

(I?ve been cleaning up my basement office and ran across a
box of 8-inch floppy disks.  When I showed them to my daughter she
understood the meaning of ?floppy? as opposed to the rigid 3.5-inch
floppies of today.  But, I digress.)

 

On a 64-bit processor, this whole idea of LONGINT as 64-bits then
becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine
(assuming we had an implementation for one) the native word size would be less
than the 32-bits we seem to take for granted now.

 

One problem is that one doesn?t really know the range of
LONGINT unless we define it as some number of bits.  Rodney?s
proposal simply stated that LONGINT was at least as big as INTEGER but could be
larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same
in terms of implementation?, whereas on a 32-bit the LONGINT would have an
additional 32-bits more than INTEGER?  What about a 128-bit machine?

 

I say all this to point out the obvious, namely that LONGINT and
INTEGER are different types.  

 

Therefore, IMO the language must make it clear how these
different types interact.

 

I would argue that 

   x: LONGINT := 23;

is wrong!  The programmer should have to write

   x: LONGINT := 23L;

instead.

 

A subrange of LONGINT would be written as [23L..4200L] and would
be a different type than the integer subrange [23..4200] even though the ranges
are identical.

 

Likewise, IMO mixed arithmetic with the compiler deciding what
to do is wrong.  The programmer should have to explicitly write
conversions to a common type for arithmetic.

 

I have no problem with extending the existing operators to deal
with LONGINT; it?s just that the result should be LONGINT.

Given x: LONGINT := 49L;

   INC(x) yields 50L

   INC(x, 3L) yields 52L

      note that INC(x, 3) would be a
syntax error since 3 is an INTEGER and x is a LONGINT

   (x + 20L) yields 69L

      note that (x + 20) would be a
syntax error since 20 is an INTEGER and x is a LONGINT

   LAST(LONGINT) yields a LONGINT

 

Now that I think about it more, I have a problem using ORD/VAL
for the conversion since NELSON defines these as converting between enumerations
and INTEGERs, and since LONGINT is a different type than INTEGER and quite
possibly has a greater range than INTEGER.  Is the proposal to also allow
enumerations to use the range of LONGINT ?  Enumerations currently are
defined as having a range no greater than INTEGER.  To extend them to
LONGINT would lose the obvious performance benefits of keeping them same range
as native INTEGER.

 

Maybe we should invent new names for the conversions between
INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These
are probably bad names, but I use them below simply to illustrate (feel free to
come up with better names):

   Given longInt: LONGINT;   and  
int: INTEGER;

   int := DEMOTE(longInt); would perform the
conversion from LONGINT to INTEGER and would give a runtime range check error if
longInt is too big/small to fit in an INTEGER.

   longInt := PROMOTE(int) would always succeed in
performing the conversion from INTEGER to LONGINT but would make the conversion
explicit

   int + DEMOTE(longInt) would yield an INTEGER result
with all arithmetic being done in the range of INTEGER

   longInt + PROMOTE(int) would yield a LONGINT result
with all arithmetic being done in the range of LONGINT

 

Now if we were to allow checked assignability (as Tony is
leaning toward), I think we begin to get on the slippery slope.  How far
do we extend this to the point that it is not clear in the expression of the
code what is happening?  If I can write ?int := longInt;? why
not ?int := 23L;? and why not ?int := longInt + 57;?
and is this different than ?int := longInt + 57L;?? etc. etc.

 

I agree the ORD/VAL syntax is ugly, so that is another reason
(besides them applying to enumerations only) we should use different names for
the INTEGER/LONGINT conversions.

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope.  Using differently named conversion operators would lesson some of
the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER
conversions.

 

Regards,

Randy Coleburn

 





From: Tony Hosking [mailto:hosking at cs.purdue.edu]


Sent: Sunday, January 10, 2010 3:43 PM

To: Randy Coleburn

Cc: m3devel

Subject: Re: [M3devel] the LONGINT proposal





 



Hi Randy,





 





As someone who has actually written
Modula-3 programs for a living your opinions are always highly valued.  I
agree with you in principle and aims, except for requiring overflow to be a
checked run-time error.  The language definition already has a mechanism
for handling this in the require FloatMode interface.  It is not something
that the compiler should be involved in.  I also just now raised
a question about perhaps having integer literals adapt their type to the
context in which they are used.





 





I should point out that the current
mainline implementation does exactly what you propose (except overflow
checking).  It captures the fundamental spirit of Rodney's proposal but
does not permit mixed arithmetic or assignment.  Can I ask what your issue
is w.r.to checked assignability?  I am still leaning in favor.  It is
not much different from assignment from an INTEGER to a subrange, which
requires no explicit check, though of course there is a run-time range check.  Having
programmers explicitly write:





 





x: INTEGER := ORD(longint,
INTEGER);





 





seems unnecessary when they could
just write





 





x: INTEGER := longint;





 









This
is similar in spirit to:









 





x: [lo..hi] := integer;





 





 







On 10 Jan 2010, at 15:00, Randy
Coleburn wrote:











I've been trying to follow along on
this topic.



Here are my thoughts:



1.  LONGINT should be a distinct type different from INTEGER.



2.  There should be no mixed arithmetic between the types.  The
programmer must code conversions using ORD/VAL to make explicit the intention.
 Don't rely on some ill-remembered built-in conversion rule.



3.  Overflow should be a checked run-time error, not silently wrapped
around.



4.  WRT assignability, I think explicit conversions should be used.



These statements may make me unpopular with some who don't like to type much,
but I've always hated the tradeoff of understandability for brevity in
expression.



The important thing is not how fast we can type up a program, it is rather how
hard is it to make a mistake.  I think the spirit of Modula-3 is that the
language makes you a better programmer by forcing you to make your intentions
explicit rather than relying on the compiler to infer your intentions.  We
need correct and maintainable software, especially at the systems level.
 Whatever is decided about LONGINT, we need to keep to the original design
tenants of the language.  



And yes, I do think we need a LONGINT type, not just to deal with large file
sizes.



But even for long-lived readers/writers, whatever type you choose for the index
will eventually be insufficient, so you have to code for the possibility that
the range of the long lived reader/writer exceeds the range of your index type.
 That is just good programming.



I think sometimes that the new generation of programmers has been warped by
what I call the "Microsoft Mentality" where you must expect that you
need to reboot/restart every so often to maintain proper performance.
 Programs should be written to run forever or until their job is completed
or they are commanded to stop.  



As "we" begin to converge on the design changes, I like having
something concrete to look at, ala Rodney's proposal.  Can we take that
and keep tweaking it in these emails until we reach a final version acceptable
to all?  To me this keeps the discussion focused rather than the many
different emails.  Thus, what I am trying to say is put forth a numbered
proposal and each subsequent email must show adjustment to that proposal rather
than just a bunch of emails discussing various aspects.  Perhaps we should
vote on each proposed change, then decide to call a final vote on the whole
thing.  Who should be involved in such votes?  Right now the main
persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.



My two cents.



Regards,

Randy Coleburn





 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/62da63a9/attachment.html>

From hendrik at topoi.pooq.com  Mon Jan 11 17:23:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Mon, 11 Jan 2010 11:23:01 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <20100111162301.GA23072@topoi.pooq.com>

On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.
> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
> 
> 
> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).
> 
> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
> 
> and allow it in safe modules?
> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.
> 
> CAST(expr, type)
> CONVERT(expr, type)
> ?
> 
> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

NARROW?  WIDEN?

And TRUNCATE if you really want to chop off the high-order bits without 
overflow check?

-- hendrik


From hosking at cs.purdue.edu  Mon Jan 11 18:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:12:25 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
Message-ID: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>

Actually, that diagnostic indicates that scc-mailrelay.att.net is blocking messages from the Elegosoft mail server (it is blacklisted!).

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 11 Jan 2010, at 05:52, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> This guy is trying to subscribe to m3devel.  Can someone help him?
>> 
>> Begin forwarded message:
>> 
>>> From: Chris <dimonax at att.net>
>>> Date: 10 January 2010 16:43:32 EST
>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>> Subject: Re: CM3 development Inquiry.
>>> 
>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>> 
>>>> Did you manage to subscribe?
>>> 
>>> I put in another subscription request just after your previous  reply, and I'm still waiting. I wonder if the confirmation e-mail  is getting through. Nonetheless, I'll keep trying.
> 
> Unfortunately the address does not work:
> 
> This is the mail system at host mx0.elegosoft.com.
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> For further assistance, please send mail to postmaster.
> 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> 
>                   The mail system
> 
> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>    command)
> 
> If he really wants to join, he needs another mail address, but I cannot
> tell him that.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/56b71c66/attachment.html>

From hosking at cs.purdue.edu  Mon Jan 11 18:32:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:32:13 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:

> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.

>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.

>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 

Correct.  The current implementation treats them as completely separate.

>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.

This is what we currently implement.

>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.

>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.

>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.

>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.

>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...

>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

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

From hosking at cs.purdue.edu  Mon Jan 11 18:42:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:00 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <90520DA3-BD5C-494F-875B-F77910088E0B@cs.purdue.edu>

On 11 Jan 2010, at 07:14, Jay K wrote:

> Randy I won't cover everything but on some of these matters you are not alone.
> In particular, INTEGER and LONGINT are different types, in the current
> implementation, and I think in all proposals.
> 
> 
> It is quite striking how the current implemtation makes them completely different.
> However many proposals do allow assignability which does make it a bit
> blurry to a user what different types mean.
> One thing that I bet will always remain though, is that VAR parameters of INTEGER
> cannot "bind" to LONGINT, and vice versa.
> The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
> without a cast, even if int and long are both 32bit.
> That is, in C and C++, int and long are different types, just as in Modula-3,
> INTEGER and LONGINT are different types.

But C has a much looser design philosophy than Modula-3.  We should not compromise Modula-3 by veering towards C.

> Which goes to show one of my agendas: C isn't as bad as people think.
> It isn't safe, granted. There is no formal module system, but
> people are actually usually rigorous in their use of the informal system.
> As well, one of the goals I have espoused is that UNSAFE Modula-3 be
> not more unsafe than C. Which is why I don't like procedures to return ADDRESS
> and expect every caller to cast/loophole -- that is just more unsafe than things should be.
> 
> 
> I have some familiarity with 8 and 16 bit integers.
> We can perhaps claim that there is a hypothetical system
> with 16bit INTEGER and 32bit LONGINT?
> And that our proposals do work in such a system?
> 
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.

I suppose ORD could convert to the underlying type, but given the intention that it be used to convert from an enumeration to an integer, then I think hardwiring it to return INTEGER is OK, since no enumeration will/should contain more elements than can be indexed by an INTEGER.  On the other hand, I see no real problem if ORD(longint) returns LONGINT.  It just means you have to do one more step to get an integer using VAL.

> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.

Yes, this is what we also currently implement.

> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).

I proposed that originally, but then decided that reusing VAL seemed much more intuitive.  After all, we are asking to treat a typed expression in one domain as a *value* in some other type domain, so long as the value has a representative in that domain.

> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

LOOPHOLE implies an unsafe operation!

> and allow it in safe modules?

Yuck!!!!!!!!!!!!!!!!

> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.

I vote we stick with VAL.

> CAST(expr, type)
> CONVERT(expr, type)
> ?

Yuck!


> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

Agreed!

> 
> gotta go,
>  - Jay
> 
> 
> From: rcolebur at SCIRES.COM
> To: hosking at cs.purdue.edu
> Date: Mon, 11 Jan 2010 01:11:52 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] the LONGINT proposal
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

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

From hosking at cs.purdue.edu  Mon Jan 11 18:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:34 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100111162301.GA23072@topoi.pooq.com>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
	<20100111162301.GA23072@topoi.pooq.com>
Message-ID: <06DE4262-4D34-4908-9367-C277E1556416@cs.purdue.edu>

We have Word.T and Long.T to handle masking the higher-order bits.

On 11 Jan 2010, at 11:23, hendrik at topoi.pooq.com wrote:

> On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
>> 
>> There is some disagreement floating around apparently on even what
>> to call the INTEGER <=> LONGINT conversions.
>> Currently ORD converts to INTEGER.
>> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
>> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
>> 
>> 
>> I believe I saw a proposal that the converesions be named after the type:
>>  INTEGER(expr), LONGINT(expr).
>> 
>> That kind of smacks to me of "too hard to search for".
>> 
>> Here is a crazy verbose suggestion:
>> LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
>> 
>> and allow it in safe modules?
>> At least it is existing syntax with roughly the desired meaning,
>> except that LOOPHOLE is and sounds unsafe.
>> 
>> CAST(expr, type)
>> CONVERT(expr, type)
>> ?
>> 
>> I'm just making up words here of course.
>> VAL or ORD seem sufficient, esp. if you can specify the type.
> 
> NARROW?  WIDEN?
> 
> And TRUNCATE if you really want to chop off the high-order bits without 
> overflow check?
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Mon Jan 11 19:39:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 13:39:21 -0500
Subject: [M3devel] some more "crazy" proposals
In-Reply-To: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
References: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
Message-ID: <69F1DBED-115F-44A5-93D6-7C2375EC3E8E@cs.purdue.edu>

Jay, as you'll note from the commit messages, I've made ORD/VAL consistent with Rodney's proposal.
I think this is much more consistent, in treating VAL as the only *conversion* operator for ordinals.
ORD is really just there to allow conversion of enumerations to INTEGER, but for consistency it makes sense to have ORD return the underlying value without any conversion.  This makes the equality:

ORD(n) = VAL(ORD(n), T) = n

where T is the type of n.

Unfortunately, it also means that your uses of ORD in the Rd/Wr code must now turn into VAL(n, INTEGER).

On 11 Jan 2010, at 07:17, Jay K wrote:

> 1) change file/rd/wr sizes to be BigInteger.T
> 
> and/or
> 
> 2) Introduce SeekL, IndexL, StatusL, etc.
> default implementation calls Seek/Index/Status and does checked truncation.
> Clients gradually port to LONGINT or BigInteger.T.
> Completely source compatible.
> 
> 
> 3) BigInteger.T is The multiple-INTEGER precision type??
> No compiler/language change??
> 
> 
> I might try these out, and then go the extra step and port the file dialog to avoid the exception..
> see what it all looks like...
> 
>  - Jay



From rodney_bates at lcwb.coop  Tue Jan 12 01:18:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:18:46 -0600
Subject: [M3devel] Mixed arithmetic
Message-ID: <4B4BBFE6.1090701@lcwb.coop>

Well, I have been mistaken.  I finally found the statement about argument
types of builtin operators.  Every time I go looking for this, I have trouble
finding it.  I had remembered it wrongly.  It does not say an actual argument must
be assignable to the type in the signature, it says it must be a _subtype_
of the type in the signature.  Actually, it says the overloading is resolved
using the subtype relation, but this has the same effect on what is and
isn't statically legal.

(2.6.1):  The particular operation will be selected so that each actual
           argument type is a subtype of the corresponding formal type or
           a member of the formal type class.

So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
rules.  We would have to insert 4 different overloaded signatures for
+, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
language changes for LONGINT a lot simpler.

This weakens my support of mixed arithmetic.

However, there is still some messiness to be resolved.  The relations do use
assignability rather than subtyping, in such a way that mixed comparisons
do fall out of the existing rules.  (The overload resolution is done on
type class, not type, and doesn't, by itself, preclude mixed INTEGER/
LONGINT comparisons.)  Then there are a lot of other places
that use assignability.  They are:

- assignment statements
- passing parameters to VALUE or READONLY formals
- passing VAR open array parameters (a different kind of assignability, not
      really relevant)
- RAISE statements
- RETURN statements
- Initial value assignment in a VAR declaration
- array subscripts in designators a[i]
- elements of set, array, and record constructors
- relational operators, including IN
- ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)

I too am generally a fan of syntactic explicitness, rather than having things
happen behind the scenes, without the programmer's coding them.  But if we
disallow mixed arithmetic operations, it seems to me that it becomes
quite arbitrary where we are allowing assignability and where we are
requiring explicit type conversions.

Without LONGINT in the picture, this arbitrariness didn't happen, because
there was no case where assignability vs. subtyping for the arguments of
the arithmetic operators made any difference.

I do think it would be particularly inconsistent to disallow the mixed
arithmetic but allow mixed relations.  As Tony has pointed out, these
two differ from the other uses of assignability in having two expressions
whose types must be used to infer a common value range to do the operation
in.  All the other uses of assignability have only one "target" type to
assign to.


From rodney_bates at lcwb.coop  Tue Jan 12 01:25:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:25:37 -0600
Subject: [M3devel] Integer overflow
In-Reply-To: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
Message-ID: <4B4BC181.8020807@lcwb.coop>

If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
I think wrapping around to the maximal negative value would be reasonable.  Even for
CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
done in the full INTEGER range).  But then the assignment of the result back to the
CARDINAL variable really must do a range check.  This derives from the assignment
x:= ... in the WITH equivalent, not from the + 1 operation.

Mainly, there is a pervasive principle in the safety of the language that you can
never get a bit pattern stored in a variable that does not map back to an abstract
value of its type.  We really need to preserve this.

Tony Hosking wrote:
> Even under the interpretation for INC that yields:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
> 
> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
> 
> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
> 
> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
> 
>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN INC(s) END;
>>
>> Should this fail at runtime with a range check error?
>>
>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>
>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
> 
> 


From rodney_bates at lcwb.coop  Tue Jan 12 01:45:27 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:45:27 -0600
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <4B4BC627.6030103@lcwb.coop>



Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is 
> the need for distinct literal forms.  This strikes me as odd, since 
> literals are really just ways of writing values, rather than stating 
> anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, 
> but they really do have incompatible value representations).

I agree, the need for distinctly typed literals is much greater for the
floating types than the integer types, because they can't be viewed
as having overlapping value sets in any reasonable way.

> 
> It strikes me that with checked assignability for INTEGER/LONGINT we 
> could also potentially treat integer literals as essentially "untyped" 
> (neither INTEGER nor LONGINT). (I still strongly resist going the route 
> of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants 
> lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be 
> unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base 
> type of the subrange should be.

This would eliminate _one_ reason for needing distinct integer literals.

> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

The reason I proposed the distinct literals is because of feeling very
badly burned by Ada.  It has a type "universal integer", which is builtin,
and all integer literals have this type.  They have unbounded range and
a complete set of arithmetic operators, which can only be evaluated at
compile time.  The type "universal integer" can't be named in source
code.

The rules for when they are converted to a type having a runtime representation
are complicated, messy, highly surprising, and a huge complication of the
language.  Static type information can propagate a long way through
language constructs.  The programmer's dilemma in figuring out just what
is happening is much worse than arithmetic operators that accept mixed
sizes and do the computation in the larger size.

Maybe the semantics of this idea could be done better than in Ada, but I spent
a lot of time trying, and didn't come up with anything that wasn't both too
complicated and not worth the gain, IMO.

We should come up with a complete language proposal before going this way.


> 

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Tue Jan 12 02:02:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 20:02:01 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <DB1A2DAE-CCAD-44EF-9687-DAD88C216DF3@cs.purdue.edu>

My firm position now is that we continue to disallow both mixed arithmetic *and* assignability, and stick with the status quo as described at:

http://www.cs.purdue.edu/~hosking/m3/reference/index.html
http://www.cs.purdue.edu/homes/hosking/m3/reference/complete/m3-defn-complete.pdf

On 11 Jan 2010, at 19:18, Rodney M. Bates wrote:

> Well, I have been mistaken.  I finally found the statement about argument
> types of builtin operators.  Every time I go looking for this, I have trouble
> finding it.  I had remembered it wrongly.  It does not say an actual argument must
> be assignable to the type in the signature, it says it must be a _subtype_
> of the type in the signature.  Actually, it says the overloading is resolved
> using the subtype relation, but this has the same effect on what is and
> isn't statically legal.
> 
> (2.6.1):  The particular operation will be selected so that each actual
>          argument type is a subtype of the corresponding formal type or
>          a member of the formal type class.
> 
> So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
> rules.  We would have to insert 4 different overloaded signatures for
> +, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
> language changes for LONGINT a lot simpler.
> 
> This weakens my support of mixed arithmetic.
> 
> However, there is still some messiness to be resolved.  The relations do use
> assignability rather than subtyping, in such a way that mixed comparisons
> do fall out of the existing rules.  (The overload resolution is done on
> type class, not type, and doesn't, by itself, preclude mixed INTEGER/
> LONGINT comparisons.)  Then there are a lot of other places
> that use assignability.  They are:
> 
> - assignment statements
> - passing parameters to VALUE or READONLY formals
> - passing VAR open array parameters (a different kind of assignability, not
>     really relevant)
> - RAISE statements
> - RETURN statements
> - Initial value assignment in a VAR declaration
> - array subscripts in designators a[i]
> - elements of set, array, and record constructors
> - relational operators, including IN
> - ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)
> 
> I too am generally a fan of syntactic explicitness, rather than having things
> happen behind the scenes, without the programmer's coding them.  But if we
> disallow mixed arithmetic operations, it seems to me that it becomes
> quite arbitrary where we are allowing assignability and where we are
> requiring explicit type conversions.
> 
> Without LONGINT in the picture, this arbitrariness didn't happen, because
> there was no case where assignability vs. subtyping for the arguments of
> the arithmetic operators made any difference.
> 
> I do think it would be particularly inconsistent to disallow the mixed
> arithmetic but allow mixed relations.  As Tony has pointed out, these
> two differ from the other uses of assignability in having two expressions
> whose types must be used to infer a common value range to do the operation
> in.  All the other uses of assignability have only one "target" type to
> assign to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/92f2fcce/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 02:18:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:18:26 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>


>> One thing I've really struggled with over the introduction of LONGINT is
>> the need for distinct literal forms. This strikes me as odd, since
>> literals are really just ways of writing values, rather than stating
>> anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct,
>> but they really do have incompatible value representations).
>
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.

 
Huh? This seems to me to be directly opposite of the truth.
LONGREAL is a strict superset of REAL in what it can represent.
There is *complete* overlap.
Am I really mistaken here?
Floating point is indeed very wierd, but it isn't this wierd.
Right?
 
 
 - Jay




---------------------------------------- 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 02:21:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:21:34 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>


> rather than having things
> happen behind the scenes, without the programmer's coding them
 
 
Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.
  It is two or three function calls.
Look at the garbage collector. 
Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
 I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.
 
 
Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
 
 
It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.
 
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 03:11:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:11:23 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <4405421D-C606-4DC4-B6D4-4C50DA03992B@cs.purdue.edu>

Yes, I agree.  I am now convinced that relaxing the current spec to allow assignability and mixed operand arithmetic is a swamp that we should steer well clear of.

On 11 Jan 2010, at 19:45, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.
> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> Here's how things would work with subrange types.
>> A subrange written as currently
>> [lo .. hi]
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> A subrange with base type LONGINT would be written explicitly:
>> [lo .. hi] OF LONGINT
>> The constants lo/hi must both be in range for LONGINT.
>> We could also support the form:
>> [lo .. hi] OF INTEGER
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> This would eliminate _one_ reason for needing distinct integer literals.
> 
>> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> The reason I proposed the distinct literals is because of feeling very
> badly burned by Ada.  It has a type "universal integer", which is builtin,
> and all integer literals have this type.  They have unbounded range and
> a complete set of arithmetic operators, which can only be evaluated at
> compile time.  The type "universal integer" can't be named in source
> code.
> 
> The rules for when they are converted to a type having a runtime representation
> are complicated, messy, highly surprising, and a huge complication of the
> language.  Static type information can propagate a long way through
> language constructs.  The programmer's dilemma in figuring out just what
> is happening is much worse than arithmetic operators that accept mixed
> sizes and do the computation in the larger size.
> 
> Maybe the semantics of this idea could be done better than in Ada, but I spent
> a lot of time trying, and didn't come up with anything that wasn't both too
> complicated and not worth the gain, IMO.
> 
> We should come up with a complete language proposal before going this way.
> 
> 
> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33599c21/attachment.html>

From hosking at cs.purdue.edu  Tue Jan 12 03:09:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:09:39 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <4B4BC181.8020807@lcwb.coop>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
	<4B4BC181.8020807@lcwb.coop>
Message-ID: <8432422C-A96C-4A0A-A8F9-9EC10963548A@cs.purdue.edu>

If the type were INTEGER instead of CARDINAL then the current implementation *does* allow wrap-around.  I've fixed the range check so that overflow does not permit the bits for FIRST(INTEGER) to be stored in the CARDINAL.

On 11 Jan 2010, at 19:25, Rodney M. Bates wrote:

> If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
> I think wrapping around to the maximal negative value would be reasonable.  Even for
> CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
> done in the full INTEGER range).  But then the assignment of the result back to the
> CARDINAL variable really must do a range check.  This derives from the assignment
> x:= ... in the WITH equivalent, not from the + 1 operation.
> 
> Mainly, there is a pervasive principle in the safety of the language that you can
> never get a bit pattern stored in a variable that does not map back to an abstract
> value of its type.  We really need to preserve this.
> 
> Tony Hosking wrote:
>> Even under the interpretation for INC that yields:
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
>> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
>> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
>> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
>>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>> 
>>> VAR s: CARDINAL := LAST(INTEGER);
>>> BEGIN INC(s) END;
>>> 
>>> Should this fail at runtime with a range check error?
>>> 
>>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>> 
>>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>> 
>>> 
>>> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33f19a51/attachment.html>

From hosking at cs.purdue.edu  Tue Jan 12 03:18:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:18:00 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>

On 11 Jan 2010, at 20:21, Jay K wrote:

> 
>> rather than having things
>> happen behind the scenes, without the programmer's coding them
> 
> 
> Just a reminder that things happen behind the scenes *all the time*.
> It is the norm, not the exception.
> Look at what "try" does.
>  It is two or three function calls.

Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.

> Look at the garbage collector. 

Again, that is not visible to the programmer.  Same again re programmer reasoning.

> Look at layering in various places.
> The system is not simple.
> This isn't a bad thing necessarily.
> Getting things done often requires complexity.
> I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.

His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.

> Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
> 
> 
> It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.

What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?

Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.

I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.

I strongly support the status quo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/02734d2d/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 04:02:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:02:55 +0000
Subject: [M3devel] 64bit file sizes now?
Message-ID: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expr).

 

 

And this is already in place.

 

 

?

 

 

So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.

Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

 

 

I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.

Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/6b8770ea/attachment.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:10:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:10:06 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>

On 11 Jan 2010, at 22:02, Jay K wrote:

> So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).

That's what I think makes most sense.

>  And this is already in place.

Yes, it's in place.

> ?
>  
> So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
> Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?

>  I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
> Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

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

From jay.krell at cornell.edu  Tue Jan 12 04:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:10:52 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
References: <4B4BBFE6.1090701@lcwb.coop>,
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>,
	<69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
Message-ID: <COL101-W65EDF1A26440E2A141F67FE66C0@phx.gbl>


The limited range of efficient integers will always be a problem.

 

 

After all, in the real world, there is no such thing as LAST(INTEGER), nor the notion that + can fail, but even in Modula-3 we have both of these unfortunate things for efficiency.

 

 

It is a wierd system already.

 

 

Having LAST(INTEGER) + 1 fail or be FIRST(INTEGER) but LAST(INTEGER) + 1L provide a more sensible result I'm skeptical makes it any worse or wierder than it already is.

 

 

On the other hand, rd/wr/file ugliness is also fairly unavoidable, and just would have been there from the start had things been done right.

 

 

It is the unavoidable case that "large" files, even if they do fit in address space, are hard to deal with efficiently. Programmers are very used to efficient random access and often don't design for sequential access. And heck, with the rise of SSDs replacing spinning magnetic disks, it isn't going to matter any longer anyway.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 21:18:00 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Mixed arithmetic




On 11 Jan 2010, at 20:21, Jay K wrote:




rather than having things

happen behind the scenes, without the programmer's coding them


Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.

 It is two or three function calls.



Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.


Look at the garbage collector. 



Again, that is not visible to the programmer.  Same again re programmer reasoning.


Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.



His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.


Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.




It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.


What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?


Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.


I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.


I strongly support the status quo.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/50f52f29/attachment.html>

From rcolebur at SCIRES.COM  Tue Jan 12 04:11:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 22:11:51 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>

Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)
then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).  Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);
but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

So, at this point, to summarize, I think you are advocating:

1.      Distinct types INTEGER and LONGINT.

2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.

3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).

4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.

5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.

6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Now, what to do about converting from LONGINT to INTEGER?

a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

e.      Any other ideas?

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:


Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.



2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.


 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.


 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.


 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.


 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.


 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.


 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.


 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...


 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:



I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/77faa179/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 04:16:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:16:42 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
Message-ID: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>


Large files (64bit file sizes) are very old.

Windows 95 had them in the released API 14+ years ago (1995), NT a few years before that (1993?), betas earlier. I heard VMS had 64bit file sizes but I haven't confirmed.

 

 > If the use-case is typically INTEGER then perhaps we
 > need to think of alternatives using abstraction?
 

Hm. StatusLong, SeekLong, IndexLong, LengthLong?

Default calls Seek/Index/Length, range checked truncation?

Kind of an annoying duplicity of APIs though.

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 22:10:06 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] 64bit file sizes now?




On 11 Jan 2010, at 22:02, Jay K wrote:


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).



That's what I think makes most sense.


 And this is already in place.



Yes, it's in place.



?
 
So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.



If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?


 I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/35d6807e/attachment.html>

From dabenavidesd at yahoo.es  Tue Jan 12 04:27:23 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 12 Jan 2010 03:27:23 +0000 (GMT)
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <420956.32527.qm@web23605.mail.ird.yahoo.com>

Hi all:
forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
(LAST(INTEGER) + 1) = FIRST (INTEGER)
This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
Please let me know if I'm wrong about this issue on current discussions. 

--- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] 64bit file sizes now?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 11 de enero, 2010 22:02
> 
> 
> 
> 
>  
> So.. LONGINT as I understand will remain roughly as it was,
> except VAL(expr, INTEGER) is how you convert expr to
> INTEGER, instead of ORD(expr).
> 
>  
> 
>  
> 
> And this is already in place.
> 
>  
> 
>  
> 
> ?
> 
>  
> 
>  
> 
> So I should go ahead and update File.i3/Status/size and
> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> the consequences"? The consequences are roughly the
> first diff I sent out, with the caveats that I used ORD()
> instead of VAL(,INTEGER), and a few packages were left to
> fix. It is mechanical and simple and predictable, just
> tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes"
> anyway, but a few might gain capacity.
> 
> Classic simple example is the mklib and libdump code, they
> read the entire file into memory and then deal with that.
> 
>  
> 
>  
> 
> I can send the diffs ahead of time, but there's really
> no choices left as to what they'll look like, it is
> forced by the limited capability of LONGINT.
> 
> Had they used LONGINT in the first place, of course,
> there'd be no diff at this time, the ugliness would have
> been builtin from the start.
> 
>  
> 
>  
> 
>  - Jay
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Tue Jan 12 04:40:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:40:28 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:

> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.

>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.

>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)

No, enumerations map only onto INTEGER.

> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.

>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.

>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)

> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 

This captures the identities precisely, which is why I reverted to the original formulation.

> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.

>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);

That is what is now implemented.

> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.

>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.

>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.

>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.

> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!

> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

> e.      Any other ideas?

I think we are done...

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  

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

From hosking at cs.purdue.edu  Tue Jan 12 04:50:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:50:05 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <0EB89E7A-0804-4D07-9F80-CB1F5A343471@cs.purdue.edu>

Overflow checking is a whole other ball of wax... ;-)
The language reference provides for controlling the behavior of integer operations regarding overflow and divide by zero through the interface FloatMode.i3.  Unfortunately, the implementation of this interface on many targets is incomplete and the default behaviour is to allow integer operations to silently overflow.
Range checks are still injected by the compiler to ensure that no variable has a bit representation that is not a legal value for that variable.  Thus, for example:

VAR x: INTEGER := LAST(INTEGER)+1

will leave x with the value -1.

But,

VAR x: CARDINAL := LAST(INTEGER)+1

will cause a range fault because the overflowed result is not a legal CARDINAL.

It would be great if someone could devote some time to implementing this interface for x86 or x86_64 as they are the most widely used these days.  Of course, each OS target will probably need a different implementation.

On 11 Jan 2010, at 22:27, Daniel Alejandro Benavides D. wrote:

> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: [M3devel] 64bit file sizes now?
>> Para: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 11 de enero, 2010 22:02
>> 
>> 
>> 
>> 
>> 
>> So.. LONGINT as I understand will remain roughly as it was,
>> except VAL(expr, INTEGER) is how you convert expr to
>> INTEGER, instead of ORD(expr).
>> 
>> 
>> 
>> 
>> 
>> And this is already in place.
>> 
>> 
>> 
>> 
>> 
>> ?
>> 
>> 
>> 
>> 
>> 
>> So I should go ahead and update File.i3/Status/size and
>> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
>> the consequences"? The consequences are roughly the
>> first diff I sent out, with the caveats that I used ORD()
>> instead of VAL(,INTEGER), and a few packages were left to
>> fix. It is mechanical and simple and predictable, just
>> tedious and ugly.
>> Most Rd/Wr users are limited to INTEGER "sizes"
>> anyway, but a few might gain capacity.
>> 
>> Classic simple example is the mklib and libdump code, they
>> read the entire file into memory and then deal with that.
>> 
>> 
>> 
>> 
>> 
>> I can send the diffs ahead of time, but there's really
>> no choices left as to what they'll look like, it is
>> forced by the limited capability of LONGINT.
>> 
>> Had they used LONGINT in the first place, of course,
>> there'd be no diff at this time, the ugliness would have
>> been builtin from the start.
>> 
>> 
>> 
>> 
>> 
>> - Jay
>> 
>> 		 	   		  
>> 
> 
> 
> 



From jay.krell at cornell.edu  Tue Jan 12 04:46:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:46:13 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>


True that:

 

> (LAST(INTEGER) + 1) = FIRST (INTEGER)


 

many folks would like to see fail before it gets to the "=".

 

The dilemna remains though because:

 

> (LAST(INTEGER) + 1L) = FIRST (INTEGER)


 

would not fail.


So, you can either look at it as they produce different values, or one succeeds and one fails.

Either way people don't like two different expressions doing two different things.

Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.

 

There something here about "transitivity" or "replacement":

 

j2 := VAL(i1, LONGINT) + j3;

vs.

j2 := i1 + j3;

 

pretty clearly have the same meaning.

The conversion is always trivial and always succeeds.

Does anyone really find it ambiguous?

 

 - Jay

 
> Date: Tue, 12 Jan 2010 03:27:23 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] 64bit file sizes now?
> 
> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: [M3devel] 64bit file sizes now?
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: lunes, 11 de enero, 2010 22:02
> > 
> > 
> > 
> > 
> > 
> > So.. LONGINT as I understand will remain roughly as it was,
> > except VAL(expr, INTEGER) is how you convert expr to
> > INTEGER, instead of ORD(expr).
> > 
> > 
> > 
> > 
> > 
> > And this is already in place.
> > 
> > 
> > 
> > 
> > 
> > ?
> > 
> > 
> > 
> > 
> > 
> > So I should go ahead and update File.i3/Status/size and
> > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > the consequences"? The consequences are roughly the
> > first diff I sent out, with the caveats that I used ORD()
> > instead of VAL(,INTEGER), and a few packages were left to
> > fix. It is mechanical and simple and predictable, just
> > tedious and ugly.
> > Most Rd/Wr users are limited to INTEGER "sizes"
> > anyway, but a few might gain capacity.
> > 
> > Classic simple example is the mklib and libdump code, they
> > read the entire file into memory and then deal with that.
> > 
> > 
> > 
> > 
> > 
> > I can send the diffs ahead of time, but there's really
> > no choices left as to what they'll look like, it is
> > forced by the limited capability of LONGINT.
> > 
> > Had they used LONGINT in the first place, of course,
> > there'd be no diff at this time, the ugliness would have
> > been builtin from the start.
> > 
> > 
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/f3bf331f/attachment.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:57:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:57:38 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
Message-ID: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>

On 11 Jan 2010, at 22:46, Jay K wrote:

> True that:
>  
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> 
>  
> many folks would like to see fail before it gets to the "=".

WIthout overflow checking the addition will not fail.

>  
> The dilemna remains though because:
>  
> > (LAST(INTEGER) + 1L) = FIRST (INTEGER)

Actually, you mean VAL(LAST(INTEGER), LONGINT) + 1L

> would not fail.
> 
> So, you can either look at it as they produce different values, or one succeeds and one fails.

The point is that the type explicitly tells you whether you might be in trouble with overflow.

> Either way people don't like two different expressions doing two different things.
> Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.
>  
> There something here about "transitivity" or "replacement":
>  
> j2 := VAL(i1, LONGINT) + j3;
> vs.
> j2 := i1 + j3;

It is not referentially transparent.  It requires innate knowledge about promotion rules to understand.  That's what "not referentially transparent" means!

>  
> pretty clearly have the same meaning.
> The conversion is always trivial and always succeeds.
> Does anyone really find it ambiguous?
>  
>  - Jay
> 
>  
> > Date: Tue, 12 Jan 2010 03:27:23 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com; jay.krell at cornell.edu
> > Subject: Re: [M3devel] 64bit file sizes now?
> > 
> > Hi all:
> > forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> > This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> > Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> > Please let me know if I'm wrong about this issue on current discussions. 
> > 
> > --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> > 
> > > De: Jay K <jay.krell at cornell.edu>
> > > Asunto: [M3devel] 64bit file sizes now?
> > > Para: "m3devel" <m3devel at elegosoft.com>
> > > Fecha: lunes, 11 de enero, 2010 22:02
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So.. LONGINT as I understand will remain roughly as it was,
> > > except VAL(expr, INTEGER) is how you convert expr to
> > > INTEGER, instead of ORD(expr).
> > > 
> > > 
> > > 
> > > 
> > > 
> > > And this is already in place.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So I should go ahead and update File.i3/Status/size and
> > > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > > the consequences"? The consequences are roughly the
> > > first diff I sent out, with the caveats that I used ORD()
> > > instead of VAL(,INTEGER), and a few packages were left to
> > > fix. It is mechanical and simple and predictable, just
> > > tedious and ugly.
> > > Most Rd/Wr users are limited to INTEGER "sizes"
> > > anyway, but a few might gain capacity.
> > > 
> > > Classic simple example is the mklib and libdump code, they
> > > read the entire file into memory and then deal with that.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > I can send the diffs ahead of time, but there's really
> > > no choices left as to what they'll look like, it is
> > > forced by the limited capability of LONGINT.
> > > 
> > > Had they used LONGINT in the first place, of course,
> > > there'd be no diff at this time, the ugliness would have
> > > been builtin from the start.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > 
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/59d798f0/attachment.html>

From rcolebur at SCIRES.COM  Tue Jan 12 05:09:46 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:09:46 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

I'm sorry, I missed the fact that you changed the type to "Integer" vs. "INTEGER" and defined "Integer" to be "INTEGER" or "LONGINT".

I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be "happy" with this state of affairs.

I am confused though by your last set of statements, namely:

>I don't think we need to do this, assuming you understand what I have said above.
>
>ORD(x: INTEGER): LONGINT
>ORD(x: LONGINT): INTEGER
>ORD(x: Enumeration): INTEGER
>ORD(x: Subrange): Base(Subrange)
>
>ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

Didn't you mean:
                ORD(x:INTEGER): INTEGER
                ORD(x:LONGINT): LONGINT

Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
"m3-libs\m3core"
"m3-libs\libm3"
"m3-tools\m3tk"
So some recent changes have caused a problem.

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 10:40 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:


Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.


 I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.


 Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

No, enumerations map only onto INTEGER.


Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.


 The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.


 So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)


then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).

This captures the identities precisely, which is why I reverted to the original formulation.


Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.


 I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);

That is what is now implemented.


but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.


 I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.


 So, at this point, to summarize, I think you are advocating:
1.      Distinct types INTEGER and LONGINT.
2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.


 Now, what to do about converting from LONGINT to INTEGER?
a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.


b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!


d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

e.      Any other ideas?

I think we are done...



Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:



Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.




2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.



 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.



 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.



 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.



 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.



 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.



 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.



 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...



 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:




I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn



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

From jdp at polstra.com  Tue Jan 12 05:43:50 2010
From: jdp at polstra.com (John Polstra)
Date: Mon, 11 Jan 2010 20:43:50 -0800
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <4B4BFE06.5010400@polstra.com>

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From jay.krell at cornell.edu  Tue Jan 12 05:55:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 04:55:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
Message-ID: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>


I thought FloatMode was only related to floating point.

So I looked:

 

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

 

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


 

This part of it should be easy to implement for all architectures.

The entire thing probably isn't too difficult either on many platforms either.

 

However...I was surprised by this.

I thought the real "intent" in Modula-3 to not have this be configurable

and endeavor for overflow and divide by zero to always immediately

raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

 

For the floating point stuff:

 

Probably like other per-platform code, this should be done in #ifdefed C.

 

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx

http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html

etc.

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/32017d54/attachment.html>

From rcolebur at SCIRES.COM  Tue Jan 12 05:59:01 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:59:01 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <4B4BFE06.5010400@polstra.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>

I also took the liberty of contacting him.  Shown below is my message and his response:
Regards,
Randy

On Mon, 11 Jan 2010 12:19:26 -0500
Randy Coleburn <rcolebur at SCIRES.COM> wrote:

> Just want to let you know that the folks hosting the mail list service are trying to fulfill your request to be added to the m3devel mail list.
> 
> The problem seems to be blacklisting of one of the hosts.  At first it seemed your email address was blacklisted, but upon further investigation it seems your email server (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has blacklisted the mail list server at elegosoft.  Note that the elegosoft server is based in Germany.
> 
> The server admins are working on the problem, but not sure if/when it will be resolved.
> 
> I'm one of the developers and also subscribe to the list and noticed the traffic about your request, so thought I would try and send you an email to see if it gets thru and to let you know of the problem.
> 
> Regards,
> Randy
> 

Thanks for the heads up. I'll give them a call to see what the problem is.

AT&T actually does it's mail hosting through Yahoo mail, so they might actually be the ones doing the blacklisting. I'm going to do some poking around on this end; and I'll send you an email if I find anything noteworthy.

Thank you.

-- 
Chris <dimonax at att.net>


-----Original Message-----
From: John Polstra [mailto:jdp at polstra.com] 
Sent: Monday, January 11, 2010 11:44 PM
To: Tony Hosking
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] Fwd: CM3 development Inquiry.

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From rcolebur at SCIRES.COM  Tue Jan 12 06:18:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>

Jay,

I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.

This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.

Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.

I agree that lumping the integer overflow control into an interface named "FloatMode" makes it a bit hard to find since "FloatMode" would make one think that the interface deals only with floating point.

So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won't care and his code will eventually break.  See the comments about long-lived readers/writers for an example.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode

I thought FloatMode was only related to floating point.
So I looked:

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.

However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

For the floating point stuff:

Probably like other per-platform code, this should be done in #ifdefed C.

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/ba0a561e/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 06:32:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 05:32:35 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W55FC6ED07465737B2146C4E66C0@phx.gbl>


Rewrite code to avoid overflow?

 That seems..difficult.

 Write it in a typical normal straightfoward

   fashion and rely on overflow checking to avoid bugs, imho.

 

I think relying on silent wrap is bad but relying on overflow

checks is appropriate.

 

Really what I think is you need multiple types or interfaces.

So that you can request silent wraparound for certain code

and overflow checking for other code. It's not a per-thread

setting, but a type thing.

It is more "statically bound" than a runtime per thread setting.

 

In the absence of this profusion of

types though, a good safe compromise is the INTEGER/Word

split. INTEGER is signed and should check overflow.

 

Word is unsigned and silently wraps.

 

Really this isn't everything. You also want unsigned

with overflow checks, maybe signed with silent wraparound.

Maybe the arithmetic library provides all this.

I need to check.

 

 

Testing your code one way and shipping it another way

is a bad recipe. The checks need to be preserved

in the shipping version because testing is never complete.

Also because the checks might have unintended side effects.

Ship what you test.

 

 

Again though, isn't silent wraparound a safety hole?

Or maybe not, maybe given that we have array bounds checking,

maybe safety is preserved?

(You know, what would happen incorrectly when positive + positive

yields negative?)

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: Re: [M3devel] FloatMode





Jay, 
 
I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.
 
This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.
 
Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.
 
I agree that lumping the integer overflow control into an interface named ?FloatMode? makes it a bit hard to find since ?FloatMode? would make one think that the interface deals only with floating point.
 
So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won?t care and his code will eventually break.  See the comments about long-lived readers/writers for an example.
 
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode
 
I thought FloatMode was only related to floating point.
So I looked:
 
   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.
 
   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}

 
This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.
 
However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
 
For the floating point stuff:
 
Probably like other per-platform code, this should be done in #ifdefed C.
 
http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/57b85e47/attachment.html>

From mika at async.async.caltech.edu  Tue Jan 12 06:46:03 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:46:03 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>
Message-ID: <20100112054603.A07EA1A2078@async.async.caltech.edu>

Jay K writes:
>
>>> One thing I've really struggled with over the introduction of LONGINT is
>>> the need for distinct literal forms. This strikes me as odd=2C since
>>> literals are really just ways of writing values=2C rather than stating
>>> anything about how they should be represented.
>>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
>=2C
>>> but they really do have incompatible value representations).
>>
>> I agree=2C the need for distinctly typed literals is much greater for the
>> floating types than the integer types=2C because they can't be viewed
>> as having overlapping value sets in any reasonable way.
>
>=20
>Huh? This seems to me to be directly opposite of the truth.
>LONGREAL is a strict superset of REAL in what it can represent.
>There is *complete* overlap.
>Am I really mistaken here?
>Floating point is indeed very wierd=2C but it isn't this wierd.
>Right?
>=20
>=20
> - Jay

Jay, I think if you have hardware that's strictly compliant with IEEE
754, you're right.  Or at least there exists an interpretation of the
values that have this property.  I alluded earlier to the fact that
Alpha represents single-precision by zeroing out the middle of the
double-precision register (some of the mantissa and some of the exponent).

However I'm sure there are systems for which this is not true.  Is 
Modula-3 forbidden from being ported to such machines?

    Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:47:25 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:47:25 -0800
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl> 
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <20100112054725.2C8ED1A207C@async.async.caltech.edu>

Jay K writes:
>
>> rather than having things
>> happen behind the scenes=2C without the programmer's coding them
>=20
>=20
>Just a reminder that things happen behind the scenes *all the time*.
>It is the norm=2C not the exception.
>Look at what "try" does.
>  It is two or three function calls.
>Look at the garbage collector.=20
>Look at layering in various places.

These things are not visible to the programmer.

     Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:53:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:53:49 -0800
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
	<COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>
Message-ID: <20100112055349.CBEFE1A2080@async.async.caltech.edu>


Why not change the implementation to something using LONGINT (or
BigInteger.T...)  and then provide the old ones as a thin veneer over
the new implementation, marking the old ones as <*OBSOLETE*>...

    Mika


Jay K writes:
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Large files (64bit file sizes) are very old.
>
>Windows 95 had them in the released API 14+ years ago (1995)=2C NT a few ye=
>ars before that (1993?)=2C betas earlier. I heard VMS had 64bit file sizes =
>but I haven't confirmed.
>
>=20
>
> > If the use-case is typically INTEGER then perhaps we
> > need to think of alternatives using abstraction?
>=20
>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?
>
>Default calls Seek/Index/Length=2C range checked truncation?
>
>Kind of an annoying duplicity of APIs though.
>
>=20
>
> - Jay
>=20
>
>
>From: hosking at cs.purdue.edu
>Date: Mon=2C 11 Jan 2010 22:10:06 -0500
>To: jay.krell at cornell.edu
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] 64bit file sizes now?
>
>
>
>
>On 11 Jan 2010=2C at 22:02=2C Jay K wrote:
>
>
>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(ex=
>pr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire)=
>.
>
>
>
>That's what I think makes most sense.
>
>
> And this is already in place.
>
>
>
>Yes=2C it's in place.
>
>
>
>?
>=20
>So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Le=
>ngth to all be LONGINT=2C "whatever the consequences"? The consequences are=
> roughly the first diff I sent out=2C with the caveats that I used ORD() in=
>stead of VAL(=2CINTEGER)=2C and a few packages were left to fix. It is mech=
>anical and simple and predictable=2C just tedious and ugly.
>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few might g=
>ain capacity.
>Classic simple example is the mklib and libdump code=2C they read the entir=
>e file into memory and then deal with that.
>
>
>
>If the use-case is typically INTEGER then perhaps we need to think of alter=
>natives using abstraction?
>
>
> I can send the diffs ahead of time=2C but there's really no choices left a=
>s to what they'll look like=2C it is forced by the limited capability of LO=
>NGINT.
>Had they used LONGINT in the first place=2C of course=2C there'd be no diff=
> at this time=2C the ugliness would have been builtin from the start.
>
>When they originally wrote it large file sizes were only proposed not imple=
>mented.  I don't think C even had long long then.  (Yes=2C I am showing my =
>age! -- we are talking almost 20 years ago now!)  If they had used LONGINT =
>from the start then folks would have not had any ugliness because all would=
> have used LONGINT.    Now=2C to save some hassles in future=2C perhaps we =
>need a better abstraction!  Let's ponder that before you propagate your cha=
>nges.
>
> 		 	   		  =
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Large files (64bit file sizes) are very old.<BR>
>Windows 95 had them in the released&nbsp=3BAPI 14+ years ago (1995)=2C NT a=
> few years before that (1993?)=2C betas earlier. I heard VMS had 64bit file=
> sizes but I haven't confirmed.<BR>
>&nbsp=3B<BR>
><DIV>&nbsp=3B&gt=3B If the use-case is typically INTEGER then perhaps we</D=
>IV>
><DIV>&nbsp=3B&gt=3B need to think of alternatives using abstraction?</DIV>
>&nbsp=3B<BR>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?<BR>
>Default calls Seek/Index/Length=2C range checked truncation?<BR>
>Kind of an annoying duplicity of APIs though.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>
><HR id=3DstopSpelling>
>From: hosking at cs.purdue.edu<BR>Date: Mon=2C 11 Jan 2010 22:10:06 -0500<BR>T=
>o: jay.krell at cornell.edu<BR>CC: m3devel at elegosoft.com<BR>Subject: Re: [M3de=
>vel] 64bit file sizes now?<BR><BR><BASE>
><DIV><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLL=
>APSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPA=
>CING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxAppl=
>e-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BOR=
>DER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LE=
>TTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=
>=3DecxApple-style-span>
><DIV style=3D"WORD-WRAP: break-word"><SPAN style=3D"TEXT-TRANSFORM: none=3B=
> TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B W=
>HITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WO=
>RD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TRANSFORM:=
> none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvet=
>ica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C=
>0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TR=
>ANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12p=
>x Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(=
>0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D=
>"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B F=
>ONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COL=
>OR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN =
>style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separ=
>ate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: norma=
>l=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-spa=
>n><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPS=
>E: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACIN=
>G: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-s=
>tyle-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER=
>-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTE=
>R-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3Dec=
>xApple-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=
>=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: norma=
>l=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" =
>class=3DecxApple-style-span>
><DIV><SPAN style=3D"FONT-SIZE: medium" class=3DecxApple-style-span>On 11 Ja=
>n 2010=2C at 22:02=2C Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN>=
></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
><DIV><BR class=3DecxApple-interchange-newline>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(e=
>xpr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire=
>).<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>That's what I think makes most sense.</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BAnd this is already in place.<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>Yes=2C it's in place.</DIV>
><DIV><BR></DIV>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>?<BR>&nbsp=3B<BR>So I should go ahead and update File.i3/Status/size and R=
>d/Wr/Index/Seek/Length to all be LONGINT=2C "whatever the consequences"? Th=
>e consequences are roughly the first diff I sent out=2C with the caveats th=
>at I used ORD() instead of VAL(=2CINTEGER)=2C and a few packages were left =
>to fix. It is mechanical and simple and predictable=2C just tedious and ugl=
>y.<BR>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few m=
>ight gain capacity.<BR>Classic simple example is the mklib and libdump code=
>=2C they read the entire file into memory and then deal with that.<BR></DIV=
>></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>If the use-case is typically INTEGER then perhaps we need to think of =
>alternatives using abstraction?</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BI can send the diffs ahead of time=2C but there's really no choice=
>s left as to what they'll look like=2C it is forced by the limited capabili=
>ty of LONGINT.<BR>Had they used LONGINT in the first place=2C of course=2C =
>there'd be no diff at this time=2C the ugliness would have been builtin fro=
>m the start.</DIV></SPAN></BLOCKQUOTE><BR></DIV>
><DIV>When they originally wrote it large file sizes were only proposed not =
>implemented. &nbsp=3BI don't think C even had <FONT class=3DecxApple-style-=
>span face=3DCourier>long long</FONT>&nbsp=3Bthen. &nbsp=3B(Yes=2C I am show=
>ing my age! -- we are talking almost 20 years ago now!) &nbsp=3BIf they had=
> used LONGINT from the start then folks would have not had any ugliness bec=
>ause all would have used LONGINT. &nbsp=3B &nbsp=3BNow=2C to save some hass=
>les in future=2C perhaps we need a better abstraction! &nbsp=3BLet's ponder=
> that before you propagate your changes.</DIV>
><DIV><BR></DIV> 		 	   		  </body>
></html>=
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_--


From jay.krell at cornell.edu  Tue Jan 12 07:19:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:19:45 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>


When do you forsee any non-IEEE 754 floating point environments coming into existance?

 

Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?

For that matter, probably Perl and Python, but I'd have to check.

Chances are high they only expose 64bit float and nothing else.

 

 

The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?

 

 

I know, I know "never say never", but sometimes....?

 

 

Certainly there are also 80bit formats on x86 and 68K.

 Though x86 is moving away from this with SSE/SSE2.

And I think 128bit formats on PowerPC.

And something beyond 64bits on IA64 (Itanium).

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/a8d6a0f6/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 07:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:21:43 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W608B0F5C8B52AB95E8D61E66C0@phx.gbl>


And even these 80 bit and 128 bit formats I'm sure can represent all values losslessly of the smaller types. I have to look into this stuff though.

 

 - Jay

 


From: jay.krell at cornell.edu
To: mika at async.async.caltech.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Integer literals
Date: Tue, 12 Jan 2010 06:19:45 +0000



When do you forsee any non-IEEE 754 floating point environments coming into existance?
 
Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?
For that matter, probably Perl and Python, but I'd have to check.
Chances are high they only expose 64bit float and nothing else.
 
 
The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?
 
 
I know, I know "never say never", but sometimes....?
 
 
Certainly there are also 80bit formats on x86 and 68K.
 Though x86 is moving away from this with SSE/SSE2.
And I think 128bit formats on PowerPC.
And something beyond 64bits on IA64 (Itanium).
 
 
 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/656c93c9/attachment.html>

From mika at async.async.caltech.edu  Tue Jan 12 07:42:43 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 22:42:43 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
Message-ID: <20100112064243.6828D1A2078@async.async.caltech.edu>

Jay K writes:
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?

x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
done in extended and then truncated by a store/load pair, if I remember
correctly).  That's not a non-IEEE format.  And I find it puzzling that
we don't expose the x87 native format in Modula-3 as EXTENDED.

One common completely non-IEEE format is Cray floating point.

In any case writing IEEE floating point into the specification of a
systems language like Modula-3 seems completely wrong to me.
Who knows what tomorrow will bring?

    Mika

>
>=20
>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>ature of all CPUs=2C at least ones that have any floating point support? Or=
> any software floating point library?
>
>For that matter=2C probably Perl and Python=2C but I'd have to check.
>
>Chances are high they only expose 64bit float and nothing else.
>
>=20
>
>=20
>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?
>
>=20
>
>=20
>
>I know=2C I know "never say never"=2C but sometimes....?
>
>=20
>
>=20
>
>Certainly there are also 80bit formats on x86 and 68K.
>
> Though x86 is moving away from this with SSE/SSE2.
>
>And I think 128bit formats on PowerPC.
>
>And something beyond 64bits on IA64 (Itanium).
>
>=20
>
>=20
>
> - Jay
>=20
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Integer literals=20
>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>> From: mika at async.async.caltech.edu
>>=20
>> Jay K writes:
>> >
>> >>> One thing I've really struggled with over the introduction of LONGINT=
> is
>> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>e
>> >>> literals are really just ways of writing values=3D2C rather than stat=
>ing
>> >>> anything about how they should be represented.
>> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>tinct=3D
>> >=3D2C
>> >>> but they really do have incompatible value representations).
>> >>
>> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
>r the
>> >> floating types than the integer types=3D2C because they can't be viewe=
>d
>> >> as having overlapping value sets in any reasonable way.
>> >
>> >=3D20
>> >Huh? This seems to me to be directly opposite of the truth.
>> >LONGREAL is a strict superset of REAL in what it can represent.
>> >There is *complete* overlap.
>> >Am I really mistaken here?
>> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
>> >Right?
>> >=3D20
>> >=3D20
>> > - Jay
>>=20
>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>> 754=2C you're right. Or at least there exists an interpretation of the
>> values that have this property. I alluded earlier to the fact that
>> Alpha represents single-precision by zeroing out the middle of the
>> double-precision register (some of the mantissa and some of the exponent)=
>.
>>=20
>> However I'm sure there are systems for which this is not true. Is=20
>> Modula-3 forbidden from being ported to such machines?
>>=20
>> Mika
> 		 	   		  =
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?<BR>
>&nbsp=3B<BR>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>ng a feature of all CPUs=2C at least ones that have any floating point supp=
>ort? Or any software floating point library?<BR>
>For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>Chances are high they only expose 64bit float and nothing else.<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>I know=2C I know "never say never"=2C but sometimes....?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>Certainly there are also 80bit formats on x86 and 68K.<BR>
>&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>And I think 128bit formats on PowerPC.<BR>
>And something beyond 64bits on IA64 (Itanium).<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>=3B literals are really just ways of writing values=3D2C rather than statin=
>g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>  		  </body>
></html>=
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--


From jay.krell at cornell.edu  Tue Jan 12 07:55:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:55:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>, ,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>,
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>,
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>


IEEE-754 is extremely long standing.

 

But it isn't the issue anyway.

 

The issue is if there exist good candiates for REAL and LONGREAL

such that LONGREAL can losslessly represent all values of REAL.

 

C systems are gradually supporting 3 or more floating point formats.

PowerPC has an optional 128 bit long double.

http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html

 

I wonder if ultimately we should provide "pieces" for people

to define their own types:

 

TYPE Int1 = BITS 32, unsigned, integer, trap overflow;

TYPE Int2 = BITS 64, signed, integer, silent overflow;

TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;

TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;

 

and then provide just a few "canned" "popular" types so that

a lot of code can interoperate with a lot of code, but if a programmer

really needs something else, he has a chance of defining it.

 

Or maybe we can only define what is efficient in hardware, but still

do so with a syntax like this??

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> Date: Mon, 11 Jan 2010 22:42:43 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> Jay K writes:
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?
> 
> x86 (well, x87) is actually very much IEEE 754. It's almost the reference
> implementation. Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly). That's not a non-IEEE format. And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.
> 
> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?
> 
> Mika
> 
> >
> >=20
> >
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
> >ature of all CPUs=2C at least ones that have any floating point support? Or=
> > any software floating point library?
> >
> >For that matter=2C probably Perl and Python=2C but I'd have to check.
> >
> >Chances are high they only expose 64bit float and nothing else.
> >
> >=20
> >
> >=20
> >
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?
> >
> >=20
> >
> >=20
> >
> >I know=2C I know "never say never"=2C but sometimes....?
> >
> >=20
> >
> >=20
> >
> >Certainly there are also 80bit formats on x86 and 68K.
> >
> > Though x86 is moving away from this with SSE/SSE2.
> >
> >And I think 128bit formats on PowerPC.
> >
> >And something beyond 64bits on IA64 (Itanium).
> >
> >=20
> >
> >=20
> >
> > - Jay
> >=20
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Integer literals=20
> >> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
> >> From: mika at async.async.caltech.edu
> >>=20
> >> Jay K writes:
> >> >
> >> >>> One thing I've really struggled with over the introduction of LONGINT=
> > is
> >> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
> >e
> >> >>> literals are really just ways of writing values=3D2C rather than stat=
> >ing
> >> >>> anything about how they should be represented.
> >> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
> >tinct=3D
> >> >=3D2C
> >> >>> but they really do have incompatible value representations).
> >> >>
> >> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
> >r the
> >> >> floating types than the integer types=3D2C because they can't be viewe=
> >d
> >> >> as having overlapping value sets in any reasonable way.
> >> >
> >> >=3D20
> >> >Huh? This seems to me to be directly opposite of the truth.
> >> >LONGREAL is a strict superset of REAL in what it can represent.
> >> >There is *complete* overlap.
> >> >Am I really mistaken here?
> >> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
> >> >Right?
> >> >=3D20
> >> >=3D20
> >> > - Jay
> >>=20
> >> Jay=2C I think if you have hardware that's strictly compliant with IEEE
> >> 754=2C you're right. Or at least there exists an interpretation of the
> >> values that have this property. I alluded earlier to the fact that
> >> Alpha represents single-precision by zeroing out the middle of the
> >> double-precision register (some of the mantissa and some of the exponent)=
> >.
> >>=20
> >> However I'm sure there are systems for which this is not true. Is=20
> >> Modula-3 forbidden from being ported to such machines?
> >>=20
> >> Mika
> > =
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Verdana
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?<BR>
> >&nbsp=3B<BR>
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
> >ng a feature of all CPUs=2C at least ones that have any floating point supp=
> >ort? Or any software floating point library?<BR>
> >For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
> >Chances are high they only expose 64bit float and nothing else.<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >I know=2C I know "never say never"=2C but sometimes....?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >Certainly there are also 80bit formats on x86 and 68K.<BR>
> >&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
> >And I think 128bit formats on PowerPC.<BR>
> >And something beyond 64bits on IA64 (Itanium).<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> > m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
> >R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
> >.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
> >gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
> >oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
> >iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
> >=3B literals are really just ways of writing values=3D2C rather than statin=
> >g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
> >d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
> >ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
> >t=3B&gt=3B but they really do have incompatible value representations).<BR>=
> >&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
> >ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> > types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
> >gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
> >=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
> >e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
> >rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
> >overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
> >g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
> >Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
> >R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
> >pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> > interpretation of the<BR>&gt=3B values that have this property. I alluded =
> >earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
> >oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> > mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
> >there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
> >den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> =
> > </body>
> ></html>=
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/60619ac5/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 09:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 08:00:41 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W53BC0E8E635AB782E72BD8E66C0@phx.gbl>


 > Also, in case anyone is interested
> the current HEAD fails to compile the following packages on Windows Vista:
> m3core, libm3, m3tk

 

It works for me. On XP, but same thing.

Be sure to run upgrade.py to first update the compiler.

An older compiler cannot build a current m3core and/or libm3.

I got errors in Convert.m3 for example.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 23:09:46 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal





  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/557b4a5b/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 10:23:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 09:23:00 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>


I propose that integer signed overflow always raise an immediate exception.

Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.

For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

 

 

I propose that FloatMode's integer features not be the way forward.

 

 

There are two implementation strategies.

 

 

 - "check the carry flag"

   A processor-specific thing, but possibly something easy for the gcc backend to do.

   And very likely easy for the integrated backend.

   Probably very efficient.

 

 

 - internally generate function calls for every arithmetic operation

   like how sets are implemented

 

 

 Implementing most such functions is easy enough in portable C.

 Or maybe using Modula-3 and interface Word.

 

 

 e.g.

   void add(int a, int b, int* c, int* overflow)

   {

    int d = (a + b);

    /* overflow if input signs are equal and output sign is different;

        if input signs are unequal, overflow is not possible

        positive + positive: expect positive, else overflow

        negative + negative: expect negative, else overflow

        positive + negative: overflow not possible */

    *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

 

   void sub(int a, int b, int* c, int* overflow)

   {

    int d = (a - b);

    /* overflow if input signs are unequal and output sign is different than first input;

        if input signs are equal, overflow is not possible;

        positive - negative: expect positive, overflow if negative

        negative - positive: expect negative, overflow if positive

        positive - positive, negative - negative: overflow not possible */

    *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

#include <limits.h>

 

  void mult(int a, int b, int* c, int* overflow)

  {

    /* do operation in higher precision and check if it fits */

    int64 d = (a * (int64)b);

    *c = (int)d;

    *overflow = (d >= INT_MIN && d <= INT_MAX);

  }

 

/* for interface Word */

  typedef unsigned uint;

 

  void addu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a + b);

    /* overflow if output less than either input */

    *overflow = (d < a);

    *c = d;

 }

 

  void subu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a - b);

    /* overflow if output greater than first input */

    *overflow = (d > a);

    *c = d;

 }

 

  void multu(uint a, uint b, uint* c, int* overflow)

  {

    /* operate at higher precision and see if it fits */

     uint64 d = (a * (uint64)b);

    *overflow = (d <= UINT_MAX);

    *c = (uint)d;

 }

 

 void multLU(uint64 a, uint64 b, uint64* c, int* overflow)

 {

  /* break it down into smaller operations, not shown, but not difficult */

 }

 

 

Yes I know this is inefficient, but such is a possible price of portable safety.

 

 

A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

 

  

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/9a600909/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 10:23:24 +0000
Subject: [M3devel] Change File.i3/Status.size from CARDINAL to
	[0L..LAST(LONGINT)].
In-Reply-To: <20100112102039.C3F672474001@birch.elegosoft.com>
References: <20100112102039.C3F672474001@birch.elegosoft.com>
Message-ID: <COL101-W288784810774F26CD509E0E66C0@phx.gbl>


diff attached (cvs is lame..)

 

 - Jay


 
> Date: Tue, 12 Jan 2010 11:20:39 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/12 11:20:39
> 
> Modified files:
> cm3/m3-db/stable/src/: LogManager.m3 
> cm3/m3-libs/libbuf/src/: Buf.m3 
> cm3/m3-libs/libm3/src/os/Common/: File.i3 
> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 
> SocketPosix.m3 
> cm3/m3-libs/libm3/src/os/WIN32/: FSWin32.m3 FileWin32.m3 
> LazyConsole.m3 
> cm3/m3-libs/libm3/src/rw/: FileRd.m3 FileWr.m3 
> cm3/m3-sys/cm3/src/: WebFile.m3 
> cm3/m3-sys/cm3ide/src/utils/: Buf.m3 
> cm3/m3-sys/fix_nl/src/: Main.m3 
> cm3/m3-sys/m3quake/src/: QScanner.m3 
> cm3/m3-sys/mklib/src/: Main.m3 
> cm3/m3-tools/cmpdir/src/: Main.m3 
> cm3/m3-tools/dirfp/src/: Main.m3 
> cm3/m3-tools/m3tohtml/src/: DBRd.m3 
> 
> Log message:
> Change File.i3/Status.size from CARDINAL to [0L..LAST(LONGINT)].
> (Notice that some code checks if it is < 0, though don't
> confuse that with <= 0.)
> Leave rd/wr essentially unchanged.
> This is probably enough to fix the exception when browsing to a directory with large files.
> Not that much/any code can read/write such files on 32bit system -- all the direct users of File.i3
> appear to read the entire file into memory.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment.txt>

From wagner at elegosoft.com  Tue Jan 12 13:13:05 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 12 Jan 2010 13:13:05 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> Actually, that diagnostic indicates that scc-mailrelay.att.net is   
> blocking messages from the Elegosoft mail server (it is blacklisted!).

Ups, I must have misread that. I should pay better attention.
Mike, can you investigate why we're blacklisted at att?

Thanks,

Olaf

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>
>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous    
>>>> reply, and I'm still waiting. I wonder if the confirmation e-mail  
>>>>   is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From michael.anderson at elego.de  Tue Jan 12 13:52:32 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 13:52:32 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
Message-ID: <20100112135232.hd9dy91casc0g0kk@mail.elego.de>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> Actually, that diagnostic indicates that scc-mailrelay.att.net is    
>> blocking messages from the Elegosoft mail server (it is   
>> blacklisted!).
>
> Ups, I must have misread that. I should pay better attention.
> Mike, can you investigate why we're blacklisted at att?
>

I'm looking into it. I filled out att's unblock form and asked for  
clarification. I don't see anything in logs that looks like abuse from  
our side.  Messages to martinbishop at bellsouth.net have apparently been  
getting bounced by att for some time.

Mike

> Thanks,
>
> Olaf
>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous    
>>>>>  reply, and I'm still waiting. I wonder if the confirmation   
>>>>> e-mail   is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                  The mail system
>>>
>>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>>   521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>>   Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>   command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30   
>>> 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 18:00:04 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 12:00:04 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
References: <20100112064243.6828D1A2078@async.async.caltech.edu>
	<COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
Message-ID: <20100112170003.GA13141@topoi.pooq.com>

On Tue, Jan 12, 2010 at 06:55:27AM +0000, Jay K wrote:
> 
> TYPE Int1 = BITS 32, unsigned, integer, trap overflow;
> 
> TYPE Int2 = BITS 64, signed, integer, silent overflow;
> 
> TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;
> 
> TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;
> 
>  
> 
> and then provide just a few "canned" "popular" types so that
> 
> a lot of code can interoperate with a lot of code, but if a programmer
> 
> really needs something else, he has a chance of defining it.
> 
>  
> 
> Or maybe we can only define what is efficient in hardware, but still
> 
> do so with a syntax like this??

That resembles the approach of C--.  You have to explicitly define the 
precision, byte sex, etc. of your data, and the compiler refuses your 
program if it doesn't match what the machine provides.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 19:31:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:31:46 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <09217458-CE1E-4928-85EE-E8DCC4CC7755@cs.purdue.edu>


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 12 Jan 2010, at 01:42, Mika Nystrom wrote:

> Jay K writes:
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?
> 
> x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
> implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly).  That's not a non-IEEE format.  And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.

That would also be a great project for someone to pick up.  ;-)  Just trying to encourage participation...

> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?

I agree that the spec should be neutral on the formats.  Just as it is about INTEGER and ADDRESS.

> 
>    Mika
> 
>> 
>> =20
>> 
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>> ature of all CPUs=2C at least ones that have any floating point support? Or=
>> any software floating point library?
>> 
>> For that matter=2C probably Perl and Python=2C but I'd have to check.
>> 
>> Chances are high they only expose 64bit float and nothing else.
>> 
>> =20
>> 
>> =20
>> 
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?
>> 
>> =20
>> 
>> =20
>> 
>> I know=2C I know "never say never"=2C but sometimes....?
>> 
>> =20
>> 
>> =20
>> 
>> Certainly there are also 80bit formats on x86 and 68K.
>> 
>> Though x86 is moving away from this with SSE/SSE2.
>> 
>> And I think 128bit formats on PowerPC.
>> 
>> And something beyond 64bits on IA64 (Itanium).
>> 
>> =20
>> 
>> =20
>> 
>> - Jay
>> =20
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Integer literals=20
>>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>>> From: mika at async.async.caltech.edu
>>> =20
>>> Jay K writes:
>>>> 
>>>>>> One thing I've really struggled with over the introduction of LONGINT=
>> is
>>>>>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>> e
>>>>>> literals are really just ways of writing values=3D2C rather than stat=
>> ing
>>>>>> anything about how they should be represented.
>>>>>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>> tinct=3D
>>>> =3D2C
>>>>>> but they really do have incompatible value representations).
>>>>> 
>>>>> I agree=3D2C the need for distinctly typed literals is much greater fo=
>> r the
>>>>> floating types than the integer types=3D2C because they can't be viewe=
>> d
>>>>> as having overlapping value sets in any reasonable way.
>>>> 
>>>> =3D20
>>>> Huh? This seems to me to be directly opposite of the truth.
>>>> LONGREAL is a strict superset of REAL in what it can represent.
>>>> There is *complete* overlap.
>>>> Am I really mistaken here?
>>>> Floating point is indeed very wierd=3D2C but it isn't this wierd.
>>>> Right?
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>> =20
>>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>>> 754=2C you're right. Or at least there exists an interpretation of the
>>> values that have this property. I alluded earlier to the fact that
>>> Alpha represents single-precision by zeroing out the middle of the
>>> double-precision register (some of the mantissa and some of the exponent)=
>> .
>>> =20
>>> However I'm sure there are systems for which this is not true. Is=20
>>> Modula-3 forbidden from being ported to such machines?
>>> =20
>>> Mika
>> 		 	   		  =
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 10pt=3B
>> font-family:Verdana
>> }
>> --></style>
>> </head>
>> <body class=3D'hmmessage'>
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?<BR>
>> &nbsp=3B<BR>
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>> ng a feature of all CPUs=2C at least ones that have any floating point supp=
>> ort? Or any software floating point library?<BR>
>> For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>> Chances are high they only expose 64bit float and nothing else.<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> I know=2C I know "never say never"=2C but sometimes....?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> Certainly there are also 80bit formats on x86 and 68K.<BR>
>> &nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>> And I think 128bit formats on PowerPC.<BR>
>> And something beyond 64bits on IA64 (Itanium).<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
>> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>> R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>> .async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>> gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>> oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>> iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>> =3B literals are really just ways of writing values=3D2C rather than statin=
>> g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>> d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>> ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>> t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>> &gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>> ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
>> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>> gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>> =3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>> e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>> rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>> overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>> g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>> Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>> R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>> pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
>> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>> earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>> oing out the middle of the<BR>&gt=3B double-precision register (some of the=
>> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>> there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>> den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>> 		  </body>
>> </html>=
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--

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

From hosking at cs.purdue.edu  Tue Jan 12 19:33:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:33:59 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>

On 11 Jan 2010, at 23:55, Jay K wrote:

> I thought FloatMode was only related to floating point.
> So I looked:
>  
>    "IntOverflow" = an integer operation produced a result whose
>    absolute value is too large to be represented.
>  
>    "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
> 
>  
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>  
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

Yes, that's the issue.

>  For the floating point stuff:
>  
> Probably like other per-platform code, this should be done in #ifdefed C.

Agreed...  does that mean you will bite?  ;-)

>  
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/522b2ac7/attachment.html>

From hendrik at topoi.pooq.com  Tue Jan 12 19:55:21 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 13:55:21 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <20100112185520.GA21429@topoi.pooq.com>

On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
> On 11 Jan 2010, at 23:55, Jay K wrote:
> >  
> > Probably like other per-platform code, this should be done in #ifdefed C.
> 
> Agreed...  does that mean you will bite?  ;-)

I seem to remember an ad for Modula 3 once that went something like
 <big number> lines of code, and not a single ifdef!

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 19:59:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 18:59:24 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>


Maybe. But I don't want to prevent anyone else from stepping in.
And I want to bring up more platforms.
My integer implementation might be inefficient.
 
 
I see these as three or possibly more separate areas.
 Integer overflow. 
 Integer divide by zero. 
 Floating point. 
 
 
Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms is probably already "not silent", so not bad.
 
 
I'm not sure about unsigned/Word.T overflow, how that is supposed to be handled. In particular, signed overflow and unsigned overflow are slightly different, and unsigned/Word possibly suggests allowing silent overflow.
 
Again I really see quite a number of options here and programmer should indicate intent via choice of type or interface/function.
Fixed width, trap overflow, silent overflow, extent precision on overflow, etc.
 
 
I was talking to a friend about the integer/longint stuff.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 13:33:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
>
>
> On 11 Jan 2010, at 23:55, Jay K wrote:
>
> I thought FloatMode was only related to floating point.
> So I looked:
>
> "IntOverflow" = an integer operation produced a result whose
> absolute value is too large to be represented.
>
> "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
>
>
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
>
> Yes, that's the issue.
>
> For the floating point stuff:
>
> Probably like other per-platform code, this should be done in #ifdefed C.
>
> Agreed... does that mean you will bite? ;-)
>
>
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>
> - Jay
>
> 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:02:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:02:49 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <20100112185520.GA21429@topoi.pooq.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>,
	<20100112185520.GA21429@topoi.pooq.com>
Message-ID: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>


That's *really* *not* a good thing.
 
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 13:55:21 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>
>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>
>> Agreed... does that mean you will bite? ;-)
>
> I seem to remember an ad for Modula 3 once that went something like
> lines of code, and not a single ifdef!
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:13:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:13:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>, ,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>, ,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>, ,
	<20100112185520.GA21429@topoi.pooq.com>,
	<COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
Message-ID: <COL101-W200C77A1ABE9F1CAA90BCE66C0@phx.gbl>


Instead of the small evil of #ifdefs, we had two large evils:
 
 
 - cloning headers, fragile, tedious, error-prone 
   Though I think generally safe, *if* done *extremely* *carefully* and *correctly*. There is a need for the underlying system to not change. The commercial systems all do that well. 64bit FreeBSD seems to have a poor record at least. NetBSD changes the symbol names maybe often. etc.
 
 
 - cloning nearly identical Modula-3 code many times

 
The second could have been reduced, by making directories keyed by processor 
architecture or kernel, instead of architecture_kernel pairs.
 
 
The first could have been reduced a lot by limiting it to only what we use.
That was what I did at first with Cygwin.
But still.
 
 
By using #ifdefs we have gained a lot of portability and thrown away many lines of code.
 
 
A C generating backend will increase portability another very big step.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 19:02:49 +0000
> Subject: Re: [M3devel] FloatMode
>
>
> That's *really* *not* a good thing.
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 12 Jan 2010 13:55:21 -0500
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>>
>>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>>
>>> Agreed... does that mean you will bite? ;-)
>>
>> I seem to remember an ad for Modula 3 once that went something like
>> lines of code, and not a single ifdef!
>>
>> -- hendrik 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 20:21:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:21:14 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>

On 11 Jan 2010, at 23:09, Randy Coleburn wrote:

> Tony:
>  
> I?m sorry, I missed the fact that you changed the type to ?Integer? vs. ?INTEGER? and defined ?Integer? to be ?INTEGER? or ?LONGINT?.
>  
> I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be ?happy? with this state of affairs.
>  
> I am confused though by your last set of statements, namely:
>  
> >I don't think we need to do this, assuming you understand what I have said above.
> > 
> >ORD(x: INTEGER): LONGINT
> >ORD(x: LONGINT): INTEGER
> >ORD(x: Enumeration): INTEGER
> >ORD(x: Subrange): Base(Subrange)
> > 
> >ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> Didn?t you mean:
>                 ORD(x:INTEGER): INTEGER
>                 ORD(x:LONGINT): LONGINT

Sorry, yes.   Cut/paste error.

>  Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
> "m3-libs\m3core"
> "m3-libs\libm3"
> "m3-tools\m3tk"
> So some recent changes have caused a problem.

Did you bootstrap a new compiler?  You will need to bootstrap a compiler before you can compile the revised ORD/VAL definitions.

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 10:40 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> On 11 Jan 2010, at 22:11, Randy Coleburn wrote:
> 
> 
> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?
>  
> Sorry, my error.  I realised after writing that I had mis-spoken.
> 
> 
>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.
>  
> That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):
>  
> 55,56c55,56
> <               ORD  (element: Ordinal): INTEGER
> <               VAL  (i: INTEGER; T: OrdinalType): T
> ---
> >               ORD  (element: Ordinal): Integer
> >               VAL  (i: Integer; T: OrdinalType): T
> 74c74
> < If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
> ---
> > If n is an integer of type T, ORD(n) = VAL(n, T) = n.
>  
> Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.
> 
> 
>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)
>  
> No, enumerations map only onto INTEGER.
> 
> 
> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).
>  
> I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.
> 
> 
>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!
>  
> Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.
> 
> 
>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)
>  
> No,
>  
> longint := VAL(integer, LONGINT)
> integer := VAL(longint, INTEGER)
> int := ORD(int)
> longint := ORD(longint)
> 
> 
> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 
>  
> This captures the identities precisely, which is why I reverted to the original formulation.
> 
> 
> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)
>  
> Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.
> 
> 
>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);
>  
> That is what is now implemented.
> 
> 
> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.
>  
> No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.
> 
> 
>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.
>  
> ORD now can never cause a checked runtime error, just as with Nelson.
> 
> 
>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?
>  
> Yes, correct.  This is what is now implemented in the CVS head.
> 
> 
>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.
>  
> See above.
> 
> 
> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.
>  
> See above.
>  
> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.
>  
> No assignability!
> 
> 
> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.
>  
> I don't think we need to do this, assuming you understand what I have said above.
>  
> ORD(x: INTEGER): LONGINT
> ORD(x: LONGINT): INTEGER
> ORD(x: Enumeration): INTEGER
> ORD(x: Subrange): Base(Subrange)
>  
> ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> e.      Any other ideas?
>  
> I think we are done...
> 
> 
>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/79a91506/attachment.html>

From mika at async.async.caltech.edu  Tue Jan 12 20:28:07 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:28:07 -0800
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
	<COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>
Message-ID: <20100112192807.055FC1A2079@async.async.caltech.edu>

Jay K writes:
>
>Maybe. But I don't want to prevent anyone else from stepping in.
>And I want to bring up more platforms.
>My integer implementation might be inefficient.
>=20
>=20
>I see these as three or possibly more separate areas.
> Integer overflow.=20
> Integer divide by zero.=20
> Floating point.=20
>=20
>=20
>Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms =
>is probably already "not silent"=2C so not bad.
>=20
>=20
>I'm not sure about unsigned/Word.T overflow=2C how that is supposed to be h=
>andled. In particular=2C signed overflow and unsigned overflow are slightly=
> different=2C and unsigned/Word possibly suggests allowing silent overflow.

Word.T never overflows.  Tons of code depends on this!

Also a lot of machines don't have integer flags, don't forget that.  (Alpha
and MIPS come to mind, although MIPS has an "add-with-exception" instruction.)

     Mika

>=20
>Again I really see quite a number of options here and programmer should ind=
>icate intent via choice of type or interface/function.
>Fixed width=2C trap overflow=2C silent overflow=2C extent precision on over=
>flow=2C etc.
>=20
>=20
>I was talking to a friend about the integer/longint stuff.
>=20
>=20
> - Jay
>
>
>________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 13:33:59 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>>
>>
>> On 11 Jan 2010=2C at 23:55=2C Jay K wrote:
>>
>> I thought FloatMode was only related to floating point.
>> So I looked:
>>
>> "IntOverflow" =3D an integer operation produced a result whose
>> absolute value is too large to be represented.
>>
>> "IntDivByZero" =3D integer "DIV" or "MOD" by zero.
>> \end{quote}
>>
>>
>> This part of it should be easy to implement for all architectures.
>> The entire thing probably isn't too difficult either on many platforms ei=
>ther.
>>
>> However...I was surprised by this.
>> I thought the real "intent" in Modula-3 to not have this be configurable
>> and endeavor for overflow and divide by zero to always immediately
>> raise an exception? The only "out" is that it might not get implemented o=
>n some platforms for some reason?
>>
>> Yes=2C that's the issue.
>>
>> For the floating point stuff:
>>
>> Probably like other per-platform code=2C this should be done in #ifdefed =
>C.
>>
>> Agreed... does that mean you will bite? =3B-)
>>
>>
>> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
>> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
>> etc.
>>
>> - Jay
>>
>> 		 	   		  =


From hosking at cs.purdue.edu  Tue Jan 12 20:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:30:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
Message-ID: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>

On 12 Jan 2010, at 04:23, Jay K wrote:

> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

That is going to pose a performance issue (that many C programmers may baulk at!).

> I propose that FloatMode's integer features not be the way forward.

Why not?

> There are two implementation strategies.
>  
>  
>  - "check the carry flag"
>    A processor-specific thing, but possibly something easy for the gcc backend to do.
>    And very likely easy for the integrated backend.
>    Probably very efficient.

Yes, doable.

>   - internally generate function calls for every arithmetic operation
>    like how sets are implemented

Very bad for performance.  We should rely on the processor support for arithmetic traps or condition variables.


>   Implementing most such functions is easy enough in portable C.
>  Or maybe using Modula-3 and interface Word.

Not the best way going forward...

>   e.g.
>    void add(int a, int b, int* c, int* overflow)
>    {
>     int d = (a + b);
>     /* overflow if input signs are equal and output sign is different;
>         if input signs are unequal, overflow is not possible
>         positive + positive: expect positive, else overflow
>         negative + negative: expect negative, else overflow
>         positive + negative: overflow not possible */
>     *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
>  
>    void sub(int a, int b, int* c, int* overflow)
>    {
>     int d = (a - b);
>     /* overflow if input signs are unequal and output sign is different than first input;
>         if input signs are equal, overflow is not possible;
>         positive - negative: expect positive, overflow if negative
>         negative - positive: expect negative, overflow if positive
>         positive - positive, negative - negative: overflow not possible */
>     *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
> #include <limits.h>
>  
>   void mult(int a, int b, int* c, int* overflow)
>   {
>     /* do operation in higher precision and check if it fits */
>     int64 d = (a * (int64)b);
>     *c = (int)d;
>     *overflow = (d >= INT_MIN && d <= INT_MAX);
>   }
>  
> /* for interface Word */
>   typedef unsigned uint;
>  
>   void addu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a + b);
>     /* overflow if output less than either input */
>     *overflow = (d < a);
>     *c = d;
>  }
>  
>   void subu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a - b);
>     /* overflow if output greater than first input */
>     *overflow = (d > a);
>     *c = d;
>  }
>  
>   void multu(uint a, uint b, uint* c, int* overflow)
>   {
>     /* operate at higher precision and see if it fits */
>      uint64 d = (a * (uint64)b);
>     *overflow = (d <= UINT_MAX);
>     *c = (uint)d;
>  }
>  
>  void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>  {
>   /* break it down into smaller operations, not shown, but not difficult */
>  }
>  
>  
> Yes I know this is inefficient, but such is a possible price of portable safety.
>  
>  
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

FloatMode seems a perfectly reasonable way forward doesn't it?  It allows both trap-based and (with compiler support) checked condition code implementations.

>  
>   
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/8f3c37df/attachment.html>

From jay.krell at cornell.edu  Tue Jan 12 20:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:46:21 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
Message-ID: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>


I'm not against using "hardware traps", if they exist.
I'll have to do a bunch of research as to their existance.
 
 
 
I don't think one should be able to turn this on or off.
I think it should be static per type or interface/library.
 
 
Even so, if it is a runtime configuration, I realize
that the implementation, on a system
without hardware traps, with a processor-specific
flag would look *like*:
 
 
 check for overflow 
 if no overflow, continue on as usual
 if overflow, call out to a function
   that function:
      fetch the thread local
      depending on *that*, raise an exception or continue on 
 
 
I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
 
 
Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
 
 
That can also be highly portable, mimicing the algorithms I showed.
 
 
The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
 
 
- Jay



________________________________
> Subject: Re: [M3devel] integer overflow
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 14:30:00 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>
>
> On 12 Jan 2010, at 04:23, Jay K wrote:
>
> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>
> That is going to pose a performance issue (that many C programmers may baulk at!).
>
> I propose that FloatMode's integer features not be the way forward.
>
> Why not?
>
> There are two implementation strategies.
>
>
> - "check the carry flag"
> A processor-specific thing, but possibly something easy for the gcc backend to do.
> And very likely easy for the integrated backend.
> Probably very efficient.
>
> Yes, doable.
>
> - internally generate function calls for every arithmetic operation
> like how sets are implemented
>
> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>
>
> Implementing most such functions is easy enough in portable C.
> Or maybe using Modula-3 and interface Word.
>
> Not the best way going forward...
>
> e.g.
> void add(int a, int b, int* c, int* overflow)
> {
> int d = (a + b);
> /* overflow if input signs are equal and output sign is different;
> if input signs are unequal, overflow is not possible
> positive + positive: expect positive, else overflow
> negative + negative: expect negative, else overflow
> positive + negative: overflow not possible */
> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
>
> void sub(int a, int b, int* c, int* overflow)
> {
> int d = (a - b);
> /* overflow if input signs are unequal and output sign is different than first input;
> if input signs are equal, overflow is not possible;
> positive - negative: expect positive, overflow if negative
> negative - positive: expect negative, overflow if positive
> positive - positive, negative - negative: overflow not possible */
> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
> #include
>
> void mult(int a, int b, int* c, int* overflow)
> {
> /* do operation in higher precision and check if it fits */
> int64 d = (a * (int64)b);
> *c = (int)d;
> *overflow = (d>= INT_MIN && d <= INT_MAX);
> }
>
> /* for interface Word */
> typedef unsigned uint;
>
> void addu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a + b);
> /* overflow if output less than either input */
> *overflow = (d < a);
> *c = d;
> }
>
> void subu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a - b);
> /* overflow if output greater than first input */
> *overflow = (d> a);
> *c = d;
> }
>
> void multu(uint a, uint b, uint* c, int* overflow)
> {
> /* operate at higher precision and see if it fits */
> uint64 d = (a * (uint64)b);
> *overflow = (d <= UINT_MAX);
> *c = (uint)d;
> }
>
> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
> {
> /* break it down into smaller operations, not shown, but not difficult */
> }
>
>
> Yes I know this is inefficient, but such is a possible price of portable safety.
>
>
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>
> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 20:57:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:57:52 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <20100112195752.22AC21A2079@async.async.caltech.edu>


Are you actually proposing making range checking mandatory for integer
arithmetic?

I think that's a bad idea... the performance hit could be very high
(especially on some architectures).

The language should already guarantee that problems in this area can't
cause unchecked runtime errors.

     Mika

Jay K writes:
>
>I'm not against using "hardware traps"=2C if they exist.
>I'll have to do a bunch of research as to their existance.
>=20
>=20
>=20
>I don't think one should be able to turn this on or off.
>I think it should be static per type or interface/library.
>=20
>=20
>Even so=2C if it is a runtime configuration=2C I realize
>that the implementation=2C on a system
>without hardware traps=2C with a processor-specific
>flag would look *like*:
>=20
>=20
> check for overflow=20
> if no overflow=2C continue on as usual
> if overflow=2C call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*=2C raise an exception or continue on=20
>=20
>=20
>I suspect I could easily quickly put in place a portable implementation=2C =
>and..like *almost* everything else that isn't I/O bound (other than code si=
>ze issue).
>=20
>=20
>Hm. Actually another very good approach is probably to have the front end i=
>nline most of this logic=2C like everything except 64bit multiplication on =
>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>ly probably competitive. There is already inlining of the computation of th=
>e result=2C and merely passing three parameters won't be cheap.
>=20
>=20
>That can also be highly portable=2C mimicing the algorithms I showed.
>=20
>=20
>The front end can also do the optimization where overflow isn't necessarily=
> checked for every single operation.
>=20
>=20
>- Jay
>
>
>
>________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>>
>>
>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>
>> I propose that integer signed overflow always raise an immediate exceptio=
>n.
>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
> no exceptions at all.
>> For folks that want silent wraparound=2C maybe a separate interface like =
>UnsafeInt.
>>
>> That is going to pose a performance issue (that many C programmers may ba=
>ulk at!).
>>
>> I propose that FloatMode's integer features not be the way forward.
>>
>> Why not?
>>
>> There are two implementation strategies.
>>
>>
>> - "check the carry flag"
>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>kend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>>
>> Yes=2C doable.
>>
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>>
>> Very bad for performance. We should rely on the processor support for ari=
>thmetic traps or condition variables.
>>
>>
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>>
>> Not the best way going forward...
>>
>> e.g.
>> void add(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a + b)=3B
>> /* overflow if input signs are equal and output sign is different=3B
>> if input signs are unequal=2C overflow is not possible
>> positive + positive: expect positive=2C else overflow
>> negative + negative: expect negative=2C else overflow
>> positive + negative: overflow not possible */
>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>>
>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a - b)=3B
>> /* overflow if input signs are unequal and output sign is different than =
>first input=3B
>> if input signs are equal=2C overflow is not possible=3B
>> positive - negative: expect positive=2C overflow if negative
>> negative - positive: expect negative=2C overflow if positive
>> positive - positive=2C negative - negative: overflow not possible */
>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>> #include
>>
>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d =3D (a * (int64)b)=3B
>> *c =3D (int)d=3B
>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>> }
>>
>> /* for interface Word */
>> typedef unsigned uint=3B
>>
>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a + b)=3B
>> /* overflow if output less than either input */
>> *overflow =3D (d < a)=3B
>> *c =3D d=3B
>> }
>>
>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a - b)=3B
>> /* overflow if output greater than first input */
>> *overflow =3D (d> a)=3B
>> *c =3D d=3B
>> }
>>
>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d =3D (a * (uint64)b)=3B
>> *overflow =3D (d <=3D UINT_MAX)=3B
>> *c =3D (uint)d=3B
>> }
>>
>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>> {
>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>t */
>> }
>>
>>
>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>e safety.
>>
>>
>> A hybrid is probably possible if the gcc backend support must be processo=
>r specific and we gradually provide the implementations.
>>
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>both trap-based and (with compiler support) checked condition code implemen=
>tations.
>>
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>> 		 	   		  =


From jay.krell at cornell.edu  Tue Jan 12 21:21:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:21:27 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>


Range checking and overflow checking I think are different.
 
 
TYPE T1 = [1..6];
a:T1 := 7; (* range check error *)
b:T1 := 6;
c:T1 := 1;
d:T1 := b + c; (* range check error *)
e:T1 := c - b; (* range check error *)
f:ARRAY [1..4] OF INTEGER;
f[b] := 0; (* range check error *)
g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
 
 
But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
 
 
Initially it'll probably be a command line option or such.
 
 
Or maybe it isn't a safety issue?
As long as one has checks on array indexing? Which I'm sure we do.
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 12 Jan 2010 11:57:52 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
>
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
>
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).
>
> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.
>
> Mika
>
> Jay K writes:
>>
>>I'm not against using "hardware traps"=2C if they exist.
>>I'll have to do a bunch of research as to their existance.
>>=20
>>=20
>>=20
>>I don't think one should be able to turn this on or off.
>>I think it should be static per type or interface/library.
>>=20
>>=20
>>Even so=2C if it is a runtime configuration=2C I realize
>>that the implementation=2C on a system
>>without hardware traps=2C with a processor-specific
>>flag would look *like*:
>>=20
>>=20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*=2C raise an exception or continue on=20
>>=20
>>=20
>>I suspect I could easily quickly put in place a portable implementation=2C =
>>and..like *almost* everything else that isn't I/O bound (other than code si=
>>ze issue).
>>=20
>>=20
>>Hm. Actually another very good approach is probably to have the front end i=
>>nline most of this logic=2C like everything except 64bit multiplication on =
>>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>>ly probably competitive. There is already inlining of the computation of th=
>>e result=2C and merely passing three parameters won't be cheap.
>>=20
>>=20
>>That can also be highly portable=2C mimicing the algorithms I showed.
>>=20
>>=20
>>The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>>=20
>>=20
>>- Jay
>>
>>
>>
>>________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exceptio=
>>n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>>UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may ba=
>>ulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>>kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes=2C doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for ari=
>>thmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>>
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>>first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>> #include
>>>
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>>
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>>
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>>t */
>>> }
>>>
>>>
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>>e safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processo=
>>r specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>>both trap-based and (with compiler support) checked condition code implemen=
>>tations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 21:27:06 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 12:27:06 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112202706.C98571A2079@async.async.caltech.edu>

Jay K writes:
>
>Range checking and overflow checking I think are different.
>=20
>=20
>TYPE T1 =3D [1..6]=3B
>a:T1 :=3D 7=3B (* range check error *)
>b:T1 :=3D 6=3B
>c:T1 :=3D 1=3B
>d:T1 :=3D b + c=3B (* range check error *)
>e:T1 :=3D c - b=3B (* range check error *)
>f:ARRAY [1..4] OF INTEGER=3B
>f[b] :=3D 0=3B (* range check error *)
>g:INTEGER :=3D LAST(INTEGER) - 5 + a=3B (* overflow *)
>=20
>=20
>But anyway=2C yes it will be slower=2C but I believe it should be mandatory=
>=2C at least in safe modules=2C it is needed for safety=2C and I doubt it'l=
>l be *noticably* slower for the vast majority of code.
>=20
>=20
>Initially it'll probably be a command line option or such.
>=20
>=20
>Or maybe it isn't a safety issue?
>As long as one has checks on array indexing? Which I'm sure we do.

That was my point.  It shouldn't be a safety issue.  It's orthogonal to the
Modula-3 definition of UNSAFE.

    Mika



From michael.anderson at elego.de  Tue Jan 12 21:35:55 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 21:35:55 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100112213555.v7disk2h44kkcos8@mail.elego.de>

Hi All,

att.net has responded and promised to have us off of their blacklist  
within 48 hours.
I'll inform Chris from another mail server.

Mike

Quoting Randy Coleburn <rcolebur at SCIRES.COM>:

> I also took the liberty of contacting him.  Shown below is my   
> message and his response:
> Regards,
> Randy
>
> On Mon, 11 Jan 2010 12:19:26 -0500
> Randy Coleburn <rcolebur at SCIRES.COM> wrote:
>
>> Just want to let you know that the folks hosting the mail list   
>> service are trying to fulfill your request to be added to the   
>> m3devel mail list.
>>
>> The problem seems to be blacklisting of one of the hosts.  At first  
>>  it seemed your email address was blacklisted, but upon further   
>> investigation it seems your email server   
>> (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has   
>> blacklisted the mail list server at elegosoft.  Note that the   
>> elegosoft server is based in Germany.
>>
>> The server admins are working on the problem, but not sure if/when   
>> it will be resolved.
>>
>> I'm one of the developers and also subscribe to the list and   
>> noticed the traffic about your request, so thought I would try and   
>> send you an email to see if it gets thru and to let you know of the  
>>  problem.
>>
>> Regards,
>> Randy
>>
>
> Thanks for the heads up. I'll give them a call to see what the problem is.
>
> AT&T actually does it's mail hosting through Yahoo mail, so they   
> might actually be the ones doing the blacklisting. I'm going to do   
> some poking around on this end; and I'll send you an email if I find  
>  anything noteworthy.
>
> Thank you.
>
> --
> Chris <dimonax at att.net>
>
>
> -----Original Message-----
> From: John Polstra [mailto:jdp at polstra.com]
> Sent: Monday, January 11, 2010 11:44 PM
> To: Tony Hosking
> Cc: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: CM3 development Inquiry.
>
> I forwarded this to him, and my mail log says it was delivered.
>
> John
>
> Tony Hosking wrote:
>> Actually, that diagnostic indicates that scc-mailrelay.att.net
>> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft
>> mail server (it is blacklisted!).
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu
>>> <mailto:hosking at cs.purdue.edu>>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous
>>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail
>>>>>  is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com
>>> <http://mx0.elegosoft.com>.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                   The mail system
>>>
>>> <dimonax at att.net <mailto:dimonax at att.net>>: host
>>> scc-mailrelay.att.net[204.127.208.75] said:
>>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521
>>> DNSRBL:
>>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>    command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
>>> 86 95
>>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>
>>
>



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 21:37:49 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 15:37:49 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112203749.GA27597@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
> 
> Range checking and overflow checking I think are different.
>  
>  
> TYPE T1 = [1..6];
> a:T1 := 7; (* range check error *)
> b:T1 := 6;
> c:T1 := 1;
> d:T1 := b + c; (* range check error *)
> e:T1 := c - b; (* range check error *)
> f:ARRAY [1..4] OF INTEGER;
> f[b] := 0; (* range check error *)
> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>  
>  
> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>  
>  
> Initially it'll probably be a command line option or such.
>  
>  
> Or maybe it isn't a safety issue?
> As long as one has checks on array indexing? Which I'm sure we do.

I always thought one of the points about declared ranges (instead of 
making everything just int, as C does) was to enable one to suppress 
most of the array indexing checks safely.

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 21:51:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:51:46 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112203749.GA27597@topoi.pooq.com>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>,
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>,
	<20100112203749.GA27597@topoi.pooq.com>
Message-ID: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>


> subranges allow suppressing array index checks
 
I didn't know that.
Sounds reasonable.
I haven't contradicted it, have I?
 
 
That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.
 
Gotta go,
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 15:37:49 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
>>
>> Range checking and overflow checking I think are different.
>>
>>
>> TYPE T1 = [1..6];
>> a:T1 := 7; (* range check error *)
>> b:T1 := 6;
>> c:T1 := 1;
>> d:T1 := b + c; (* range check error *)
>> e:T1 := c - b; (* range check error *)
>> f:ARRAY [1..4] OF INTEGER;
>> f[b] := 0; (* range check error *)
>> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>>
>>
>> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>>
>>
>> Initially it'll probably be a command line option or such.
>>
>>
>> Or maybe it isn't a safety issue?
>> As long as one has checks on array indexing? Which I'm sure we do.
>
> I always thought one of the points about declared ranges (instead of
> making everything just int, as C does) was to enable one to suppress
> most of the array indexing checks safely.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Tue Jan 12 22:17:00 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 16:17:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
References: <20100112203749.GA27597@topoi.pooq.com>
	<COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
Message-ID: <20100112211700.GA29801@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:51:46PM +0000, Jay K wrote:
> 
> > subranges allow suppressing array index checks
>  
> I didn't know that.
> Sounds reasonable.
> I haven't contradicted it, have I?

No.  Assignments to subrange variables can be a lot less frequent than 
the use of those variables as subscripts, especially in, say, 
matrix-handling code.

>  
>  
> That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
> Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.

Might not have to check the lower bound at all.
Might only have to check the upper bound when you have to anyway in the 
loop control.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 23:02:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:02:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <E48D174B-D53C-4D58-8F13-10B450ED3437@cs.purdue.edu>

On 12 Jan 2010, at 14:57, Mika Nystrom wrote:

> 
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
> 
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).

I agree.

> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.

It does.

> 
>     Mika
> 
> Jay K writes:
>> 
>> I'm not against using "hardware traps"=2C if they exist.
>> I'll have to do a bunch of research as to their existance.
>> =20
>> =20
>> =20
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>> =20
>> =20
>> Even so=2C if it is a runtime configuration=2C I realize
>> that the implementation=2C on a system
>> without hardware traps=2C with a processor-specific
>> flag would look *like*:
>> =20
>> =20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>>  that function:
>>     fetch the thread local
>>     depending on *that*=2C raise an exception or continue on=20
>> =20
>> =20
>> I suspect I could easily quickly put in place a portable implementation=2C =
>> and..like *almost* everything else that isn't I/O bound (other than code si=
>> ze issue).
>> =20
>> =20
>> Hm. Actually another very good approach is probably to have the front end i=
>> nline most of this logic=2C like everything except 64bit multiplication on =
>> 32bit platform. At first I though that'd be too bloating=2C but it's actual=
>> ly probably competitive. There is already inlining of the computation of th=
>> e result=2C and merely passing three parameters won't be cheap.
>> =20
>> =20
>> That can also be highly portable=2C mimicing the algorithms I showed.
>> =20
>> =20
>> The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>> =20
>> =20
>> - Jay
>> 
>> 
>> 
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> 
>>> 
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>> 
>>> I propose that integer signed overflow always raise an immediate exceptio=
>> n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>> UnsafeInt.
>>> 
>>> That is going to pose a performance issue (that many C programmers may ba=
>> ulk at!).
>>> 
>>> I propose that FloatMode's integer features not be the way forward.
>>> 
>>> Why not?
>>> 
>>> There are two implementation strategies.
>>> 
>>> 
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>> kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>> 
>>> Yes=2C doable.
>>> 
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>> 
>>> Very bad for performance. We should rely on the processor support for ari=
>> thmetic traps or condition variables.
>>> 
>>> 
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>> 
>>> Not the best way going forward...
>>> 
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> 
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>> first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> #include
>>> 
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>> 
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>> 
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>> 
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>> t */
>>> }
>>> 
>>> 
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>> e safety.
>>> 
>>> 
>>> A hybrid is probably possible if the gcc backend support must be processo=
>> r specific and we gradually provide the implementations.
>>> 
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>> both trap-based and (with compiler support) checked condition code implemen=
>> tations.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 		 	   		  =



From hosking at cs.purdue.edu  Tue Jan 12 23:09:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:09:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>

On 12 Jan 2010, at 14:46, Jay K wrote:

> I'm not against using "hardware traps", if they exist.
> I'll have to do a bunch of research as to their existence.

Their existence is why FloatMode was designed in the first place.

> I don't think one should be able to turn this on or off.
> I think it should be static per type or interface/library.

I disagree.  You are conflating language safety with what the semantics of arithmetic should be.  The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C).  Overflow doesn't create a "bad" value for an INTEGER.  It is still an INTEGER value.  It is just that the value is obtained by overflowed arithmetic in the hardware.


> Even so, if it is a runtime configuration, I realize
> that the implementation, on a system
> without hardware traps, with a processor-specific
> flag would look *like*:
> 
> 
> check for overflow 
> if no overflow, continue on as usual
> if overflow, call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*, raise an exception or continue on 

Why do you assume we would even support thread-local handling of overflow?    If we did, I would argue that the code would be more like:

check if this thread cares about overflow
if it does then check the overflow flag and raise an exception if it is set

> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
> 
> 
> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.

The inline sequence would be quite cheap if we really needed to go that route.

> That can also be highly portable, mimicing the algorithms I showed.
> 
> 
> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.

Correct.  It is never needed for subranges that don't include the extremes of the integer representation.

> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> 
>> 
>> On 12 Jan 2010, at 04:23, Jay K wrote:
>> 
>> I propose that integer signed overflow always raise an immediate exception.
>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>> 
>> That is going to pose a performance issue (that many C programmers may baulk at!).
>> 
>> I propose that FloatMode's integer features not be the way forward.
>> 
>> Why not?
>> 
>> There are two implementation strategies.
>> 
>> 
>> - "check the carry flag"
>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>> 
>> Yes, doable.
>> 
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>> 
>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>> 
>> 
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>> 
>> Not the best way going forward...
>> 
>> e.g.
>> void add(int a, int b, int* c, int* overflow)
>> {
>> int d = (a + b);
>> /* overflow if input signs are equal and output sign is different;
>> if input signs are unequal, overflow is not possible
>> positive + positive: expect positive, else overflow
>> negative + negative: expect negative, else overflow
>> positive + negative: overflow not possible */
>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> 
>> void sub(int a, int b, int* c, int* overflow)
>> {
>> int d = (a - b);
>> /* overflow if input signs are unequal and output sign is different than first input;
>> if input signs are equal, overflow is not possible;
>> positive - negative: expect positive, overflow if negative
>> negative - positive: expect negative, overflow if positive
>> positive - positive, negative - negative: overflow not possible */
>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> #include
>> 
>> void mult(int a, int b, int* c, int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d = (a * (int64)b);
>> *c = (int)d;
>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>> }
>> 
>> /* for interface Word */
>> typedef unsigned uint;
>> 
>> void addu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a + b);
>> /* overflow if output less than either input */
>> *overflow = (d < a);
>> *c = d;
>> }
>> 
>> void subu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a - b);
>> /* overflow if output greater than first input */
>> *overflow = (d> a);
>> *c = d;
>> }
>> 
>> void multu(uint a, uint b, uint* c, int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d = (a * (uint64)b);
>> *overflow = (d <= UINT_MAX);
>> *c = (uint)d;
>> }
>> 
>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>> {
>> /* break it down into smaller operations, not shown, but not difficult */
>> }
>> 
>> 
>> Yes I know this is inefficient, but such is a possible price of portable safety.
>> 
>> 
>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>> 
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Tue Jan 12 23:51:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 22:51:29 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
Message-ID: <COL101-W272903528EBD5811FFF56CE66C0@phx.gbl>


I didn't think many processors offered integer overflow "traps".
I'm so used to condition flags being the way, on x86, PowerPC, 6502, etc.
  (6502 it turns out is awful, but you don't realize you are in the insane asylum until you leave it; signed comparisons required doing an actual "destructive" subtract, the "compare" instruction only "works" for unsigned comparisons) 
 
 
Divide by zero and floating point I'm more familiar with.
  Though I think x86 and PowerPC vary on that point -- integer divide by zero.
  I think that was mentioned on the "let's change architectures yet again" guide.
 
 
The reason you'd check for overflow before you'd check if the thread cares about overflow, is that the first is probably *much* cheaper and yields "true" much less often. Checking if the thread cares about trapping overflow requires getting a thread local. Checking for overflow on x86 is typically one conditional branch I believe. Or maybe a "cmove", probably cheaper.
 
 
Granted, if you get the address of the thread locals only upon entry (such as in a function with TRY!) and you only check the bit when there hasn't been a function call (such as to possibly change the setting), then the check isn't too too bad. Still, one conditional branch, encoded to be predicted correctly (whichever way that is..), seems cheap. Plus there might be a reasonable way to "accumulate" overflow that is even cheaper. Like, having a local overflow variable and if you have e := a + b + c + d, do like:
 
 
  overflow = 0;  
  e = a + b;  
  overflow += carry;  
  e += c;  
  overflow += carry;  
  e += d;  
  overflow += carry;  
  if overflow raise 
 
 
might be cheaper than:
  overflow = 0;  
  e = a + b;  
  if overflow raise 
  e += c;  
  if overflow raise 
  e += d;  
  if overflow raise 
 
 
 
I really thought that detecting/trapping integer overflow was part of being safe. It seems I was very mistaken.
So I guess any work here is really not so important as I thought?
Someone convince me that it is actually important?
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 17:09:36 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On 12 Jan 2010, at 14:46, Jay K wrote:
>
>> I'm not against using "hardware traps", if they exist.
>> I'll have to do a bunch of research as to their existence.
>
> Their existence is why FloatMode was designed in the first place.
>
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>
> I disagree. You are conflating language safety with what the semantics of arithmetic should be. The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C). Overflow doesn't create a "bad" value for an INTEGER. It is still an INTEGER value. It is just that the value is obtained by overflowed arithmetic in the hardware.
>
>
>> Even so, if it is a runtime configuration, I realize
>> that the implementation, on a system
>> without hardware traps, with a processor-specific
>> flag would look *like*:
>>
>>
>> check for overflow
>> if no overflow, continue on as usual
>> if overflow, call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*, raise an exception or continue on
>
> Why do you assume we would even support thread-local handling of overflow? If we did, I would argue that the code would be more like:
>
> check if this thread cares about overflow
> if it does then check the overflow flag and raise an exception if it is set
>
>> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
>>
>>
>> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
>
> The inline sequence would be quite cheap if we really needed to go that route.
>
>> That can also be highly portable, mimicing the algorithms I showed.
>>
>>
>> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
>
> Correct. It is never needed for subranges that don't include the extremes of the integer representation.
>
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010, at 04:23, Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exception.
>>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may baulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes, doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a + b);
>>> /* overflow if input signs are equal and output sign is different;
>>> if input signs are unequal, overflow is not possible
>>> positive + positive: expect positive, else overflow
>>> negative + negative: expect negative, else overflow
>>> positive + negative: overflow not possible */
>>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>>
>>> void sub(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a - b);
>>> /* overflow if input signs are unequal and output sign is different than first input;
>>> if input signs are equal, overflow is not possible;
>>> positive - negative: expect positive, overflow if negative
>>> negative - positive: expect negative, overflow if positive
>>> positive - positive, negative - negative: overflow not possible */
>>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>> #include
>>>
>>> void mult(int a, int b, int* c, int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d = (a * (int64)b);
>>> *c = (int)d;
>>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint;
>>>
>>> void addu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a + b);
>>> /* overflow if output less than either input */
>>> *overflow = (d < a);
>>> *c = d;
>>> }
>>>
>>> void subu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a - b);
>>> /* overflow if output greater than first input */
>>> *overflow = (d> a);
>>> *c = d;
>>> }
>>>
>>> void multu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d = (a * (uint64)b);
>>> *overflow = (d <= UINT_MAX);
>>> *c = (uint)d;
>>> }
>>>
>>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>>> {
>>> /* break it down into smaller operations, not shown, but not difficult */
>>> }
>>>
>>>
>>> Yes I know this is inefficient, but such is a possible price of portable safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 00:02:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 23:02:58 +0000
Subject: [M3devel] integer overflow and for loops
Message-ID: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>


http://www.roland-illig.de/articles/modula-3-for-loop.pdf





  		 	   		  

From hosking at cs.purdue.edu  Wed Jan 13 03:18:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:18:59 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>

> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

This assumes that overflow checks should be defined on integers in the language.  Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language.  I think this is an unacceptable overhead for a systems programming language.  C does not have it.  The characteristics of restricted range integer arithmetic are well understood.  If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).



From rcolebur at SCIRES.COM  Wed Jan 13 03:23:04 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:23:04 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>

Ok, I thought I understood this, but now I'm not sure.

I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.

I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle

Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.

Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\m3core
                package C:\cm3\Sandbox\m3-libs\libm3
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle
                package C:\cm3\Sandbox\m3-sys\mklib

The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Q1:  So, am I to infer that in the process of "bootstrapping" a new compiler using an old one, that you have to leave out "m3core" and "libm3" on the first pass, or is there some other logic going on here?

Q2:  Next, if "m3staloneback" and "m3bundle" are needed, shouldn't they be listed as part of the "front" group in pkginfo.txt?

Regards,
Randy Coleburn

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

From hosking at cs.purdue.edu  Wed Jan 13 03:30:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:30:49 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>

On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:

> Ok, I thought I understood this, but now I?m not sure.
>  
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay?s upgrade.py to see what it does.
>  
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>  
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>  
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
>  
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>  
> Q1:  So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?

It has to do with bootstrapping the compiler to implement feature FOO.  Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries.  First you build a compiler that can compiler FOO (using the old libraries).  Then you make the FOO change to the libraries, and recompile the compiler against the new libraries.  Now both libraries and compiler are FOO-capable.  Carry on...

> Q2:  Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?

They aren't actually needed here.  Not sure why they are included.  Nor is import-libs unless on Windows perhaps.

>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/897e86ba/attachment.html>

From jay.krell at cornell.edu  Wed Jan 13 03:57:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 02:57:07 +0000
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>,
	<2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
Message-ID: <COL101-W132DFD4126C48933CFAA6DE66B0@phx.gbl>


m3stalonebak I think is never used, agreed.
m3bundle I don't remember why I put it there.
 
 
  Probably because in upgrade.sh or such, there was logic like if m3bundle not found in path, build it fairly early. Something like that. A lot of this is based on what the *.sh files did/do, though there is also divergence/improvement/regression.
  - The *.sh files accept additional cm3 parameters, *.py not yet.
  - The *.sh files read pkginfo.txt, which I was a vocal proponent of and implemented mostly. The *.py not yet (yeah yeah, I'm a hypocrite.)
(*.py is still arguably better than the older *.sh here, in that the data drivenness of it has less redundancy, e.g. the ordering is only present once).
 
 
import-libs is "self filtering", building it does nothing, successfully, for other targets.
 
 
Agreed.
There is are unavoidable circularities.
 
 
Historically there was also a problem with adding new targets.
If libm3 "knew" about a different list of targets than cm3, then cm3 couldn't build it. Maybe similar with m3core but I think not.
So you had to avoid using your pre-existing cm3 to build a current libm3.
First build cm3, then libm3.
That problem is gone now.
What libm3 actually I think "knew" about was more like the hash ("fingerprint") of an enum that listed all targets, which is about the same as having an exact list (few collisions that aren't also exact matches). Anyway, the list is gone.
 
 
But the circularities are and still can be present.
m3core/libm3 use LONGINT for example, so a sufficiently old cm3 can't compile them.
 
 
This is the nature of writing a system in itself.
Definitely a worthwhile tradeoff.
:)
 
 
 - Jay




________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:30:49 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] two questions on bootstrapping the compiler
>
>
>
> On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:
>
> Ok, I thought I understood this, but now I?m not sure.
>
> I had trouble rebuilding everything due to the recent changes. So, I ran Jay?s upgrade.py to see what it does.
>
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
>
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\m3core
> package C:\cm3\Sandbox\m3-libs\libm3
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
> package C:\cm3\Sandbox\m3-sys\mklib
>
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>
> Q1: So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?
>
> It has to do with bootstrapping the compiler to implement feature FOO. Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries. First you build a compiler that can compiler FOO (using the old libraries). Then you make the FOO change to the libraries, and recompile the compiler against the new libraries. Now both libraries and compiler are FOO-capable. Carry on...
>
> Q2: Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?
>
> They aren't actually needed here. Not sure why they are included. Nor is import-libs unless on Windows perhaps.
>
>
> Regards,
> Randy Coleburn
>
> 		 	   		  

From rcolebur at SCIRES.COM  Wed Jan 13 03:57:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:57:02 -0500
Subject: [M3devel] LONGINT on NT386
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>

Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?

I ask, because currently on Windows, LONGINT has same range as INTEGER.

Is there anything I can do to help?

BYTESIZE(INTEGER) =4
BYTESIZE(CARDINAL)=4
BYTESIZE(LONGINT) =4

FIRST(INTEGER) =-2147483648
LAST (INTEGER) = 2147483647

FIRST(CARDINAL)=0
LAST (CARDINAL)=2147483647

FIRST(LONGINT) =-2147483648
LAST (LONGINT) = 2147483647

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/9c6de4be/attachment.html>

From jay.krell at cornell.edu  Wed Jan 13 04:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:08:47 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
Message-ID: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>


If isn't needed for safety, then I agree.
I really thought it was needed for safety.
But I do not "argue" that that is true.
I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
 
 
That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
This is a common problem. There are several solutions all with tradeoffs.
It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
I tend to think type/interface are the best options.
 
 
INTERFACE IntegerOverflowOut;
 
 
(* maybe UNTRACED REF := NIL for "compatibility" *)
 
PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;

PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
 
 
INTERFACE IntegerOverflowRaises;
 
EXCEPTION Error;
 
PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
 
 
INTERFACE IntegerOverflowSilent;
 
 
PROCEDURE Add(a,b: INTEGER): INTEGER;
PROCEDURE Sub(a,b: INTEGER): INTEGER;
PROCEDURE Mult(a,b: INTEGER): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT;
PROCEDURE SubLong(a,b: LONGINT): LONGINT;
PROCEDURE MultLong(a,b: LONGINT): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
 
 
Notice how two of the interfaces are "source compatible" and allow
easy switching between them for testing/investigation.
That might be deemed a feature, and provided somehow across all three.
 
 
Is anyone strongly opposed to providing something *like* these in m3core?
Maybe inlined by the compiler?
 
 
You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
 
And sometimes not.
 
 
 - Jay



----------------------------------------
> Subject: Re: [M3devel] integer overflow and for loops
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:18:59 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 04:27:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:27:05 +0000
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>


It's not easy to fix.
I386_MINGWIN is the easiest way actually..
I'll look at it again soon..
Maybe we should have an option where the front end decomposes things?
Or makes function calls?
That is probably a pleasantly nice option.
 
 
 - Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 21:57:02 -0500
> Subject: [M3devel] LONGINT on NT386
>
>
> Ok, so now that we have this LONGINT type, what else needs
> to take place for it to be useful?
>
> I ask, because currently on Windows, LONGINT has same range
> as INTEGER.
>
>
> Is there anything I can do to help?
>
>
>
>
>
>
>
> BYTESIZE(INTEGER) =4
>
> BYTESIZE(CARDINAL)=4
>
> BYTESIZE(LONGINT) =4
>
>
>
> FIRST(INTEGER) =-2147483648
>
> LAST (INTEGER) = 2147483647
>
>
>
> FIRST(CARDINAL)=0
>
> LAST (CARDINAL)=2147483647
>
>
>
> FIRST(LONGINT) =-2147483648
>
> LAST (LONGINT) = 2147483647
>
>
>
>
>
>
>
> Regards,
>
>
>
> Randy Coleburn
>
> 		 	   		  

From roland.illig at gmx.de  Wed Jan 13 08:33:46 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Wed, 13 Jan 2010 08:33:46 +0100
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <4B4D775A.9040603@gmx.de>

Jay K schrieb:
> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

My main point in that article was not the integer overflow but the fact 
of having an ugly sentence like "don't use the FOR loop for large 
numbers" in the language definition. Additionally, one would not expect 
the FOR loop to loop endlessly. These are the things I wanted to fix 
back then.

Roland


From wagner at elegosoft.com  Wed Jan 13 10:43:03 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 13 Jan 2010 10:43:03 +0100
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
Message-ID: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>
>>  Also, in case anyone is interested, the current HEAD fails to   
>> compile the following packages on Windows Vista:
>> "m3-libs\m3core"
>> "m3-libs\libm3"
>> "m3-tools\m3tk"
>> So some recent changes have caused a problem.
>
> Did you bootstrap a new compiler?  You will need to bootstrap a   
> compiler before you can compile the revised ORD/VAL definitions.

So if I understand this correctly, should we finally get to release
5.8, then this compiler won't be able to compile the current trunk
head? That is, not unless we merge this change to the release branch?

Anything else that we should do for 5.8?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed Jan 13 15:25:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:25:14 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <20100113142513.GA25925@topoi.pooq.com>

On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
>  
>  
> INTERFACE IntegerOverflowOut;

While we're at it, should there be a carry out as well?

-- hendrik



From hendrik at topoi.pooq.com  Wed Jan 13 15:32:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:32:32 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100113143232.GB25925@topoi.pooq.com>

On Tue, Jan 12, 2010 at 09:23:04PM -0500, Coleburn, Randy wrote:
> Ok, I thought I understood this, but now I'm not sure.
> 
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.
> 
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
> 
> Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.
> 
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
> 
> The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Also "mklib".

-- hendrik


From hosking at cs.purdue.edu  Wed Jan 13 16:09:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:01 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <8E064BBE-460E-45AE-B08A-82B8AA6A5B16@cs.purdue.edu>

That's because the integrated backed on Windows doesn't currently support LONGINT.  Someone needs to smarten up the code generator to cope with LONGINT.

On 12 Jan 2010, at 21:57, Coleburn, Randy wrote:

> Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?
>  
> I ask, because currently on Windows, LONGINT has same range as INTEGER.
>  
> Is there anything I can do to help?
>  
> BYTESIZE(INTEGER) =4
> BYTESIZE(CARDINAL)=4
> BYTESIZE(LONGINT) =4
> 
> FIRST(INTEGER) =-2147483648
> LAST (INTEGER) = 2147483647
> 
> FIRST(CARDINAL)=0
> LAST (CARDINAL)=2147483647
> 
> FIRST(LONGINT) =-2147483648
> LAST (LONGINT) = 2147483647
>  
> Regards,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/4d5a20cb/attachment.html>

From hosking at cs.purdue.edu  Wed Jan 13 16:09:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:59 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
Message-ID: <831906E2-A122-4C17-BA03-C0101F4DFE85@cs.purdue.edu>

On 12 Jan 2010, at 22:27, Jay K wrote:

> It's not easy to fix.
> I386_MINGWIN is the easiest way actually..
> I'll look at it again soon..
> Maybe we should have an option where the front end decomposes things?

It is the job of the backend to map to machine types.  Don't go complicating the front-end unnecessarily: compiler design 101.

> Or makes function calls?
> That is probably a pleasantly nice option.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Tue, 12 Jan 2010 21:57:02 -0500
>> Subject: [M3devel] LONGINT on NT386
>> 
>> 
>> Ok, so now that we have this LONGINT type, what else needs
>> to take place for it to be useful?
>> 
>> I ask, because currently on Windows, LONGINT has same range
>> as INTEGER.
>> 
>> 
>> Is there anything I can do to help?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> BYTESIZE(INTEGER) =4
>> 
>> BYTESIZE(CARDINAL)=4
>> 
>> BYTESIZE(LONGINT) =4
>> 
>> 
>> 
>> FIRST(INTEGER) =-2147483648
>> 
>> LAST (INTEGER) = 2147483647
>> 
>> 
>> 
>> FIRST(CARDINAL)=0
>> 
>> LAST (CARDINAL)=2147483647
>> 
>> 
>> 
>> FIRST(LONGINT) =-2147483648
>> 
>> LAST (LONGINT) = 2147483647
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Randy Coleburn
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:14:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:14:52 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <2227245F-1770-4D86-B74A-CEBDA15FCB2D@cs.purdue.edu>

On 13 Jan 2010, at 04:43, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>> 
>>> Also, in case anyone is interested, the current HEAD fails to  compile the following packages on Windows Vista:
>>> "m3-libs\m3core"
>>> "m3-libs\libm3"
>>> "m3-tools\m3tk"
>>> So some recent changes have caused a problem.
>> 
>> Did you bootstrap a new compiler?  You will need to bootstrap a  compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?

Correct.  I suggest we merge the changes to avoid inconsistency.  This will be the first official release with LONGINT in it so let's make sure we make it right before anyone starts actually using it...

> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Wed Jan 13 16:40:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:40:20 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>

I really don't think an interface should support overflow checks for unsigned types.  We have Word.T and Long.T with their current semantics.  To be honest I don't think this is really a high priority right now.

I do have another suggestion for where to direct your energies.  :-)  What about going back to smartening up the integrated backend to generate LONGINT properly on Windows?  As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end.  Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html

We only need the following:

Load Relaxed:  MOV (from memory)
Load Acquire:  MOV (from memory)
Load Seq_Cst:  LOCK XADD(0) // alternative: MFENCE,MOV (from memory)

Store Relaxed: MOV (into memory)
Store Release: MOV (into memory)
Store Seq Cst: LOCK XCHG    // alternative: MOV (into memory),MFENCE

Acquire Fence: <ignore>
Release Fence: <ignore>
Acq_Rel Fence: <ignore>
Seq_Cst Fence: MFENCE

Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).

One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable.  The ops as currently defined do not take an offset.  This would permit more efficient addressing modes for the instructions just like regular loads/stores.

On 12 Jan 2010, at 22:08, Jay K wrote:

> 
> If isn't needed for safety, then I agree.
> I really thought it was needed for safety.
> But I do not "argue" that that is true.
> I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> 
> 
> That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> This is a common problem. There are several solutions all with tradeoffs.
> It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> I tend to think type/interface are the best options.
> 
> 
> INTERFACE IntegerOverflowOut;
> 
> 
> (* maybe UNTRACED REF := NIL for "compatibility" *)
> 
> PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> 
> 
> INTERFACE IntegerOverflowRaises;
> 
> EXCEPTION Error;
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> 
> 
> INTERFACE IntegerOverflowSilent;
> 
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER;
> PROCEDURE Sub(a,b: INTEGER): INTEGER;
> PROCEDURE Mult(a,b: INTEGER): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> 
> 
> Notice how two of the interfaces are "source compatible" and allow
> easy switching between them for testing/investigation.
> That might be deemed a feature, and provided somehow across all three.
> 
> 
> Is anyone strongly opposed to providing something *like* these in m3core?
> Maybe inlined by the compiler?
> 
> 
> You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> 
> And sometimes not.
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] integer overflow and for loops
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 21:18:59 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>> 
>> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:47:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:47:19 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <4B4D775A.9040603@gmx.de>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>
Message-ID: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> 
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
> 
> Roland



From rcolebur at SCIRES.COM  Wed Jan 13 17:41:44 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 11:41:44 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>,
	<F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD7F1902@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland

From rcolebur at SCIRES.COM  Wed Jan 13 19:00:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 13:00:02 -0500
Subject: [M3devel] integer overflow and for loops
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E412@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland


From jay.krell at cornell.edu  Wed Jan 13 22:39:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:39:34 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
Message-ID: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>


Agreed. I might have more a clue this time around for LONGINT/NT386.

I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:

    last_imm   : INTEGER := 0;
    lowbound   : INTEGER := FIRST (INTEGER);
    upbound    : INTEGER := LAST (INTEGER);


Something is bugging me a bit though.

Is TInt also used to hold LONGINT values for 32bit targets?

 

I'll look into the atomics too.

It's easy, because in particular, we can just be overly strict on the memory model.

Boehm's prototype already is -- using full barriers where only release/acquire is called for.

 

mfence is a "relatively new" instruction. We are ok with that?

 

I'll try to report back later about the offset question.

I'll compile some C examples and see what addressing modes get used. :)

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 10:40:20 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> 
> I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> 
> We only need the following:
> 
> Load Relaxed: MOV (from memory)
> Load Acquire: MOV (from memory)
> Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> 
> Store Relaxed: MOV (into memory)
> Store Release: MOV (into memory)
> Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> 
> Acquire Fence: <ignore>
> Release Fence: <ignore>
> Acq_Rel Fence: <ignore>
> Seq_Cst Fence: MFENCE
> 
> Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> 
> One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> 
> On 12 Jan 2010, at 22:08, Jay K wrote:
> 
> > 
> > If isn't needed for safety, then I agree.
> > I really thought it was needed for safety.
> > But I do not "argue" that that is true.
> > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > 
> > 
> > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > This is a common problem. There are several solutions all with tradeoffs.
> > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > I tend to think type/interface are the best options.
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> > 
> > 
> > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > 
> > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > 
> > 
> > INTERFACE IntegerOverflowRaises;
> > 
> > EXCEPTION Error;
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > 
> > 
> > INTERFACE IntegerOverflowSilent;
> > 
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > 
> > 
> > Notice how two of the interfaces are "source compatible" and allow
> > easy switching between them for testing/investigation.
> > That might be deemed a feature, and provided somehow across all three.
> > 
> > 
> > Is anyone strongly opposed to providing something *like* these in m3core?
> > Maybe inlined by the compiler?
> > 
> > 
> > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > 
> > And sometimes not.
> > 
> > 
> > - Jay
> > 
> > 
> > 
> > ----------------------------------------
> >> Subject: Re: [M3devel] integer overflow and for loops
> >> From: hosking at cs.purdue.edu
> >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> >> CC: m3devel at elegosoft.com
> >> To: jay.krell at cornell.edu
> >> 
> >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> >> 
> >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/456d6837/attachment.html>

From jay.krell at cornell.edu  Wed Jan 13 22:45:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:45:17 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>


Yes and no. I was thinking about this too.

In general this "race" never ends.

However:

  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"

   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

 

  - the "race" should actually "slow down" now that I fixed the platform list problem :)

     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use

     (to be clear, the "front" group needs to be more careful about using more features;

     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

 

 

If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.

They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/b0ca354d/attachment.html>

From hosking at cs.purdue.edu  Wed Jan 13 22:53:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 16:53:19 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
Message-ID: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>

On 13 Jan 2010, at 16:45, Jay K wrote:

> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

We should merge head back to release for LONGINT as it is now (more consistently) implemented.

>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.

I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.

>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

That would be good too.

>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/45b4c7b7/attachment.html>

From jay.krell at cornell.edu  Wed Jan 13 22:58:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:58:55 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <20100113142513.GA25925@topoi.pooq.com>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<20100113142513.GA25925@topoi.pooq.com>
Message-ID: <COL101-W5136334F62E4E28C53D39BE66B0@phx.gbl>


I believe it is the same thing. As long as you still compute the lower bits correctly.

There should also be carry in.

And check if the arithmetic library doesn't already provide this stuff.

 

 

You might also provide a library, where, at least for add/sub, signed and unsigned

operations are merged but two extra bits are output: "signed overflow" and "unsigned overflow".

Probably all processors do that in one add/sub instruction that produces at least

2 status flags.

"signed overflow" is the "second to last carry bit" as I recall.

"unsigned overflow" is merely the "last carry bit".

 

 

Another way to look at it is that there is signed overflow if there was

carry into the sign bit.

 

 

Another implementation choice is what lower bits to return if there is overflow.

I had a "new idea" that you might as well just always use the direct

implementation to compute the lower bits. It's a little extra work

in the highest precision multiplication case but probably ok.

That is -- look at hand.c, how m3_mult_u64 throws away the

result of the last m3_add_u64.

 

Someone should also write a bunch of code with these things and then

argue for operator overloading in the language. :)

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 09:25:14 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> 
> While we're at it, should there be a carry out as well?
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/1cc7e05e/attachment.html>

From jay.krell at cornell.edu  Wed Jan 13 23:39:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 22:39:53 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>


Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

I kind of think Target.Int should remain being implemented as an array of 8 bit integers.

That preserves flexibility of targeting basically "anything from anything".

 

 

Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.

  Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.

 

 

As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

I think it's a pretty simple fix.

 

 

There is still a bug targeting 64bit from 32bit because of this.

The attempts to declare "maximally sized arrays" fails.

m3core has a hack where it uses 2GB or 4GB instead of the real max.

The "jvideo" package still fails to cross compile.

 

 

 - Jay
 


Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
From: hosking at cs.purdue.edu
Date: Wed, 13 Jan 2010 16:53:19 -0500
CC: wagner at elegosoft.com; m3devel at elegosoft.com
To: jay.krell at cornell.edu




On 13 Jan 2010, at 16:45, Jay K wrote:


Yes and no. I was thinking about this too.
In general this "race" never ends.
However:
  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)



We should merge head back to release for LONGINT as it is now (more consistently) implemented.


  - the "race" should actually "slow down" now that I fixed the platform list problem :)
     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
     (to be clear, the "front" group needs to be more careful about using more features;
     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).



Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.


I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.


 If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).



That would be good too.


 
 
 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Thu Jan 14 02:05:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:05:10 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
	<COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
Message-ID: <D3FCB564-EA7A-441C-B5E7-1DAEB00CDA77@cs.purdue.edu>

On 13 Jan 2010, at 16:39, Jay K wrote:

> Agreed. I might have more a clue this time around for LONGINT/NT386.
> I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:
>     last_imm   : INTEGER := 0;
>     lowbound   : INTEGER := FIRST (INTEGER);
>     upbound    : INTEGER := LAST (INTEGER);
> 
> Something is bugging me a bit though.
> Is TInt also used to hold LONGINT values for 32bit targets?

Yes, but the range is dictated by the n field of TInt.  So, you'd need to have 8-byte TInt for 64-bit LONGINT.

>  I'll look into the atomics too.
> It's easy, because in particular, we can just be overly strict on the memory model.

Correct: x86 is closest to SC.

> Boehm's prototype already is -- using full barriers where only release/acquire is called for.

Right.

>  mfence is a "relatively new" instruction. We are ok with that?

Our targets that support this should probably be equivalent of "-arch i686" (gcc flag) and above.  Notice that targets can always revert to locks to implement things.

>  I'll try to report back later about the offset question.
> I'll compile some C examples and see what addressing modes get used. :)

:-)

>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Wed, 13 Jan 2010 10:40:20 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] integer overflow and for loops
> > 
> > I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> > 
> > I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64:http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> > 
> > We only need the following:
> > 
> > Load Relaxed: MOV (from memory)
> > Load Acquire: MOV (from memory)
> > Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> > 
> > Store Relaxed: MOV (into memory)
> > Store Release: MOV (into memory)
> > Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> > 
> > Acquire Fence: <ignore>
> > Release Fence: <ignore>
> > Acq_Rel Fence: <ignore>
> > Seq_Cst Fence: MFENCE
> > 
> > Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> > 
> > One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> > 
> > On 12 Jan 2010, at 22:08, Jay K wrote:
> > 
> > > 
> > > If isn't needed for safety, then I agree.
> > > I really thought it was needed for safety.
> > > But I do not "argue" that that is true.
> > > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > > 
> > > 
> > > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > > This is a common problem. There are several solutions all with tradeoffs.
> > > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > > I tend to think type/interface are the best options.
> > > 
> > > 
> > > INTERFACE IntegerOverflowOut;
> > > 
> > > 
> > > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > > 
> > > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > 
> > > 
> > > INTERFACE IntegerOverflowRaises;
> > > 
> > > EXCEPTION Error;
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > 
> > > 
> > > INTERFACE IntegerOverflowSilent;
> > > 
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > > 
> > > 
> > > Notice how two of the interfaces are "source compatible" and allow
> > > easy switching between them for testing/investigation.
> > > That might be deemed a feature, and provided somehow across all three.
> > > 
> > > 
> > > Is anyone strongly opposed to providing something *like* these in m3core?
> > > Maybe inlined by the compiler?
> > > 
> > > 
> > > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > > 
> > > And sometimes not.
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > > ----------------------------------------
> > >> Subject: Re: [M3devel] integer overflow and for loops
> > >> From: hosking at cs.purdue.edu
> > >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> > >> CC: m3devel at elegosoft.com
> > >> To: jay.krell at cornell.edu
> > >> 
> > >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> > >> 
> > >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> > >> 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/7be48d81/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 14 02:35:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:35:45 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
Message-ID: <2ED96294-8D8F-4F73-8B5E-C7EA588D5A85@cs.purdue.edu>

On 13 Jan 2010, at 17:39, Jay K wrote:

> Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

It's a possibility except for overflow checks, etc. on compile-time constant folding, so perhaps not.

> I kind of think Target.Int should remain being implemented as an array of 8 bit integers.
> That preserves flexibility of targeting basically "anything from anything".

True, I guess not.

>  Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.
>   Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.
>  
>  
> As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

They should always be representable as INTEGER, no?

> I think it's a pretty simple fix.
>  
>  
> There is still a bug targeting 64bit from 32bit because of this.
> The attempts to declare "maximally sized arrays" fails.

Oh, yes, now I get you.

> m3core has a hack where it uses 2GB or 4GB instead of the real max.
> The "jvideo" package still fails to cross compile.


RIght.

>  
>  
>  - Jay
>  
> Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 16:53:19 -0500
> CC: wagner at elegosoft.com; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> On 13 Jan 2010, at 16:45, Jay K wrote:
> 
> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)
> 
> We should merge head back to release for LONGINT as it is now (more consistently) implemented.
> 
>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).
> 
> Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.
> 
> I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.
> 
>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).
> 
> That would be good too.
> 
>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/4c9ba8a4/attachment.html>

From jay.krell at cornell.edu  Thu Jan 14 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 10:23:24 +0000
Subject: [M3devel] merging head m3front to release
Message-ID: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>


 > merging head m3front to release

 

The changes are big and I don't understand them right away.

Just do a wholesale copy?

(and remember related changes to m3tk and m3core)

 

A parameter got renamed lhs => traced or vice versa 

through a lot of the code, but not always. And the value

of it sometimes changed but not always.

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/28a3e89f/attachment.html>

From wagner at elegosoft.com  Thu Jan 14 11:56:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Jan 2010 11:56:49 +0100
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 13 Jan 2010, at 16:45, Jay K wrote:
>
>> Yes and no. I was thinking about this too.
>> In general this "race" never ends.
>> However:
>>   - right this is first release with LONGINT, and I think there are  
>>  incompatibilities between head and release esp. wrt "ORD"
>>    (Had we added e.g. "assignability" and release was just a   
>> compatible subset, different; I think it is actually "incompatible".)
>
> We should merge head back to release for LONGINT as it is now (more   
> consistently) implemented.
>
>>   - the "race" should actually "slow down" now that I fixed the   
>> platform list problem :)
>>      but still, the "race" isn't guaranteeably gone; there might   
>> still be new language features that m3core/libm3 use
>>      (to be clear, the "front" group needs to be more careful about  
>>  using more features;
>>      for example, it would be "useful" for me to use LONGINT in   
>> m3back, and then build a non-NT386 hosted compiler, in order to get  
>>  LONGINT support into NT386, however my preference at the moment is  
>>  to use Target.Int to "simulate" 64bit arithmetic in the compiler   
>> ("constant folding" and such, as it already does for 32bit   
>> integers); the compiler basically supports targeting 32bit INTEGER   
>> even on a host with only 8 or 16bit INTEGER, as I understand).
>
> Yes, I could have made use of LONGINT but didn't so as to retain   
> cross-compilation from short to long LONGINT platforms.
>
> I don't understand what you are saying about needing to simulate   
> 64-bit arithmetic.  We can do that already.  I don't think the   
> compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be   
> surprised if that actually works.
>
>>  If I or anyone checks that the exception is gone now in GUI file   
>> open dialog, maybe merge those changes too.
>> They are pretty small. I haven't touched rd/wr yet (well, they were  
>>  touched *slightly*).
>
> That would be good too.

Can one of you please do the necessary merges? I had a quick look,
but there were too many commits to find the relevant things quickly.

We should try to be selective and not merge just everything though;
CVS needs two labels or dates to do those three point merges
(cvs update -j -r rev1 -r rev2; build; cvs commit).

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Jan 14 13:36:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100114123342.98F412474001@birch.elegosoft.com>
References: <20100114123342.98F412474001@birch.elegosoft.com>
Message-ID: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>


In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..

 

 

 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0003.txt>

From jay.krell at cornell.edu  Thu Jan 14 13:37:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:37:45 +0000
Subject: [M3devel] longint changes to release branch
In-Reply-To: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
References: <20100114123342.98F412474001@birch.elegosoft.com>,
	<COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
Message-ID: <COL101-W251E60863732D724E2A93EE66A0@phx.gbl>


Also, I'm slightly guessing here as to what should go to release.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3commit at elegosoft.com; m3devel at elegosoft.com
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: Re: [M3devel] [M3commit] CVS Update: cm3



In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..
 
 
 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/8b1d6459/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 14 14:44:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:44:54 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
Message-ID: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>

On 14 Jan 2010, at 05:23, Jay K wrote:

>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.

That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).

I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/348e9b5c/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 14 14:45:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:45:27 -0500
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
Message-ID: <9EF41FDC-DF20-4024-99FC-ADCA6CE44BAC@cs.purdue.edu>

I won't have time for it for at least 2 weeks.

On 14 Jan 2010, at 05:56, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 13 Jan 2010, at 16:45, Jay K wrote:
>> 
>>> Yes and no. I was thinking about this too.
>>> In general this "race" never ends.
>>> However:
>>>  - right this is first release with LONGINT, and I think there are  incompatibilities between head and release esp. wrt "ORD"
>>>   (Had we added e.g. "assignability" and release was just a  compatible subset, different; I think it is actually "incompatible".)
>> 
>> We should merge head back to release for LONGINT as it is now (more  consistently) implemented.
>> 
>>>  - the "race" should actually "slow down" now that I fixed the  platform list problem :)
>>>     but still, the "race" isn't guaranteeably gone; there might  still be new language features that m3core/libm3 use
>>>     (to be clear, the "front" group needs to be more careful about  using more features;
>>>     for example, it would be "useful" for me to use LONGINT in  m3back, and then build a non-NT386 hosted compiler, in order to get  LONGINT support into NT386, however my preference at the moment is  to use Target.Int to "simulate" 64bit arithmetic in the compiler  ("constant folding" and such, as it already does for 32bit  integers); the compiler basically supports targeting 32bit INTEGER  even on a host with only 8 or 16bit INTEGER, as I understand).
>> 
>> Yes, I could have made use of LONGINT but didn't so as to retain  cross-compilation from short to long LONGINT platforms.
>> 
>> I don't understand what you are saying about needing to simulate  64-bit arithmetic.  We can do that already.  I don't think the  compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be  surprised if that actually works.
>> 
>>> If I or anyone checks that the exception is gone now in GUI file  open dialog, maybe merge those changes too.
>>> They are pretty small. I haven't touched rd/wr yet (well, they were  touched *slightly*).
>> 
>> That would be good too.
> 
> Can one of you please do the necessary merges? I had a quick look,
> but there were too many commits to find the relevant things quickly.
> 
> We should try to be selective and not merge just everything though;
> CVS needs two labels or dates to do those three point merges
> (cvs update -j -r rev1 -r rev2; build; cvs commit).
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/3be3eafd/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 14 18:40:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 12:40:32 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
Message-ID: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 12:14, Tony Hosking wrote:

> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all

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

From rcolebur at SCIRES.COM  Thu Jan 14 20:34:24 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 14:34:24 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>

No, the only scripts I've changed are mine in scripts/dev/windows.  These don't have anything to do with Tinderbox.
Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484





On 14 Jan 2010, at 12:14, Tony Hosking wrote:


Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all

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

From hosking at cs.purdue.edu  Thu Jan 14 20:57:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 14:57:15 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>

Hmm.  The only other commits I've seen are Jay's.  Jay?

On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:

> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>  
> 
> 
>  
>  
> On 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/0b0d827a/attachment.html>

From jay.krell at cornell.edu  Thu Jan 14 23:09:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:09:17 +0000
Subject: [M3devel] initializing Target.Int
In-Reply-To: <20100114135750.080852474001@birch.elegosoft.com>
References: <20100114135750.080852474001@birch.elegosoft.com>
Message-ID: <COL101-W65F274A88DB4C659B147C3E66A0@phx.gbl>


Uninitialized seems pretty much always bad.

n := 0 appears to be illegal.

 

 - Jay

 
> Date: Thu, 14 Jan 2010 14:57:50 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/14 14:57:49
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.i3 
> 
> Log message:
> This is deliberately uninitialised!
> It defaults to 0 anyway.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/afde87e9/attachment.html>

From jay.krell at cornell.edu  Thu Jan 14 23:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:21:43 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
Message-ID: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>


"lastok" of the release branch, which this appears to be, was expected to fail.
(and for head was expected a few days ago)

Previous compiler can't build m3core.

Must first build compiler, then m3core.

The usual occasional problem.

 

  - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 14:57:15 -0500
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Output from "cron" command

Hmm.  The only other commits I've seen are Jay's.  Jay?




On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:



No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
Regards,
Randy
 


From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command
 
Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

 

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

 

Randy/Jay, did you change something related to this?

 



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 14 Jan 2010, at 12:14, Tony Hosking wrote:




Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f6fcf293/attachment.html>

From jay.krell at cornell.edu  Thu Jan 14 23:28:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:28:33 +0000
Subject: [M3devel] merging head m3front to release
In-Reply-To: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
Message-ID: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>


If it's just a wholesale copy, I can do that fairly easily/quickly/soon.

  Anyone can.

You are certain a wholesale copy, of all of m3front? Final answer?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 08:44:54 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] merging head m3front to release




On 14 Jan 2010, at 05:23, Jay K wrote:


 > merging head m3front to release
 
The changes are big and I don't understand them right away.
Just do a wholesale copy?
(and remember related changes to m3tk and m3core)
 
A parameter got renamed lhs => traced or vice versa 
through a lot of the code, but not always. And the value
of it sometimes changed but not always.



That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).


I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/990dc763/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 00:22:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:22:03 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
	<COL101-W39241284420296C5E5118FE66A0@phx.gbl>
Message-ID: <E9ED6716-3CCB-4DF3-B25E-D34DF4097E16@cs.purdue.edu>

Yes.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:28, Jay K wrote:

> If it's just a wholesale copy, I can do that fairly easily/quickly/soon.
>   Anyone can.
> You are certain a wholesale copy, of all of m3front? Final answer?
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 08:44:54 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] merging head m3front to release
> 
> On 14 Jan 2010, at 05:23, Jay K wrote:
> 
>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.
> 
> That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).
> 
> I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
> Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/61d5c355/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 00:24:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:24:06 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>

I'm not sure what that implies...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:21, Jay K wrote:

> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>  
>   - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Hmm.  The only other commits I've seen are Jay's.  Jay?
> 
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> 
> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/17d1ca27/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 00:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 23:58:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
Message-ID: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Fri Jan 15 02:10:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 01:10:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <COL101-W25419C91933D529A477126E6690@phx.gbl>


> What should always work actually..
 
Except that I've seen "blessed" in our Hudson process
a cm3 that just always crashes.
It happened multiple times on my SOLgnu/SOLsun machine.
I had to delete a bunch of cm3 and go back to an older one.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:58:33 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
> Tony you know all this.
> This email is redundant for you.
>
>
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>
>
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
>
>
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>
>
> If this works, its cm3 output can be "blessed" as "something".
>
>
>
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>
>
> Again the output can be "blessed" as "something".
>
>
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>
>
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>
>
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>
>
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>
>
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>
>
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>
>
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>
>
> - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>>
>> I'm not sure what that implies...
>>
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>>
>>
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>>
>> - Jay
>>
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Hmm. The only other commits I've seen are Jay's. Jay?
>>
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>
>> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
>> Regards,
>> Randy
>>
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>
>> Randy/Jay, did you change something related to this?
>>
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>
>>
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>>
>> produced the following output:
>>
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>>
>>
>>
>> 		 	   		  

From rcolebur at SCIRES.COM  Fri Jan 15 05:45:50 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 23:45:50 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, ,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>

Jay / Tony:

I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".

RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".

Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".

RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
1.  Copies some of the other scripts and documentation I use to the "bin" folder.
2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
4.  Stage-2:  Builds and ships all packages in the "front" group.
5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.

Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?

Regards,
Randy Coleburn

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, January 14, 2010 6:59 PM
To: Tony
Cc: m3devel
Subject: Re: [M3devel] Output from "cron" command


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  


From hosking at cs.purdue.edu  Fri Jan 15 05:49:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 23:49:18 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>

I think so.  Jay can comment more accurately re Windows.

On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:

> Jay / Tony:
> 
> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
> 
> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
> 
> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".
> 
> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
> 1.  Copies some of the other scripts and documentation I use to the "bin" folder.
> 2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
> 3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
> 4.  Stage-2:  Builds and ships all packages in the "front" group.
> 5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
> 
> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Thursday, January 14, 2010 6:59 PM
> To: Tony
> Cc: m3devel
> Subject: Re: [M3devel] Output from "cron" command
> 
> 
> Tony you know all this.
> This email is redundant for you.
> 
> 
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
> 
> 
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
> 
> 
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
> 
> 
> If this works, its cm3 output can be "blessed" as "something".
> 
> 
> 
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
> 
> 
> Again the output can be "blessed" as "something".
> 
> 
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
> 
> 
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
> 
> 
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
> 
> 
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
> 
> 
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
> 
> 
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
> 
> 
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> 
>> 
>> I'm not sure what that implies...
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>> 
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>> 
>> - Jay
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Hmm. The only other commits I've seen are Jay's. Jay?
>> 
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>> 
>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>> Regards,
>> Randy
>> 
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>> 
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>> 
>> Randy/Jay, did you change something related to this?
>> 
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>> 
>> 
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>> 
>> produced the following output:
>> 
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>> 
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>> 
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Fri Jan 15 07:07:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 06:07:56 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>,
	<D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
Message-ID: <COL101-W18358BFDB1FF6BCB94C49DE6690@phx.gbl>


Not quite. shipping cm3 doesn't put it in the right place, so you have to "manually" copy it.
 
 
At some point I'd like to see about making that work better
but it isn't high priority.
 
 
In particular, on Windows you can rename away an in-use .exe/.dll and then copy over.
 
 
But I think I've seen the behavior on other systems that replacing in-use executables/.so files causes a "random" mix of in-memory code/data and crashes. (And I know Windows is usually criticized for not letting you replace "running code", but the reality is more lenient than people realize, the reality of allowing such things is far more complicated than people realize (how do I ensure the old version eventually is not used?) and I believe other systems have similar or more stringent restrictions, e.g. AIX).
 
 
We should probably make shipping in cminstall put the configuration files in place or somesuch, instead of leaving it to all the scripts.
There is a tension in that programming in Python being much easier and more pleasant than any of the alternatives such as Modula-3 or Quake..
 
 
Anyway, I just use the *.py files, on Linux, Darwin, NT, OpenBSD, FreeBSD, NetBSD, Solaris, etc. (MIPS64_OPENBSD so far I don't have Python for, it's like the only one).
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:49:18 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] Output from "cron" command
>
> I think so. Jay can comment more accurately re Windows.
>
> On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:
>
>> Jay / Tony:
>>
>> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
>>
>> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
>>
>> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file. It depends on "pkgInfo.txt".
>>
>> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
>> 1. Copies some of the other scripts and documentation I use to the "bin" folder.
>> 2. Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
>> 3. Stage-1: Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
>> 4. Stage-2: Builds and ships all packages in the "front" group.
>> 5. Stage-3: Builds and ships a distribution. Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
>>
>> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
>>
>> Regards,
>> Randy Coleburn
>>
>> -----Original Message-----
>> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
>> Sent: Thursday, January 14, 2010 6:59 PM
>> To: Tony
>> Cc: m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>> Tony you know all this.
>> This email is redundant for you.
>>
>>
>> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>>
>>
>> We have as I understand "pairs" of automated builds.
>> Though actually more than two could make sense.
>>
>>
>> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>>
>>
>> If this works, its cm3 output can be "blessed" as "something".
>>
>>
>>
>> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>>
>>
>> Again the output can be "blessed" as "something".
>>
>>
>> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>>
>>
>> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>>
>>
>> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>>
>>
>> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>>
>>
>> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>>
>>
>> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>>
>>
>> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>>
>>>
>>> I'm not sure what that implies...
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>>
>>> "lastok" of the release branch, which this appears to be, was expected to fail.
>>> (and for head was expected a few days ago)
>>> Previous compiler can't build m3core.
>>> Must first build compiler, then m3core.
>>> The usual occasional problem.
>>>
>>> - Jay
>>>
>>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>>> To: rcolebur at SCIRES.COM
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Hmm. The only other commits I've seen are Jay's. Jay?
>>>
>>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>>
>>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>>> Regards,
>>> Randy
>>>
>>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>>> Sent: Thursday, January 14, 2010 12:41 PM
>>> To: Tony Hosking
>>> Cc: m3devel m3devel
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>>
>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>>
>>> Randy/Jay, did you change something related to this?
>>>
>>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>>
>>>
>>> Your "cron" job on niagara.cs.purdue.edu
>>> $HOME/cm3/scripts/regression/cron.sh
>>>
>>> produced the following output:
>>>
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 06:30:09 -- checkout in progress.
>>> [start checkout 2010.01.14 06:30:17]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 06:45:08]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 06:45:13 -- compile in progress.
>>> [start compile 2010.01.14 06:45:13]
>>> compile return value: 0
>>> [end compile 2010.01.14 08:49:36]
>>> COMPILE_RETURN = 0
>>> 2010.01.14 08:49:56 -- tests in progress.
>>> [start run-tests 2010.01.14 08:49:56]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> [end run-tests 2010.01.14 11:02:11]
>>> TESTS_RETURN = 510
>>> *** TESTS FAILED
>>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 11:05:04 -- checkout in progress.
>>> [start checkout 2010.01.14 11:05:06]
>>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 11:20:02]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 11:20:08 -- compile in progress.
>>> [start compile 2010.01.14 11:20:08]
>>> compile return value: 1
>>> [end compile 2010.01.14 12:11:12]
>>> COMPILE_RETURN = 1
>>> *** COMPILE FAILED
>>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>>
>>>
>>>
>>>
> 		 	   		  

From wagner at elegosoft.com  Fri Jan 15 10:05:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 15 Jan 2010 10:05:09 +0100
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, 
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> "lastok" of the release branch, which this appears to be, was   
> expected to fail.
> (and for head was expected a few days ago)
>
> Previous compiler can't build m3core.
>
> Must first build compiler, then m3core.
>
> The usual occasional problem.

The release-builds fail, too.

Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
AMD64_LINUX has no previous release, it needs to be fixed manually.
I expect SOLgnu on Niagara to fail soon, too.

The upgrade.sh script should take care for all problems encountered
during bootstrapping a (slightly) incompatible compiler.

In  
http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846

it fails with a quake error though:

5369           
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh  
upgrade
5370          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
5371          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
5372  NEXT    quake runtime error:  
"/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line  
13: quake runtime error: undefined variable: M3_PROFILING
5373
5374          --procedure--  -line-  -file---
5375                             13   
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
5376          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
5377          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5

Later libm3 cannot be compiled due to errors in FilePosix.

Error reporting should definitely be better here, but it's unlikely that
I find the time to do that soon.

Olaf


>   - Jay
>
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm.  The only other commits I've seen are Jay's.  Jay?
>
>
>
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
>
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows.    
> These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
>
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts   
> results in improper bootstrapping of the compiler...
>
>
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
>
>
> Randy/Jay, did you change something related to this?
>
>
>
>
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan 15 12:17:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:17:59 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W48219CDFF89BDE026F09A1E6690@phx.gbl>


ps: the thing do is also what I alluded to:

 

use a "latest" build, but skip m3core/libm3.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] Output from "cron" command
Date: Fri, 15 Jan 2010 11:16:45 +0000



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/875a534f/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 12:16:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>


Interestingly, my upgrade.py goes ahead and foists current configuration files any

old compiler. I've definitely spent some time working around problems

with older compilers in the current configurations.

And older compilers definitely don't always have a good configuration,

so replacing it is not a bad idea.

 

 

That said, this isn't that big a deal. The scripts

prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/cb7ffe36/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 13:16:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 12:16:04 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>,
	<COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
Message-ID: <COL101-W69543449C8565130D44A9E6690@phx.gbl>


well, I did something else instead; let's see how it goes

 

 - Jay

 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: Re: [M3devel] Output from "cron" command



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/efb1e269/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 17:51:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 11:51:18 -0500
Subject: [M3devel] Oops, forgot to ask
In-Reply-To: <4B2965B7.6040304@lcwb.coop>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>
	<4B2965B7.6040304@lcwb.coop>
Message-ID: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>

I just dug this correspondence out of my pile and realised that we still don't have LONGCARD.  This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines.  I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3.  Might as well do it now instead of later, so the pain is not dragged out over time.

On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
>> 
>>  
>>> Hi Gang,
>>> 
>>> 0 - CARDINALs are an integral type defined by the language
>>> spec to be from 0 (zero) to MAXINT (not MAXCARD).  Recently,
>>> a change was made to CM3 to extend the language it recognizes
>>> beyond the original language spec (SPWM3), now CM3 understands
>>> a LONGINT.  
>>> Was there a corresponding LONGCARD defined?
>>>    
>> 
>> No.  But you can write:
>> 
>> [0L..LAST(LONGINT)]
>> 
>> just as
>> 
>> CARDINAL=[0..LAST(INTEGER)]
>>  
> Actually, the line above was once true, long long ago, when dinosaurs
> roamed unfettered.  CARDINAL was changed to be "just like"
> (but not equal to) [0..LAST(INTEGER)].  This would have been
> maybe early 1990s. 
> It took me years to figure out what this actually meant, and more
> years to figure out why, but I believe I now know.  CARDINAL is not an
> equal type to [0..LAST(INTEGER)], but otherwise has all the same
> properties.  This makes the two mutually assignable, which is close
> enough to equal to not matter in most contexts.  The exact consequences
> follow from other language rules. 
> The motivation is this:  [0..LAST(INTEGER)] on a 32-bit machine is not
> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> machines with different values of LAST(INTEGER)), because the numeric
> value of LAST(INTEGER) is part of the expanded type.  The one place this
> matters is if you use pickles to transfer data between machines of different
> word sizes.  If the type is [0..LAST(INTEGER)], the type signature (a hash
> of the complete, expanded type definition) is different on the two machines,
> and values of or containing this type cannot be transferred.  Exact type
> signature matches are used in pickles to find corresponding types when
> reading. 
> But pickles handle different sized INTEGER values fine, expanding/shortening
> as needed.  Being a leaf in a type definition, INTEGER is always the same
> type on any machine.  So CARDINAL was changed to be its own unique
> type too, so it would be possible also to transfer CARDINAL values in pickles
> between different word sizes. 
> So, we really should have a LONGCARD, parallel to CARDINAL.
> 
> Note that this also affects network objects, which use pickles to transfer
> values of the objects.
> 
> 
>> 
>>  
>>> Can is use all 64-bits, or is it restricted to 63, like
>>> the CARDINAL is only 31-bits.
>>>    
>> 
>> 63 bits, since its underlying base type is LONGINT.
>> 
>> 
>>  
>>> 
>>> 
>>> 
>>> +--------------------------------------------------------+
>>> | Peter P. Eiserloh                                      |
>>> +--------------------------------------------------------+
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>  



From jay.krell at cornell.edu  Fri Jan 15 21:53:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:53:51 +0000
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
Message-ID: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>


I know. But see here from 2001:

 

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2



Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.

 

It seems some of the 4.1/5.1 changes never made it from a branch to head??


 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:04:48 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> 
> *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> ***************
> *** 236,241 ****
> --- 236,242 ----
> 
> PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> RAISES {OSError.E} =
> + VAR log: TEXT;
> BEGIN
> IF NOT lm.recoverable(nm) THEN
> RAISE OSError.E(
> ***************
> *** 243,253 ****
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! IF TestFile(lm.logfn(nm)) THEN
> ! RETURN FS.Status(nm).size > 0
> ! ELSE
> ! RETURN TRUE
> ! END;
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> --- 244,251 ----
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! log := lm.logfn(nm);
> ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> 
> 
> On 15 Jan 2010, at 13:03, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 13:03:10
> > 
> > Modified files:
> > cm3/m3-db/stable/src/: LogManager.m3 
> > 
> > Log message:
> > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/62e18b50/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 21:57:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:57:58 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
 file size on 32bit platform)
In-Reply-To: <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
Message-ID: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>


I at least did move the hacks to one place.

I agree it isn't nice.

This is due to my changes, not yours -- changing File.T.status().size to LONGINT.

There's no way to use that in the "compiler" and still support old compiler/libm3, right?

Ok now that I centralized it to sysutils?

 

 

Leave status() alone as using INTEGER and introduce statusL()?

 

 

Or leave size alone and introduce sizeL?

 That's not a complete solution because you have to set size to something.

  -1 if it doesn't fit?

 

 

Or just get past the bootstrapping and put it back using VAL?

It seems a tough situation..the compiler is otherwise I believe

very compatible with old compiler/libm3.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/870c16bb/attachment.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:08:59 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:08:59 -0500
Subject: [M3devel] question on cm3 versioning & dating
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7B8@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

When running upgrade.py, the compiler gets invoked as follows on my system:

C:\cm3\bin\cm3.exe  -build -DROOT=C:/cm3/Sandbox -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15

I also note that the "cm3 -version" option currently produces the following:

Critical Mass Modula-3 version d5.8.2
  last updated: 2009-07-15
  compiled: 2010-01-13 02:33:39
  configuration: C:\cm3\bin\cm3.cfg
  host: NT386
defaulting to native build: NT386
  target: NT386

Questions:


1.       What is purpose of the various "-DCM3..." arguments and should these be changing based on some formula or rule?


2.       I note that when compiling "cm3" package, I get complaints about missing version file information.  What should I be doing to correct this, if anything?  See below:

missing CM3_VERSION_NUMBER will read version file
missing CM3_VERSION_TEXT will read version file
missing CM3_LAST_CHANGED will read version file

It would seem that these three items have some parallel to the "-DCM3..." arguments.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/88197ea8/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 22:17:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:17:15 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
Message-ID: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>

On 15 Jan 2010, at 15:57, Jay K wrote:

> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?

Yes.

> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.

It very soon will not be.

>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/83dcb1f9/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 22:20:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:20:03 -0500
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
	<COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
Message-ID: <9CA89F2F-4065-480D-A20C-87B983CE511B@cs.purdue.edu>

Aha!  Weird!  I'll leave it alone.

On 15 Jan 2010, at 15:53, Jay K wrote:

> I know. But see here from 2001:
>  
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2
> 
> 
> Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.
>  
> It seems some of the 4.1/5.1 changes never made it from a branch to head??
> 
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:04:48 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> > 
> > *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> > --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> > ***************
> > *** 236,241 ****
> > --- 236,242 ----
> > 
> > PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> > RAISES {OSError.E} =
> > + VAR log: TEXT;
> > BEGIN
> > IF NOT lm.recoverable(nm) THEN
> > RAISE OSError.E(
> > ***************
> > *** 243,253 ****
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! IF TestFile(lm.logfn(nm)) THEN
> > ! RETURN FS.Status(nm).size > 0
> > ! ELSE
> > ! RETURN TRUE
> > ! END;
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > --- 244,251 ----
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! log := lm.logfn(nm);
> > ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > 
> > 
> > On 15 Jan 2010, at 13:03, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 13:03:10
> > > 
> > > Modified files:
> > > cm3/m3-db/stable/src/: LogManager.m3 
> > > 
> > > Log message:
> > > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> > 



From jay.krell at cornell.edu  Fri Jan 15 22:34:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:34:11 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
Message-ID: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>


We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.

That is more ok for m3core, less ok for cm3/m3quake.

As well, m3core also couldn't be built with recent but slightly old compiler.

    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).

    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.

 

 

The sysutils/m3quake/cm3 changes should stand?

Ok removing "32" from the name and letting it return >4GB on 64bit platforms.

But I think either it can't use libm3.File.T.status().size, OR we have to

make status().size more compatible such as by introducing statusL or sizeL.

32bit code wouldn't see >4GB file sizes unless actively changed.

Maybe not a bad idea.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/8fdf539f/attachment.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:45:42 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Not sure about your statement that recent cm3.exe can't be used to bootstrap new compiler.

I haven't done an update in last 2 days, but up until then, I've been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.

Are you saying that if I get current update (I'm only a couple of days out of sync with HEAD) that I won't be able to bootstrap anymore?

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.


The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.


 - Jay


________________________________
From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
On 15 Jan 2010, at 15:57, Jay K wrote:

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

Ok now that I centralized it to sysutils?


Leave status() alone as using INTEGER and introduce statusL()?


Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?


Or just get past the bootstrapping and put it back using VAL?

Yes.

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

It very soon will not be.



 - Jay


> From: hosking at cs.purdue.edu<mailto:hosking at cs.purdue.edu>
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de<mailto:jkrell at elego.de>
> CC: m3commit at elegosoft.com<mailto:m3commit at elegosoft.com>
> Subject: Re: [M3commit] CVS Update: cm3
>
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
>
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
>
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> >
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
> > m3makefile
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c
> >
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/898d6377/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 22:46:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:46:48 +0000
Subject: [M3devel] Oops, forgot to ask (LONGCARD)
In-Reply-To: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>,
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>,
	<4B2965B7.6040304@lcwb.coop>,
	<A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
Message-ID: <COL101-W161A9EA86E5E2209FDC950E6690@phx.gbl>


sysutils.GetFileSize use by the compiler should help.

And still I'm open to introducing statusL() or sizeL and leaving status()/size as INTEGER.

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 11:51:18 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Oops, forgot to ask
> 
> I just dug this correspondence out of my pile and realised that we still don't have LONGCARD. This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines. I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3. Might as well do it now instead of later, so the pain is not dragged out over time.
> 
> On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:
> 
> > Tony Hosking wrote:
> >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
> >> 
> >> 
> >>> Hi Gang,
> >>> 
> >>> 0 - CARDINALs are an integral type defined by the language
> >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,
> >>> a change was made to CM3 to extend the language it recognizes
> >>> beyond the original language spec (SPWM3), now CM3 understands
> >>> a LONGINT. 
> >>> Was there a corresponding LONGCARD defined?
> >>> 
> >> 
> >> No. But you can write:
> >> 
> >> [0L..LAST(LONGINT)]
> >> 
> >> just as
> >> 
> >> CARDINAL=[0..LAST(INTEGER)]
> >> 
> > Actually, the line above was once true, long long ago, when dinosaurs
> > roamed unfettered. CARDINAL was changed to be "just like"
> > (but not equal to) [0..LAST(INTEGER)]. This would have been
> > maybe early 1990s. 
> > It took me years to figure out what this actually meant, and more
> > years to figure out why, but I believe I now know. CARDINAL is not an
> > equal type to [0..LAST(INTEGER)], but otherwise has all the same
> > properties. This makes the two mutually assignable, which is close
> > enough to equal to not matter in most contexts. The exact consequences
> > follow from other language rules. 
> > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not
> > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> > machines with different values of LAST(INTEGER)), because the numeric
> > value of LAST(INTEGER) is part of the expanded type. The one place this
> > matters is if you use pickles to transfer data between machines of different
> > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash
> > of the complete, expanded type definition) is different on the two machines,
> > and values of or containing this type cannot be transferred. Exact type
> > signature matches are used in pickles to find corresponding types when
> > reading. 
> > But pickles handle different sized INTEGER values fine, expanding/shortening
> > as needed. Being a leaf in a type definition, INTEGER is always the same
> > type on any machine. So CARDINAL was changed to be its own unique
> > type too, so it would be possible also to transfer CARDINAL values in pickles
> > between different word sizes. 
> > So, we really should have a LONGCARD, parallel to CARDINAL.
> > 
> > Note that this also affects network objects, which use pickles to transfer
> > values of the objects.
> > 
> > 
> >> 
> >> 
> >>> Can is use all 64-bits, or is it restricted to 63, like
> >>> the CARDINAL is only 31-bits.
> >>> 
> >> 
> >> 63 bits, since its underlying base type is LONGINT.
> >> 
> >> 
> >> 
> >>> 
> >>> 
> >>> 
> >>> +--------------------------------------------------------+
> >>> | Peter P. Eiserloh |
> >>> +--------------------------------------------------------+
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/4286c96a/attachment.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:49:06 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
References: <20100115212846.B78742474001@birch.elegosoft.com>
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Can you explain why?

I haven't noticed this problem on Windows.

Perhaps are you suggesting that since cm3.exe is currently executing the -ship directive that Windows won't replace the .exe file while in use?  In general, for these type of problems I've always gotten a pop-up warning that file was in use.  I don't get such an error in this case though.

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3

In fact -ship never puts cm3.exe in the right place.

 - Jay



> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
>
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd
>
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b3ca8a42/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 22:53:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:53:00 +0000
Subject: [M3devel] installing cm3.exe.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115212846.B78742474001@birch.elegosoft.com>,
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W656107CB255BC695B02F6EE6690@phx.gbl>


Because it is likely to fail, we don't even try.

 

 

See m3-sys/cm3/src/m3makefile:

 

 

% Some platforms do not allow overwriting binaries that are currently
% executed, hence the default is not to install the cm3 binary in place.
% This also saves the user from accidentally overwriting the currently
% used compiler. To install the binary, you can either use the
% install-cm3-compiler script from the scripts/ directory or set the
% INSTALL_CM3_IN_BIN environment variable to "yes".
if equal($INSTALL_CM3_IN_BIN, "yes")
Program ("cm3")
else
program ("cm3")
end


 

You wouldn't get a popup for this, you'd just get an error.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: Re: [M3devel] [M3commit] CVS Update: cm3





Jay:
 
Can you explain why?
 
I haven?t noticed this problem on Windows.
 
Perhaps are you suggesting that since cm3.exe is currently executing the ?ship directive that Windows won?t replace the .exe file while in use?  In general, for these type of problems I?ve always gotten a pop-up warning that file was in use.  I don?t get such an error in this case though.
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3
 
In fact -ship never puts cm3.exe in the right place.
 
 - Jay


 
> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
> 
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd 
> 
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/d5965c5c/attachment.html>

From Highjinks at gmx.com  Fri Jan 15 22:46:53 2010
From: Highjinks at gmx.com (Highjinks at gmx.com)
Date: Fri, 15 Jan 2010 16:46:53 -0500
Subject: [M3devel] Hello m3devel.
Message-ID: <20100115214653.129010@gmx.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/2ca36db1/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 22:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:56:19 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <20100115215118.A9F482474001@birch.elegosoft.com>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
Message-ID: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>


VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,

but I think what I had is the way to go.

The bootstrapping pain is otherwise novel.

The compiler doesn't otherwise use LONGINT.

 (My doing that it started using it.)

It ought not until after the current release?

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/f54804b0/attachment.html>

From jay.krell at cornell.edu  Fri Jan 15 22:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:50:50 +0000
Subject: [M3devel] [M3commit] WebFile/QScanner
	use	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W633584E529E074A2C2AEE6E6690@phx.gbl>


cm3.exe from a few days ago doesn't understand the VAL(LONGINT, INTEGER) used in Convert.m3.

 I had "fixed" Convert.m3 that but Tony put it back.

 

cm3/m3quake packages from a period this week only work with current libm3.

  That is fixed.

 

Normally you can either use an old cm3 and skip libm3/m3core or you can use a fairly recent cm3 and not stop skip them.

Neither was the case for a short time, but I restored the first option.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: Re: [M3devel] [M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)







Jay:
 
Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
 
I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
 
Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
 
We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 



From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)



On 15 Jan 2010, at 15:57, Jay K wrote:


 

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

 

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

 

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

 

Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?

 

Yes.

 

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

 

It very soon will not be.

 

 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/ddee77a0/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:08:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:08:08 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.

On 15 Jan 2010, at 16:34, Jay K wrote:

> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 

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

From hosking at cs.purdue.edu  Fri Jan 15 23:09:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:09:10 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <E8BA8874-781B-48CC-8603-78B2B34E38C7@cs.purdue.edu>

You'll  need to bootstrap from old libs to new compiler+old libs to new libs to new compiler+new libs.

On 15 Jan 2010, at 16:45, Coleburn, Randy wrote:

> Jay:
>  
> Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
>  
> I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
>  
> Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
>  
> Regards,
> Randy Coleburn
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, January 15, 2010 4:34 PM
> To: Tony
> Cc: m3devel; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
>  
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
>  
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
>  
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
>  
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
>  
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
>  
> Yes.
>  
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
>  
> It very soon will not be.
>  
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
>  

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

From hosking at cs.purdue.edu  Fri Jan 15 23:13:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:13:38 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

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

From jay.krell at cornell.edu  Fri Jan 15 23:13:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:13:46 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
Message-ID: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>


That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?

They previously never used LONGINT, including converting LONGINT to INTEGER.

*I* changed that, not you.

But then I decided it was a mistake.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:08:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.






On 15 Jan 2010, at 16:34, Jay K wrote:

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 


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

From jay.krell at cornell.edu  Fri Jan 15 23:42:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:42:58 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
Message-ID: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>


The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.

 

I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.

(It's still in progress, but far long.)

 

m3core/libm3 can depend on current compiler, agreed.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:13:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.



On 15 Jan 2010, at 16:56, Jay K wrote:

VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
but I think what I had is the way to go.
The bootstrapping pain is otherwise novel.
The compiler doesn't otherwise use LONGINT.
 (My doing that it started using it.)
It ought not until after the current release?
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/64a7dd20/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:48:09 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, , ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
	<COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
Message-ID: <D4AC4183-1465-47E9-BD5B-DF879237640A@cs.purdue.edu>

My point is that you need to bootstrap a new compiler as follows:

Build new compiler against old libraries.
Compile new libraries using new compiler.
Recompile new compiler against new libraries.
Throw away old libraries.

On 15 Jan 2010, at 17:13, Jay K wrote:

> That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?
> They previously never used LONGINT, including converting LONGINT to INTEGER.
> *I* changed that, not you.
> But then I decided it was a mistake.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:08:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.
> 
> On 15 Jan 2010, at 16:34, Jay K wrote:
> 
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 
> 
> 



From hosking at cs.purdue.edu  Fri Jan 15 23:50:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:50:17 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.

The bootstrapping pain is now no more novel than when LONGINT was first introduced...

> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?

... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.

>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/9acc873c/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:51:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:51:47 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
Message-ID: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>

It's not the presence of LONGINT in the libraries or not.  It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.

On 15 Jan 2010, at 17:42, Jay K wrote:

> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>  
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>  
> m3core/libm3 can depend on current compiler, agreed.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
> 
> Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.
> 
> On 15 Jan 2010, at 16:56, Jay K wrote:
> 
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 
> 
> 

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

From jay.krell at cornell.edu  Sat Jan 16 00:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:45:36 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
Message-ID: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>


I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
I'm not sure, but our regular builds might do that.
Not so now though.
I think you might be saying however that such a compiler might have bugs in it?
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:50:17 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>
>
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
>
> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 00:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:50:17 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
Message-ID: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>


Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.
 
 
Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?
 
 
One of us seems confused. I'm not sure who.
 
 
Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
5.2.6 works.
5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
 
 
I realize that it is grey and not clear how far to run this race.
You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
 
 
One metric has been that you can build with the previous "release".
I'm not sure which that is.
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:51:47 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
>
>
> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>
>
>
> On 15 Jan 2010, at 17:42, Jay K wrote:
>
> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>
> m3core/libm3 can depend on current compiler, agreed.
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
>
>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 00:57:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:57:30 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>
Message-ID: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>

You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:

Using old (release) cm3

m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.

m3core (new, with LONGINT/LONGCARD)
libm3 (new, with LONGINT/LONGCARD)
sysutils
m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses new run-time libraries.

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

> 
> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
> I'm not sure, but our regular builds might do that.
> Not so now though.
> I think you might be saying however that such a compiler might have bugs in it?
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> 
>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>> 
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Sat Jan 16 00:58:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:58:27 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
	<COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
Message-ID: <13D6BE0C-2B40-474D-8743-B4F95F7A1D1A@cs.purdue.edu>

On 15 Jan 2010, at 18:50, Jay K wrote:

> 
> Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.

Not easily.

> Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?

By old, you mean pre-LONGINT, right?

> One of us seems confused. I'm not sure who.

Not me!  ;-)

> Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
> 5.2.6 works.
> 5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
> 
> 
> I realize that it is grey and not clear how far to run this race.
> You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
> 
> 
> One metric has been that you can build with the previous "release".
> I'm not sure which that is.
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:51:47 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>> 
>> 
>> 
>> On 15 Jan 2010, at 17:42, Jay K wrote:
>> 
>> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>> 
>> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
>> (It's still in progress, but far long.)
>> 
>> m3core/libm3 can depend on current compiler, agreed.
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:13:38 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 
>> 
>> 		 	   		  



From Highjinks at gmx.com  Sat Jan 16 01:33:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 16 Jan 2010 01:33:22 +0100 (CET)
Subject: [M3devel] Hello m3devel. Fixed mailer.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <20100115203621.5ca71b4a.Highjinks@gmx.com>

On Fri, 15 Jan 2010 16:46:53 -0500
Highjinks at gmx.com wrote:

Sorry about the html attachment. Webmailers tend to do that. Sticking to my regular client program. 


--
Chris <Highjinks at gmx.com>


From rcolebur at SCIRES.COM  Sat Jan 16 02:09:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 20:09:02 -0500
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7F4@ATLEX02-SRV.SCIRES.LOCAL>

Chris:

Glad to have you on board.  Welcome!

We always seem to have a long list of to-do items and a shorter list of folks to help, so thanks for your offer.

As you become more familiar with Modula-3, don?t hesitate to reach out to me, or to the development group.

Glad to hear your learning experience so far has been good.  That is one of the primary goals of Modula-3.

I?ve been using Modula-3 for over 16 years now; and Modula-2 before that (among other languages).  Right now I?m primarily using Modula-3 on various Windows? platforms, so I won?t be much help with AMD64_LINUX issues, though I have and do use other Linux flavors.

The next major hurdle for the development team is to finish up the next release.  Maybe you can help test on your platform.

Regards,
Randy Coleburn

From: Highjinks at gmx.com [mailto:Highjinks at gmx.com]
Sent: Friday, January 15, 2010 4:47 PM
To: m3devel at elegosoft.com
Subject: [M3devel] Hello m3devel.

Just dropping in to say "Hi" and let you guys know what I'm up to.

Since I'm new to the list, and Modula 3, I wont clog up the list with novice questions. However, I do have fifteen years experience developing in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an order of magnitude faster than I picked up Ada.

My current platform is the AMD64_LINUX setup. And from the looks of it the development team here has been struggling a bit with 32bit/64bit issues. Is my observation correct? If so, what could I, an M3 newbie, do to assist?

I'm checking out the CM3 sources, anonymously, from the repository right now.

If there is anything I can do, just let me know.
--
Chris <Highjinks at gmx.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b95c54c4/attachment.html>

From hosking at cs.purdue.edu  Sat Jan 16 03:45:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 21:45:26 -0500
Subject: [M3devel] LONGINT and LONGCARD
Message-ID: <C101F91A-05C4-4FDA-84A8-A2A8BC13D043@cs.purdue.edu>

Support for these is now more complete.
More probably needs to be done w.r.to pickles, stable, sharedobj, netobj, etc. to handle variations in target implementations (NT386 using the integrated backend currently treats LONGINT/LONGCARD as 32 bits, whereas all other targets using the gcc-based backend treat LONGINT/LONGCARD as 64 bits).

For example:  there are no Longint/Longcard variants of In/OutInteger and In/OutCardinal in PickleStubs.m3.  Rodney?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/462d24e7/attachment.html>

From jay.krell at cornell.edu  Sat Jan 16 05:15:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 04:15:20 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
Message-ID: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>


I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 18:57:30 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>
> Using old (release) cm3
>
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>
> m3core (new, with LONGINT/LONGCARD)
> libm3 (new, with LONGINT/LONGCARD)
> sysutils
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses new run-time libraries.
>
> On 15 Jan 2010, at 18:45, Jay K wrote:
>
>>
>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>> I'm not sure, but our regular builds might do that.
>> Not so now though.
>> I think you might be saying however that such a compiler might have bugs in it?
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>>
>>>
>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>
>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>> but I think what I had is the way to go.
>>> The bootstrapping pain is otherwise novel.
>>>
>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>
>>> The compiler doesn't otherwise use LONGINT.
>>> (My doing that it started using it.)
>>> It ought not until after the current release?
>>>
>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>> To: m3commit at elegosoft.com
>>>> From: hosking at elego.de
>>>> Subject: [M3commit] CVS Update: cm3
>>>>
>>>> CVSROOT: /usr/cvs
>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>
>>>> Modified files:
>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>
>>>> Log message:
>>>> Revert to VAL.
>>>>
>>>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 05:29:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 23:29:27 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
Message-ID: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>

The old (release) libraries don't have the VAL stuff do they?

On 15 Jan 2010, at 23:15, Jay K wrote:

> 
> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>> 
>> Using old (release) cm3
>> 
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>> 
>> m3core (new, with LONGINT/LONGCARD)
>> libm3 (new, with LONGINT/LONGCARD)
>> sysutils
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses new run-time libraries.
>> 
>> On 15 Jan 2010, at 18:45, Jay K wrote:
>> 
>>> 
>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>> I'm not sure, but our regular builds might do that.
>>> Not so now though.
>>> I think you might be saying however that such a compiler might have bugs in it?
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> ________________________________
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> 
>>>> 
>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>> 
>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>> but I think what I had is the way to go.
>>>> The bootstrapping pain is otherwise novel.
>>>> 
>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>> 
>>>> The compiler doesn't otherwise use LONGINT.
>>>> (My doing that it started using it.)
>>>> It ought not until after the current release?
>>>> 
>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>> To: m3commit at elegosoft.com
>>>>> From: hosking at elego.de
>>>>> Subject: [M3commit] CVS Update: cm3
>>>>> 
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>> 
>>>>> Modified files:
>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>> 
>>>>> Log message:
>>>>> Revert to VAL.
>>>>> 
>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Sat Jan 16 06:14:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:14:16 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	,,<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	, , <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
Message-ID: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>


No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
It doesn't matter if x is INTEGER or not, right?
(In newer libraries, it is LONGINT).
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 23:29:27 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> The old (release) libraries don't have the VAL stuff do they?
>
> On 15 Jan 2010, at 23:15, Jay K wrote:
>
>>
>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>
>>> Using old (release) cm3
>>>
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>
>>> m3core (new, with LONGINT/LONGCARD)
>>> libm3 (new, with LONGINT/LONGCARD)
>>> sysutils
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses new run-time libraries.
>>>
>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>
>>>>
>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>> I'm not sure, but our regular builds might do that.
>>>> Not so now though.
>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>
>>>>>
>>>>>
>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>
>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>> but I think what I had is the way to go.
>>>>> The bootstrapping pain is otherwise novel.
>>>>>
>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>
>>>>> The compiler doesn't otherwise use LONGINT.
>>>>> (My doing that it started using it.)
>>>>> It ought not until after the current release?
>>>>>
>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>> To: m3commit at elegosoft.com
>>>>>> From: hosking at elego.de
>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>
>>>>>> Log message:
>>>>>> Revert to VAL.
>>>>>>
>>>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 06:16:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:16:11 +0000
Subject: [M3devel] release vs. head?
Message-ID: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>


Should we just make a new release branch?
Or I keep copying stuff over somewhat selectively?
  We do want LONGCARD in the release, I assume.
 
 
I'll diff the two trees again, see what varies.
Sometimes when I do that I find stuff to take.
 And take the LONGCARD changes.
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 06:20:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:20:22 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, , ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, , ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
	<COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
Message-ID: <DB076F7D-29E4-41E3-B0FA-1D02B33CD6C7@cs.purdue.edu>

That's fine.

On 16 Jan 2010, at 00:14, Jay K wrote:

> 
> No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
> It doesn't matter if x is INTEGER or not, right?
> (In newer libraries, it is LONGINT).
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 23:29:27 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> The old (release) libraries don't have the VAL stuff do they?
>> 
>> On 15 Jan 2010, at 23:15, Jay K wrote:
>> 
>>> 
>>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>> 
>>>> Using old (release) cm3
>>>> 
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>> 
>>>> m3core (new, with LONGINT/LONGCARD)
>>>> libm3 (new, with LONGINT/LONGCARD)
>>>> sysutils
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses new run-time libraries.
>>>> 
>>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>> 
>>>>> 
>>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>>> I'm not sure, but our regular builds might do that.
>>>>> Not so now though.
>>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>> 
>>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>>> but I think what I had is the way to go.
>>>>>> The bootstrapping pain is otherwise novel.
>>>>>> 
>>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>> 
>>>>>> The compiler doesn't otherwise use LONGINT.
>>>>>> (My doing that it started using it.)
>>>>>> It ought not until after the current release?
>>>>>> 
>>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: hosking at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>> 
>>>>>>> Log message:
>>>>>>> Revert to VAL.
>>>>>>> 
>>>>>> 
>>>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/42a67f46/attachment.html>

From hosking at cs.purdue.edu  Sat Jan 16 06:21:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:21:26 -0500
Subject: [M3devel] release vs. head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <99ACAE0F-41FB-4A46-A570-D10C9AA7C872@cs.purdue.edu>

At this point, what substantive differences are there between the release branch and the trunk other than LONGCARD?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 00:16, Jay K wrote:

> 
> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>  We do want LONGCARD in the release, I assume.
> 
> 
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
> And take the LONGCARD changes.
> 
> 
> - Jay 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/551dc9e1/attachment.html>

From jay.krell at cornell.edu  Sat Jan 16 12:11:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings
Message-ID: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>


Any of these worrisome?

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/654b4519/attachment.html>

From jay.krell at cornell.edu  Sat Jan 16 13:50:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 12:50:43 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>


Some of these are fixed in a newer version by adding parens.

The rest I just #pragma warning'ed away.

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings



Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/318612ae/attachment.html>

From jay.krell at cornell.edu  Sat Jan 16 14:45:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 13:45:22 +0000
Subject: [M3devel] longint/longcard/atomics copied from head to release
In-Reply-To: <20100116134209.79B3A2474001@birch.elegosoft.com>
References: <20100116134209.79B3A2474001@birch.elegosoft.com>
Message-ID: <COL101-W37005FD9263CE8B4674E89E6680@phx.gbl>


There's also more "val" reversion here.

Attached should match this. Pity no cvs command or web page can show it.

(I try to make up for CVS lameness just by remembering a lot...not a good technique..)

 

 - Jay

 
> Date: Sat, 16 Jan 2010 14:42:09 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/16 14:42:09
> 
> Modified files:
> cm3/m3-comm/events/src/: Tag: release_branch_cm3_5_8 
> EventStubLib.m3 
> cm3/m3-comm/sharedobjgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 
> Type.i3 Type.m3 Value.m3 
> cm3/m3-comm/stubgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 Type.i3 
> Type.m3 Value.m3 
> cm3/m3-db/stable/src/: Tag: release_branch_cm3_5_8 StableLog.i3 
> StableLog.m3 
> cm3/m3-db/stablegen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 GenModuleCode.m3 
> GenTypeCode.m3 Type.i3 Type.m3 
> Value.m3 
> cm3/m3-libs/libm3/src/pickle/ver2/: Tag: release_branch_cm3_5_8 
> ConvertPacking.m3 
> PickleStubs.i3 
> PickleStubs.m3 
> cm3/m3-libs/m3core/src/runtime/common/: Tag: 
> release_branch_cm3_5_8 
> RTBuiltin.mx 
> RTPacking.i3 
> RTPacking.m3 RTTipe.i3 
> RTTipe.m3 
> cm3/m3-sys/m3cggen/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> BuiltinTypes.m3 m3makefile 
> cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.i3 
> CG.m3 TipeDesc.i3 Token.m3 
> cm3/m3-sys/m3front/src/types/: Tag: release_branch_cm3_5_8 
> RecordType.i3 RecordType.m3 
> SubrangeType.m3 
> cm3/m3-sys/m3middle/src/: Tag: release_branch_cm3_5_8 M3CG.i3 
> M3CG.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 
> M3CG_Binary.i3 M3CG_Check.m3 
> M3CG_Ops.i3 M3CG_Rd.m3 M3CG_Wr.m3 
> cm3/m3-sys/m3quake/src/: Tag: release_branch_cm3_5_8 
> QCompiler.m3 QScanner.i3 
> cm3/m3-sys/m3tools/src/: Tag: release_branch_cm3_5_8 M3Const.m3 
> M3Type.i3 M3Type.m3 
> cm3/m3-tools/m3browser/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-tools/m3tk/src/fe/: Tag: release_branch_cm3_5_8 
> StandardAsText.m3 WiredStandard.m3 
> cm3/m3-tools/m3tk/src/pl/: Tag: release_branch_cm3_5_8 
> M3LTextToType.m3 M3LTypeEquiv.m3 
> M3LTypeToText.i3 M3LTypeToText.m3 
> cm3/m3-tools/m3tk/src/sem/: Tag: release_branch_cm3_5_8 
> M3CMkStd.m3 M3CStdTypes.i3 
> M3CStdTypes.m3 M3CTypeChkUtil.i3 
> M3CTypeChkUtil.m3 
> cm3/m3-tools/m3tk/src/syn/: Tag: release_branch_cm3_5_8 
> M3CLex.m3 M3CParse.m3 M3CToken.i3 
> Added files:
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> LCard.i3 LCard.m3 
> 
> Log message:
> copy from head: LONGINT, LONGCARD, and atomics come along for the ride
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment.txt>

From rodney_bates at lcwb.coop  Sat Jan 16 18:49:12 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 16 Jan 2010 11:49:12 -0600
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <4B51FC18.1000104@lcwb.coop>



Highjinks at gmx.com wrote:
> Just dropping in to say "Hi" and let you guys know what I'm up to.
> 
> Since I'm new to the list, and Modula 3, I wont clog up the list with 
> novice questions. However, I do have fifteen years experience developing 
> in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an 
> order of magnitude faster than I picked up Ada.

As an old Ada refugee, I am glad to hear from someone making the same
transition, and glad to hear your estimate of learning time ratio.
It is the same as the ratio of language definition page counts!

> 
> My current platform is the AMD64_LINUX setup. And from the looks of it 
> the development team here has been struggling a bit with 32bit/64bit 
> issues. Is my observation correct? If so, what could I, an M3 newbie, do 
> to assist?
> 
> I'm checking out the CM3 sources, anonymously, from the repository right 
> now.
> 
> If there is anything I can do, just let me know.
> -- 
> Chris <Highjinks at gmx.com>
> 


From hosking at cs.purdue.edu  Sat Jan 16 19:48:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:12 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <2629BE63-3067-41FD-8A0F-E1F20C79C4FD@cs.purdue.edu>

Yes, those are potentially worrisome.  I've not seen them before.  dtoa has failed in the past because of warnings.  Which compiler?

On 16 Jan 2010, at 06:11, Jay K wrote:

> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/8ca33448/attachment.html>

From hosking at cs.purdue.edu  Sat Jan 16 19:48:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:49 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
Message-ID: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 07:50, Jay K wrote:

> Some of these are fixed in a newer version by adding parens.
> The rest I just #pragma warning'ed away.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sat, 16 Jan 2010 11:11:28 +0000
> Subject: [M3devel] dtoa warnings
> 
> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sat Jan 16 21:03:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 20:03:07 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>,
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>,
	<E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
Message-ID: <COL101-W15A68491F1F3F5ADA4096CE6680@phx.gbl>


A lot/all of the assignment within conditional you can see are ok because in the newer version they doubled the parens. That is the gcc convention for quashing them that unfortunately Microsoft C doesn't recognize.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>cl -c -W4 -Wall -DIEEE_8087 -TC dtoa.h | more

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.


...

 

These I can fix from current source.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>\cygwin\bin\gcc-4.exe -DIEEE_8087 -c -Wall dtoa.h
dtoa.h: In function 'Balloc':
dtoa.h:530: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'mult':
dtoa.h:809: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'pow5mult':
dtoa.h:891: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'lshift':
dtoa.h:972: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'd2b':
dtoa.h:1274: warning: suggest parentheses around assignment used as truth value
dtoa.h:1278: warning: suggest parentheses around assignment used as truth value
dtoa.h:1279: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'match':
dtoa.h:1473: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'hexnan':
dtoa.h:1505: warning: suggest parentheses around assignment used as truth value
dtoa.h:1533: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_strtod':
dtoa.h:1857: warning: suggest parentheses around assignment used as truth value
dtoa.h:1917: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'nrv_alloc':
dtoa.h:2600: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_dtoa':
dtoa.h:2780: warning: suggest parentheses around assignment used as truth value
dtoa.h:2934: warning: suggest parentheses around assignment used as truth value
dtoa.h:3095: warning: suggest parentheses around assignment used as truth value
dtoa.h:3133: warning: suggest parentheses around assignment used as truth value


 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 16 Jan 2010 13:48:49 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] dtoa warnings

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.




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 16 Jan 2010, at 07:50, Jay K wrote:

Some of these are fixed in a newer version by adding parens.
The rest I just #pragma warning'ed away.
 
 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings

Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression







 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/18a42382/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 00:39:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 23:39:09 +0000
Subject: [M3devel] signed overflow warnings in hand.c
Message-ID: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>


In C signed overflow is not defined.

Sometimes compilers take advantage of that and make optimizations assuming there is no overflow.

 

 

$ gcc-4 -O2 -Wstrict-overflow=4 -c hand.c
hand.c: In function `m3_div':
hand.c:244: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:245: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c: In function `m3_divL':
hand.c:256: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:257: warning: assuming signed overflow does not occur when distributing n
egation across division

jay at jay1 /cygdrive/c/dev2/cm3/m3-libs/m3core/src/Csupport/Common

 

 

Is there a way to write this using unsigned math only?

 

I was expecting warnings on the new functions unused functions I added.

 

 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/8526917b/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 06:10:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
Message-ID: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>


The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/5881e0f4/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 06:46:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
Message-ID: <COL101-W30215B137331232907B941E6670@phx.gbl>


The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/0e1628c2/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 06:48:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W30215B137331232907B941E6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	<COL101-W30215B137331232907B941E6670@phx.gbl>
Message-ID: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>


(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/daa44195/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 06:57:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>


The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/ca1bbea2/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 07:04:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 06:04:39 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <COL101-W63EE738E1345D2DACEFC08E6670@phx.gbl>


Actually there is also a problem passing 64 bit integers to K&R functions.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: Re: [M3devel] bugs in hand.c division








The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/c7bd059e/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 08:19:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>


Visual C++ and Sun cc also had problems here.

Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.

  -1 vs 1.

Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.

Anyone feel free to confirm my findings, please. :)

(likewise with INT64_MIN)

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/d4d102c2/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 08:28:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:28:47 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
Message-ID: <COL101-W22756264B636CB0F28608E6670@phx.gbl>


sorry, that wasn't right. But there were problems with Microsoft Visual C++ and Sun cc, and gcc.

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: Re: [M3devel] bugs in hand.c division



Visual C++ and Sun cc also had problems here.
Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.
  -1 vs 1.
Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.
Anyone feel free to confirm my findings, please. :)
(likewise with INT64_MIN)
 
 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/b3a3f1fa/attachment.html>

From roland.illig at gmx.de  Sun Jan 17 08:49:45 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Sun, 17 Jan 2010 08:49:45 +0100
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, , ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <4B52C119.7080808@gmx.de>

Jay K schrieb:
> The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> What is that supposed to equal?
> For any version that doesn't "crash", the result is LONG_MIN.

That's the best result one can get besides throwing an exception. With 
unlimited integers, the result would be LONG_MAX + 1, which equals 
LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
arithmetics.

Roland


From jay.krell at cornell.edu  Sun Jan 17 09:56:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 08:56:59 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <4B52C119.7080808@gmx.de>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	,,<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>,
	<4B52C119.7080808@gmx.de>
Message-ID: <COL101-W162860C88378BBA3019641E6670@phx.gbl>


Understood. I put that back -- depending on C compiler flags,
LONG_MIN / -1 will either be LONG_MIN or trap.
Trap seems reasonable.
Though Modula-3 might mandate the consistent LONG_MIN?
Or leave it implementation defined?


The real bugs here were:
  LONG_MIN / negative (other than -1) was returning positive 
  possibly long long problem with K&R style, I'm pretty sure 
  possibly slightly fragile code wrt signed overflow. 


   funny thing is though, the reason I went looking into this
   was because mailing list threads lead me to believe my
   functions that are meant to look for overflow might be
   broken by the optimizer; it doesn't seem to notice them 
   but the funny stuff m3_div was doing, the optimizer 
   sees opportunity in and warns..so I started writing
   something using unsigned math, which isn't subject
   to such fragility, started testing it by comparison
   to the existing..found the existing to be wrong 


  I didn't really understand the code that was there.
  
But from the spec and behavior I could see -- round down negative results.
   Which you can do by roughly - ((abs(a) + abs(b) - 1) / abs(b))
   Round up the positive result.

 - Jay


> Date: Sun, 17 Jan 2010 08:49:45 +0100
> From: roland.illig at gmx.de
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] bugs in hand.c division
> 
> Jay K schrieb:
> > The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> > What is that supposed to equal?
> > For any version that doesn't "crash", the result is LONG_MIN.
> 
> That's the best result one can get besides throwing an exception. With 
> unlimited integers, the result would be LONG_MAX + 1, which equals 
> LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
> arithmetics.
> 
> Roland
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/644bba0e/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 10:38:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:38:46 +0000
Subject: [M3devel] in favor of mixed operators..
Message-ID: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>


http://python-history.blogspot.com/2009/03/problem-with-integer-division.html


He argues that for a "high level" language, of course
I should be able to add int to long, int to float, etc.
And that int / int should not be int.
At least Modula-3 spells them differently, / vs. MOD.


Of course, "high level" vs. "systems" vs. "one size to fit all"...


Anyway, I give up here.


 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/3f7a2e00/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 10:36:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:36:55 +0000
Subject: [M3devel] integer division rounding?
Message-ID: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>


Modula-3 apparently specifies integer division as rounding down.
http://www.modula3.com/cm3/doc/reference/arithmetic.html

C used to leave it unspecified. So it could be fast.
Fortran rounded to zero.
C's ldiv function rounds to zero.
C now rounds to zero with C99.
  The rationale was that nobody using Fortran seemed to mind.
Java apparently rounds toward zero.
C# apparently rounds toward zero.


I'm assuming we are stuck being different here?

 - Jay

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

From jay.krell at cornell.edu  Sun Jan 17 10:41:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:41:26 +0000
Subject: [M3devel] rd/wr beyond 2GB on 32bit?
Message-ID: <COL101-W501F667E0F501DC8B6E0C1E6670@phx.gbl>


Anyone have ideas or time to think about or work on fixing rd/wr to support going past 2GB on 32bit platforms?
Well, it's easy to get to 64bits.
  - is that enough? Probably. How many rd/wr are "infinite" and long enough lived to exceed 64bits?
  - at what cost to breaking existing code? I sent approximate diffs. A little gnarly.
   Maybe add SeekL, LengthL, etc.?

 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/6d98f794/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 11:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:44:53 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>


-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/065bb5f7/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 11:50:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:50:18 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>


I think I missed a sign.




-2147483648 - 2147483647  * -2
 actually -2147483648 + 2 * 2147483647

  actually 2147483646

which agrees.

so 




-2147483648 div 2147483647 = -2 
-2147483648 mod 2147483647 = 2147483646 

-2 * 2147483647 + 2147483646  = -2147483648

I'll make sure m3_mod works this way if it doesn't already.
Presumably we are stuck with these rules.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: integer division/mod questions?
Date: Sun, 17 Jan 2010 10:44:53 +0000








-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/7702d6cc/attachment.html>

From wagner at elegosoft.com  Sun Jan 17 12:38:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 12:38:16 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>   We do want LONGCARD in the release, I assume.
>
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
>  And take the LONGCARD changes.

 From a release engineering point of view this is more or less
a nightmare. We cannot make incompatible extensions to the feature
set after the fourth release candidate.

The only clean way I'd see to even get the LONGINT changes into the
next release would be to start anew. Meaning declaring 5.8.4 as
the latest release and develop 5.9 on the trunk. Of course we'd
have to carefully merge back any fixes that might be missing on the
trunk right now.

That said, I have currently neither the time nor the energy to do all
that cleanly. I didn't even get round to set up release builds
on new.elego.de via Hudson in order to cover the FreeBSD4 target
platform we recently lost in the release due to my home machine's
complete crash in December. So the release engineering support is not
in the best of states I must admit.

I could live with declaring 5.8.RC4 as an intermediate release,
but somebody really needs to do all the housekeeping of comparing
and merging branches. And we shouldn't start a new release branch
until things have settled down.

Is anybody interested in taking over some of the release engineering
tasks (including Hudson management and re-targeting to the new release)?

Please keep in mind that we haven't managed to get out a stable release
for several years now.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Sun Jan 17 14:21:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 14:21:37 +0100
Subject: [M3devel] Hudson RELENG builds broken
Message-ID: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>

Several Hudson builds are currently broken due to

new source -> compiling ProcessPosixCommon.m3
"../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
qualification '.' (sleep)
1 error encountered
new source -> compiling ProcessPosix.m3

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
for example.

I'm really not sure that we should copy the incompatible
LONGINT and LONGCARD changes to this release branch...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Sun Jan 17 14:33:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:33:42 +0000
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <COL101-W3172F677C46972D488A4F8E6670@phx.gbl>


Sorry, my fault, should be ok now.
Nothing to do with LONGINT/LONGCARD.

 - Jay


> Date: Sun, 17 Jan 2010 14:21:37 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Hudson RELENG builds broken
> 
> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
> qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/d601908b/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 14:42:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:42:57 +0000
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>


We can stick with the current release branch if that is indeed much easier.



I thought there was some agreement we shouldn't release LONGINT as it was.
I can undo the changes if we want.
It's not easy with cvs (not much is) but I can do it.
It's easy for me to diff the trees, just using windiff or diff (again, cvs
seems not to help).



Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
but diff tells us better.


I'm still planning on setting up some more machines and can do FreeBSD4.
(I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
I have to check if Modula-3 actually works on them first...)


Does anyone have the missing steps for the cvsup bug report, like the configuration file,
can show the callstacks, try it with user threads..etc..?


 - Jay


> Date: Sun, 17 Jan 2010 12:38:16 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > Should we just make a new release branch?
> > Or I keep copying stuff over somewhat selectively?
> >   We do want LONGCARD in the release, I assume.
> >
> > I'll diff the two trees again, see what varies.
> > Sometimes when I do that I find stuff to take.
> >  And take the LONGCARD changes.
> 
>  From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/dfa99ae5/attachment.html>

From jay.krell at cornell.edu  Sun Jan 17 14:55:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:55:34 +0000
Subject: [M3devel] how division and modulo work in hand.c?
Message-ID: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>


I have to admit I don't fully understand
the division and modulo code in hand.c.


I don't understand the old division code,
but the documenation and behavior are
clear: round down. I understand
why my version works, though it might
depend on non-guaranteed behavior in C division
for the same sign cases. An earlier version
was clearer since it avoided doing anything
with negative numbers execpt negating them
(and carefully at that).


Modulo is much less clear to me.
>From testing vs. the documentation, I know the
old code was wrong, though close.
I made some guesses based on the old code and
ran a variety of inputs through it.
My version matches the old version, except
where the old version is wrong.
I could write a clearly correct version, but it
would be perhaps much less efficient, just
computing a - b * div(a, b).


I tried running all 32bit inputs through some of it but it was
going to take too long.
I could maybe leave that running a few days if needed.

 - Jay

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

From hosking at cs.purdue.edu  Sun Jan 17 17:05:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:05:44 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>

What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

On 17 Jan 2010, at 04:36, Jay K wrote:

> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> C used to leave it unspecified. So it could be fast.
> Fortran rounded to zero.
> C's ldiv function rounds to zero.
> C now rounds to zero with C99.
>   The rationale was that nobody using Fortran seemed to mind.
> Java apparently rounds toward zero.
> C# apparently rounds toward zero.
> 
> 
> I'm assuming we are stuck being different here?
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/5d8ecb47/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:08:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:08:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
Message-ID: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>

On 17 Jan 2010, at 05:50, Jay K wrote:

> I think I missed a sign.
> 
> -2147483648 - 2147483647  * -2
>  actually -2147483648 + 2 * 2147483647
>   actually 2147483646
> 
> which agrees.
> 
> so 
> 
> -2147483648 div 2147483647 = -2 
> -2147483648 mod 2147483647 = 2147483646 
> 
> -2 * 2147483647 + 2147483646  = -2147483648
> 
> I'll make sure m3_mod works this way if it doesn't already.
> Presumably we are stuck with these rules.

Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: integer division/mod questions?
> Date: Sun, 17 Jan 2010 10:44:53 +0000
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 
> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of the quotient of x and y; that is, the maximum integer not exceeding the real number z such that z * y = x. For integers x and y, the value of x MOD y is defined to be x - y * (x DIV y). This means that for positive y, the value of x MOD y lies in the interval [0 .. y-1], regardless of the sign of x. For negative y, the value of x MOD y lies in the interval [y+1 .. 0], regardless of the sign of x. 
> 
> -2147483648 - 2147483647  * -2
> -2147483648 +2  (due to overflow)
> -2147483646
> 
> which contradicts the second part.
> 
> Maybe I'm confused? I should work this all through again?
> 
>  - Jay

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

From hosking at cs.purdue.edu  Sun Jan 17 17:10:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:10:18 -0500
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <A15FF600-B5FD-4A12-9F35-3BA91BC69B4D@cs.purdue.edu>

On 17 Jan 2010, at 08:21, Olaf Wagner wrote:

> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...

I think we definitely should.  There were some rough edges in the implementation of LONGINT/LONGCARD that needed tidying.  This is our first release with them and we should make sure to have it right for the release.  The problem you see above is something we can fix!

> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Sun Jan 17 17:12:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:12:13 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>

I think that we are closest now to a release we can be happy with than for some time.  It would be a huge shame not to push this out the door.

On 17 Jan 2010, at 06:38, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Should we just make a new release branch?
>> Or I keep copying stuff over somewhat selectively?
>>  We do want LONGCARD in the release, I assume.
>> 
>> I'll diff the two trees again, see what varies.
>> Sometimes when I do that I find stuff to take.
>> And take the LONGCARD changes.
> 
> From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Sun Jan 17 17:13:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:13:39 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
Message-ID: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>

On 17 Jan 2010, at 08:42, Jay K wrote:

> We can stick with the current release branch if that is indeed much easier.
> 
> 
> I thought there was some agreement we shouldn't release LONGINT as it was.

Indeed!

> I can undo the changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff or diff (again, cvs
> seems not to help).

Surely we can move forward on this.

> Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
> but diff tells us better.

I agree.

> I'm still planning on setting up some more machines and can do FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them first...)

Let's not worry about additional targets. 

> Does anyone have the missing steps for the cvsup bug report, like the configuration file,
> can show the callstacks, try it with user threads..etc..?

Maybe cvsup should not be part of the release?

> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more or less
> > a nightmare. We cannot make incompatible extensions to the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT changes into the
> > next release would be to start anew. Meaning declaring 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of course we'd
> > have to carefully merge back any fixes that might be missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the energy to do all
> > that cleanly. I didn't even get round to set up release builds
> > on new.elego.de via Hudson in order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my home machine's
> > complete crash in December. So the release engineering support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate release,
> > but somebody really needs to do all the housekeeping of comparing
> > and merging branches. And we shouldn't start a new release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the release engineering
> > tasks (including Hudson management and re-targeting to the new release)?
> > 
> > Please keep in mind that we haven't managed to get out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

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

From hosking at cs.purdue.edu  Sun Jan 17 17:39:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:39:03 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
Message-ID: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>

TRUNC_DIV_EXPR
FLOOR_DIV_EXPR
CEIL_DIV_EXPR
ROUND_DIV_EXPR
These nodes represent integer division operations that return an integer result. TRUNC_DIV_EXPR rounds towards zero, FLOOR_DIV_EXPRrounds towards negative infinity, CEIL_DIV_EXPR rounds towards positive infinity and ROUND_DIV_EXPR rounds to the closest integer. Integer division in C and C++ is truncating, i.e. TRUNC_DIV_EXPR.
The behavior of these operations on signed arithmetic overflow, when dividing the minimum signed integer by minus one, is controlled by the flag_wrapv and flag_trapv variables. 

TRUNC_MOD_EXPR
FLOOR_MOD_EXPR
CEIL_MOD_EXPR
ROUND_MOD_EXPR
These nodes represent the integer remainder or modulus operation. The integer modulus of two operands a and b is defined as a - (a/b)*b where the division calculated using the corresponding division operator. Hence for TRUNC_MOD_EXPR this definition assumes division using truncation towards zero, i.e. TRUNC_DIV_EXPR. Integer remainder in C and C++ uses truncating division, i.e.TRUNC_MOD_EXPR. 

This is a quote from the gcc internals manual.  I've always wondered why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for known positive operands.  What would be wrong about using them also for negative operands?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 17 Jan 2010, at 08:55, Jay K wrote:

> I have to admit I don't fully understand
> the division and modulo code in hand.c.
> 
> 
> I don't understand the old division code,
> but the documenation and behavior are
> clear: round down. I understand
> why my version works, though it might
> depend on non-guaranteed behavior in C division
> for the same sign cases. An earlier version
> was clearer since it avoided doing anything
> with negative numbers execpt negating them
> (and carefully at that).
> 
> 
> Modulo is much less clear to me.
> From testing vs. the documentation, I know the
> old code was wrong, though close.
> I made some guesses based on the old code and
> ran a variety of inputs through it.
> My version matches the old version, except
> where the old version is wrong.
> I could write a clearly correct version, but it
> would be perhaps much less efficient, just
> computing a - b * div(a, b).
> 
> 
> I tried running all 32bit inputs through some of it but it was
> going to take too long.
> I could maybe leave that running a few days if needed.
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/91a3145d/attachment.html>

From rodney_bates at lcwb.coop  Sun Jan 17 18:29:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 17 Jan 2010 11:29:28 -0600
Subject: [M3devel] integer division rounding?
In-Reply-To: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
	<9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
Message-ID: <4B5348F8.6070605@lcwb.coop>



Tony Hosking wrote:
> What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

For all of these, it is not so easy to decide what is the authoritative
definition.  They all suffer from worse dialect proliferation than Modula-3.
----------------------------------------------------------------------------
Original  Pascal report "The programming Language Pascal", Acta
Informatica, 1, 35-6 (1971) just says div is "division with truncation"
and the usual relationship: "m mod n = m-((m div n)*n)"

Does "truncate" mean towards zero or towards minus infinity?  Read on.
----------------------------------------------------------------------------
"An Axiomatic Definition of the Programming Langauge Pascal",
by C. A. R. Hoare and N. Wirth (apparently a tech report from
Eidgenoessische Technische Hochschule Zuerich (November 1972) says only:

"3.10. (m>=0) ^ ((n>0) => m-n < (m div n)*n <= m"

leaving div undefined for either operand negative.  It does give the
usual relationship.

----------------------------------------------------------------------------
"A Draft Proposal for Pascal", by A.M.Addyman (I have no citation
info for this, except the heading "technical contributions"--maybe
this was SIGPLAN?) says:

"It shall be an error if j is zero, otherwise the value of i div j
shall be such that
abs(i) - abs(j) < abs((i div j) * j) <= abs(i)
where the value shall be zero if abs(i)<abs(j), otherwise the sign
of the value shall be positive if i and j have the same sign and
negative if i and j have different signs.

This is truncating toward zero, which agrees with my memory about Pascal.
------------------------------------------------------------------------------
A "Draft ISO Standard for Pascal" that I have, dated 1982-08-12,
says the same thing about div, but adds:

"A term of the form i mod j shall be an error if j is zero or negative, otherwise the
value of i mod j shall be that value of (i-(k*j)) for integral k such that
0 <= i mod j < j."

disallowing negative j.
-----------------------------------------------------------------------------------
"Programming in Modula-2", Niklaus Wirth, 4th edition, Springer-Verlag, 1988, says:

"x DIV y is equal to the truncated quotient of x/y
  x MOD y is equal to the remainder of the division x DIV y
  x = (x DIV y) * y + (x MOD y), 0 <= (x MOD y) < y"

the last condition implying that MOD is either undefined or an error
for negative y.
-----------------------------------------------------------------------------------

I don't have any Oberon variant definitions quickly accessible.

I recall disliking the Pascal/M2 habit of truncating towards zero as both
inconsistent with traditional mathematics and not want you need as a programmer,
at least in the application of doing subscript arithmetic in circular buffers.
I was glad to see Modula-3 fix that.

> 
> On 17 Jan 2010, at 04:36, Jay K wrote:
> 
>> Modula-3 apparently specifies integer division as rounding down.
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> C used to leave it unspecified. So it could be fast.
>> Fortran rounded to zero.
>> C's ldiv function rounds to zero.
>> C now rounds to zero with C99.
>>   The rationale was that nobody using Fortran seemed to mind.
>> Java apparently rounds toward zero.
>> C# apparently rounds toward zero.
>>
>>
>> I'm assuming we are stuck being different here?
>>
>>  - Jay
>>
> 


From wagner at elegosoft.com  Sun Jan 17 19:44:29 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 19:44:29 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs. head?
In-Reply-To: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
Message-ID: <20100117194429.pvmnaij280s4gck0@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> I think that we are closest now to a release we can be happy with   
> than for some time.  It would be a huge shame not to push this out   
> the door.

OK, I doubt there is very much interest from other users how we do this,
so let's be unorthodox again ;-) Let's just stick to the existing
release branch and let RC 5.8.5 be somewhat incompatible with RC 5.8.4.
Everything else would be too much hassle for too few users
(at least I think so). As I doubt there's anybody who wants to start
the release engineering again, we will just use the existing branch
and move forward.

Any objections?

Olaf

> On 17 Jan 2010, at 06:38, Olaf Wagner wrote:
>
>> Quoting Jay K <jay.krell at cornell.edu>:
>>
>>> Should we just make a new release branch?
>>> Or I keep copying stuff over somewhat selectively?
>>>  We do want LONGCARD in the release, I assume.
>>>
>>> I'll diff the two trees again, see what varies.
>>> Sometimes when I do that I find stuff to take.
>>> And take the LONGCARD changes.
>>
>> From a release engineering point of view this is more or less
>> a nightmare. We cannot make incompatible extensions to the feature
>> set after the fourth release candidate.
>>
>> The only clean way I'd see to even get the LONGINT changes into the
>> next release would be to start anew. Meaning declaring 5.8.4 as
>> the latest release and develop 5.9 on the trunk. Of course we'd
>> have to carefully merge back any fixes that might be missing on the
>> trunk right now.
>>
>> That said, I have currently neither the time nor the energy to do all
>> that cleanly. I didn't even get round to set up release builds
>> on new.elego.de via Hudson in order to cover the FreeBSD4 target
>> platform we recently lost in the release due to my home machine's
>> complete crash in December. So the release engineering support is not
>> in the best of states I must admit.
>>
>> I could live with declaring 5.8.RC4 as an intermediate release,
>> but somebody really needs to do all the housekeeping of comparing
>> and merging branches. And we shouldn't start a new release branch
>> until things have settled down.
>>
>> Is anybody interested in taking over some of the release engineering
>> tasks (including Hudson management and re-targeting to the new release)?
>>
>> Please keep in mind that we haven't managed to get out a stable release
>> for several years now.
>>
>> Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Sun Jan 17 21:19:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:19:14 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100117201914.GD11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 09:36:55AM +0000, Jay K wrote:
> 
> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html

In my experience, the rounding direction on division as supported by 
hardware seems is correlated with whether the processor uses one's 
complement or two's complement arithmetic.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:34:06 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:34:06 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
Message-ID: <20100117203406.GE11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 

There are two kinds of binary integer arithmetic -- two's complement 
and one's complement.  In my experience, two's complement machines tend 
to have the remainder being the same sign as the dividend; one's 
complement machines semm to have a remainder the same sign as the 
divisor.

One's complement machines are all but extinct these days.

> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of 
> the quotient of x and y; that is, the maximum integer 
> not exceeding the real number z such that z * y = x.
> For integers x and y, the value of x MOD y is 
> defined to be x - y * (x DIV y).
> 
> 
> This means that for positive y, the value of x MOD y
> lies in the interval [0 .. y-1], regardless of 
> the sign of x.  For negative y, the value of
> x MOD y lies in the interval [y+1 .. 0], regardless 
> of the sign of x.

And this is consistent with MOD producing a canonical representative of 
an equivalence class modulo y.  It's what's wanted for a lot of 
algorithms.  What it returns for negative y isn't as important, but 
it is important to have positive MODuli for positive y no matter what 
the sign of x is.

But it's not what most two's-complement processors produce naturally.  
Having a MODulo operation that is mathematically well-behaved takes 
extra effort on these machines.

And it's also important to have a remainder that corresponds to the 
division operator.  On two's complement machines you have to either
  * use extra instructions to correct the result of the divide 
    instruction to correspond to the mathematically desirable MOD 
    operator, or
  * Have a separate remainder operation that does correspond to 
    division.

On one's complement machines MOD will have the same effect as remainder.
On two's complement, different.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:39:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:39:42 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
Message-ID: <20100117203942.GF11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> On 17 Jan 2010, at 05:50, Jay K wrote:
> 
> > I think I missed a sign.
> > 
> > -2147483648 - 2147483647  * -2
> >  actually -2147483648 + 2 * 2147483647
> >   actually 2147483646
> > 
> > which agrees.
> > 
> > so 
> > 
> > -2147483648 div 2147483647 = -2 
> > -2147483648 mod 2147483647 = 2147483646 
> > 
> > -2 * 2147483647 + 2147483646  = -2147483648
> > 
> > I'll make sure m3_mod works this way if it doesn't already.
> > Presumably we are stuck with these rules.
> 
> Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

It gives results that satisfy important mathematical identities, such as

     (a + m) MOD m = a MOD m

which makes it easier to reason about the correctness of algorithms and 
program  transformations.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:48:30 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:48:30 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
Message-ID: <20100117204830.GG11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> 
> This is a quote from the gcc internals manual.  I've always wondered 
> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for 
> known positive operands.  What would be wrong about using them also 
> for negative operands?

What does cm3cg use for operands that are not known to be positive?

-- hendrik


From hosking at cs.purdue.edu  Sun Jan 17 22:19:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 15:19:21 -0600
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <20100117204830.GG11416@topoi.pooq.com>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
	<20100117204830.GG11416@topoi.pooq.com>
Message-ID: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>

It calls the C routines in hand.c.

Sent from my iPhone

On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
>>
>> This is a quote from the gcc internals manual.  I've always wondered
>> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
>> known positive operands.  What would be wrong about using them also
>> for negative operands?
>
> What does cm3cg use for operands that are not known to be positive?
>
> -- hendrik


From jay.krell at cornell.edu  Mon Jan 18 02:01:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:01:39 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203942.GF11416@topoi.pooq.com>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>,
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>,
	<20100117203942.GF11416@topoi.pooq.com>
Message-ID: <COL101-W61AE85464E81AF91D50FA3E6660@phx.gbl>


Thanks Hendrik. I didn't realize the relationship to one's complement.

In my little experimentation:

 C modulo, which I assume is machine modulo, returns the sign of the first parameter.

 Modula-3 specifies it to have the sign of the second parameter.

 The "formula" appears to hold either way.

  But I'd have to double check.

 

 

Hand.c used "tricks" to implement div and mod.

My replacement functions are clear for div but still tricky for mod.

I don't understand the tricks.

In fact I just guessed and wrote something similar to the original, but different.

 

 

One goal was to avoid dependency on signed arithmetic overflow, though

 I compromised somewhat, I think. That is, I'm not sure if negative / negative

  and negative mod negative in C depend on overflow.

  What gcc was telling me is the "trick" in the old div function did depend

  on modulo. Ultimately I'm not sure if this dependency was even a problem or not,

  as the bug at least for div tended to occur more with unoptimized compilation.

  Optimization actually tended to fix the bug. But it did vary with compilers.

  Specifically dividing and moding LONG_MIN (or INT64_MIN) by negative numbers

  produced a result with the wrong sign. There was probably also a problem

  with K&R style. The "crash" or "trap" was appropriate.

 

 

I was *actually* wondering if depency on overflow would be a problem

for the other functions I added, but apparently not.

Still I might consider writing them to use only unsigned, or deleting them.

 

 

One of my implied questions is:
  Do people believe my changes are correct?

  Please look at them.

  Esp. mod.

 

 

 - Jay

 
> Date: Sun, 17 Jan 2010 15:39:42 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> > On 17 Jan 2010, at 05:50, Jay K wrote:
> > 
> > > I think I missed a sign.
> > > 
> > > -2147483648 - 2147483647 * -2
> > > actually -2147483648 + 2 * 2147483647
> > > actually 2147483646
> > > 
> > > which agrees.
> > > 
> > > so 
> > > 
> > > -2147483648 div 2147483647 = -2 
> > > -2147483648 mod 2147483647 = 2147483646 
> > > 
> > > -2 * 2147483647 + 2147483646 = -2147483648
> > > 
> > > I'll make sure m3_mod works this way if it doesn't already.
> > > Presumably we are stuck with these rules.
> > 
> > Yep. I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how. Anyone?
> 
> It gives results that satisfy important mathematical identities, such as
> 
> (a + m) MOD m = a MOD m
> 
> which makes it easier to reason about the correctness of algorithms and 
> program transformations.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/0791186c/attachment.html>

From jay.krell at cornell.edu  Mon Jan 18 02:06:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:06:32 +0000
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
Message-ID: <COL101-W4203E93E82A73319794582E6660@phx.gbl>


I *speculate*:

   If the inputs to div or mod are known to have the same sign: don't bother calling the functions.

      Certainly that is clear for two positive inputs in the old functions.

   If either input to div is known to be zero, ditto. Presumably not a common case.

      And *maybe* we want to alter how divide by zero works to reliably trap or not trap.

 

  For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.

    (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)

 

 

 - Jay


 
> From: hosking at cs.purdue.edu
> To: hendrik at topoi.pooq.com
> Date: Sun, 17 Jan 2010 15:19:21 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how division and modulo work in hand.c?
> 
> It calls the C routines in hand.c.
> 
> Sent from my iPhone
> 
> On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> >>
> >> This is a quote from the gcc internals manual. I've always wondered
> >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> >> known positive operands. What would be wrong about using them also
> >> for negative operands?
> >
> > What does cm3cg use for operands that are not known to be positive?
> >
> > -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/95985a3a/attachment.html>

From jay.krell at cornell.edu  Mon Jan 18 02:11:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:11:20 +0000
Subject: [M3devel] another change in hand.c
Message-ID: <COL101-W46DA48ECED7FEDC4F05B82E6660@phx.gbl>


Also I changed set_eq and set_ne to just use memcmp.

 

 

That certainly appears correct.

I believe I added some tests to m3-sys/m3tests.

I also changed the integrated backend to call memcmp directly.

Given the input is known to be ulongs not just bytes, this

might be a deoptimization. However hand.c isn't necessarily

compiled with optimizations.

 

 

You know, memcmp generally handles any alignment.

First it often has to handle a leading unaligned part before

proceeding to compare data in larger chunks.

Whereas if you know the alignment you can be faster.

 

 

I believe m3front inlines for small sets anyway.

 

 

 - Jay

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

From mika at async.async.caltech.edu  Mon Jan 18 02:58:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:58:33 -0800
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl> 
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <20100118015833.708F71A207C@async.async.caltech.edu>


Jay I think the following paragraph is important and demonstrates why
this article is perhaps less relevant to Modula-3:

When you write a function implementing a numeric algorithm (for example,
calculating the phase of the moon) you typically expect the arguments
to be specified as floating point numbers. However, since Python doesnt
have type declarations, nothing is there to stop a caller from providing
you with integer arguments. In a statically typed language, like C,
the compiler will coerce the arguments to floats, but Python does no
such thing  the algorithm is run with integer values until the wonders
of mixed-mode arithmetic produce intermediate results that are floats.

     Mika

Jay K writes:
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml
>
>
>He argues that for a "high level" language=2C of course
>I should be able to add int to long=2C int to float=2C etc.
>And that int / int should not be int.
>At least Modula-3 spells them differently=2C / vs. MOD.
>
>
>Of course=2C "high level" vs. "systems" vs. "one size to fit all"...
>
>
>Anyway=2C I give up here.
>
>
> - Jay
>
>
>
>
> 		 	   		  =
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml<br><br><br>He argues that for a "high level" language=2C of course<br>I =
>should be able to add int to long=2C int to float=2C etc.<br>And that int /=
> int should not be int.<br>At least Modula-3 spells them differently=2C / v=
>s. MOD.<br><br><br>Of course=2C "high level" vs. "systems" vs. "one size to=
> fit all"...<br><br><br>Anyway=2C I give up here.<br><br><br>&nbsp=3B- Jay<=
>br><br><br><br><br> 		 	   		  </body>
></html>=
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_--


From mika at async.async.caltech.edu  Mon Jan 18 02:59:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:59:59 -0800
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl> 
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100118015959.BB9911A207C@async.async.caltech.edu>

Jay K writes:
>--_80188ab7-0cb8-4a34-8b91-f5a76ee2640e_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Modula-3 apparently specifies integer division as rounding down.
>http://www.modula3.com/cm3/doc/reference/arithmetic.html
>
>C used to leave it unspecified. So it could be fast.
>Fortran rounded to zero.
>C's ldiv function rounds to zero.
>C now rounds to zero with C99.
>  The rationale was that nobody using Fortran seemed to mind.
>Java apparently rounds toward zero.
>C# apparently rounds toward zero.
>
>
>I'm assuming we are stuck being different here?
>
> - Jay
>

This is because Modula-3 has MOD while C has "remainder" (%).

If you use the normal definition of MOD you're stuck with making
DIV match it I think...

    Mika


From hendrik at topoi.pooq.com  Mon Jan 18 03:21:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 21:21:35 -0500
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118015833.708F71A207C@async.async.caltech.edu>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
	<20100118015833.708F71A207C@async.async.caltech.edu>
Message-ID: <20100118022134.GA23436@topoi.pooq.com>

On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> 
> Jay I think the following paragraph is important and demonstrates why
> this article is perhaps less relevant to Modula-3:
> 
> When you write a function implementing a numeric algorithm (for example,
> calculating the phase of the moon) you typically expect the arguments
> to be specified as floating point numbers. However, since Python doesnt
> have type declarations, nothing is there to stop a caller from providing
> you with integer arguments. In a statically typed language, like C,
> the compiler will coerce the arguments to floats, but Python does no
> such thing  the algorithm is run with integer values until the wonders
> of mixed-mode arithmetic produce intermediate results that are floats.
> 
>      Mika
> 
> Jay K writes:
> >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> >ml
> >
> >
> >He argues that for a "high level" language=2C of course

He identifies python as a high-level language.  His arguments about what 
a high-level language should do are based on python's absence of static 
typing.  Thus he comes to his conclusion, having identified the concept 
of "high level" with "no static typing".  Presumably he thinls that 
types are an inconvenience inflicted by the desire for run-time 
efficiency.  Many people believe this, failing entirely to notice that 
static typing is a powerful tool in the pursuit of correctness.

-- hendrik


From jay.krell at cornell.edu  Mon Jan 18 04:37:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 03:37:30 +0000
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118022134.GA23436@topoi.pooq.com>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>,
	<20100118015833.708F71A207C@async.async.caltech.edu>,
	<20100118022134.GA23436@topoi.pooq.com>
Message-ID: <COL101-W38145B37DE6AD23BE9C563E6660@phx.gbl>


I am mostly a believer in static types.

 

Though there sure is an interesting place in

languages like C#, C++, ML, where the compiler

is *obligated* in many contexts to deduce static

type and in which it really isn't very controversial.

 

This leads to, for example, qsort that can "easily"

inline the comparison function and beat C.

 

C# has this nifty "LINQ" stuff where to actually

have the programmer state the static types

would be quite onerous.

 

 

A similar scenario is "expression templates" in C++.

Where you have a + b * c / d and the types

of a, b, c, d are a variety of vectors/matrices,

and there are no actual intermediate computations done,

just one inner loop, because the type of the overloads

doesn't hold an intermediate result but rather sort of "directions"

on how to proceed. See Todd Veldhuzien's fascinating work.

http://en.wikipedia.org/wiki/Expression_templates

 

 

The dynamic type proponents do have strong arguments in some situations:

 - You are going to throw out the code soon anyway, sometimes.

 - You have to run it, test it, and that somewhat substitutes for whatever checks the "compiler" makes.

 

 - Jay





 
> Date: Sun, 17 Jan 2010 21:21:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] in favor of mixed operators..
> 
> On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> > 
> > Jay I think the following paragraph is important and demonstrates why
> > this article is perhaps less relevant to Modula-3:
> > 
> > When you write a function implementing a numeric algorithm (for example,
> > calculating the phase of the moon) you typically expect the arguments
> > to be specified as floating point numbers. However, since Python doesnt
> > have type declarations, nothing is there to stop a caller from providing
> > you with integer arguments. In a statically typed language, like C,
> > the compiler will coerce the arguments to floats, but Python does no
> > such thing the algorithm is run with integer values until the wonders
> > of mixed-mode arithmetic produce intermediate results that are floats.
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> > >ml
> > >
> > >
> > >He argues that for a "high level" language=2C of course
> 
> He identifies python as a high-level language. His arguments about what 
> a high-level language should do are based on python's absence of static 
> typing. Thus he comes to his conclusion, having identified the concept 
> of "high level" with "no static typing". Presumably he thinls that 
> types are an inconvenience inflicted by the desire for run-time 
> efficiency. Many people believe this, failing entirely to notice that 
> static typing is a powerful tool in the pursuit of correctness.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/3ce6d925/attachment.html>

From jay.krell at cornell.edu  Mon Jan 18 14:05:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 13:05:58 +0000
Subject: [M3devel] FW: __int128 coming to gcc
In-Reply-To: <1263819673.24181.ezmlm@gcc.gnu.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
Message-ID: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>


gcc 4.6 apparently will have __int128.

How long until we have LONGLONGINT or INT128?

Presumably we should have LONGLONGINT or INT128 to expose it?

:)

 

 

Or, again, I should look at the arithemetic library...

 

 

 - Jay

 

 

Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
 
... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  	review
	255919 by: Kai Tietz <ktietz70@>
 
...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
.... 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/9e165e65/attachment.html>

From hosking at cs.purdue.edu  Mon Jan 18 14:47:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 08:47:41 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W4203E93E82A73319794582E6660@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
	<COL101-W4203E93E82A73319794582E6660@phx.gbl>
Message-ID: <533DD3F9-B74D-4796-AD6D-CA3986A610C1@cs.purdue.edu>

cm3cg currently only uses FLOOR_DIV_EXPR for known positive integers.  For anything else it calls out to the library.

On 17 Jan 2010, at 20:06, Jay K wrote:

> I *speculate*:
>    If the inputs to div or mod are known to have the same sign: don't bother calling the functions.
>       Certainly that is clear for two positive inputs in the old functions.
>    If either input to div is known to be zero, ditto. Presumably not a common case.
>       And *maybe* we want to alter how divide by zero works to reliably trap or not trap.
>  
>   For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.
>     (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > To: hendrik at topoi.pooq.com
> > Date: Sun, 17 Jan 2010 15:19:21 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] how division and modulo work in hand.c?
> > 
> > It calls the C routines in hand.c.
> > 
> > Sent from my iPhone
> > 
> > On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> > 
> > > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> > >>
> > >> This is a quote from the gcc internals manual. I've always wondered
> > >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> > >> known positive operands. What would be wrong about using them also
> > >> for negative operands?
> > >
> > > What does cm3cg use for operands that are not known to be positive?
> > >
> > > -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/0b0f15fd/attachment.html>

From hosking at cs.purdue.edu  Mon Jan 18 15:03:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 09:03:21 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
Message-ID: <298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>

On 18 Jan 2010, at 08:05, Jay K wrote:

> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)

Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as

BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]

>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/53e93722/attachment.html>

From Highjinks at gmx.com  Mon Jan 18 23:11:15 2010
From: Highjinks at gmx.com (Chris)
Date: Mon, 18 Jan 2010 23:11:15 +0100 (CET)
Subject: [M3devel] Explicit types.
Message-ID: <20100118181413.6aaac7d6.Highjinks@gmx.com>

I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.

I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
	
	TYPE UnsignedInt64 ...
	TYPE SignedInt64 ...
	TYPE UnsignedInt32 ...
	TYPE SignedInt32 ...

etc...

Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.

Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.

I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.

I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.

-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Mon Jan 18 23:17:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 17:17:54 -0500
Subject: [M3devel] Explicit types.
In-Reply-To: <20100118181413.6aaac7d6.Highjinks@gmx.com>
References: <20100118181413.6aaac7d6.Highjinks@gmx.com>
Message-ID: <1F367F97-CA3E-4EE4-A103-C446A21BF339@cs.purdue.edu>

Hi Chris,

I think we gave settled on a good fit for long integer types for Modula-3.  Things are unlikely to change further.

--  Tony

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 18 Jan 2010, at 17:11, Chris wrote:

> I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.
> 
> I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
> 	
> 	TYPE UnsignedInt64 ...
> 	TYPE SignedInt64 ...
> 	TYPE UnsignedInt32 ...
> 	TYPE SignedInt32 ...
> 
> etc...
> 
> Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.
> 
> Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.
> 
> I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.
> 
> I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.
> 
> -- 
> Chris <Highjinks at gmx.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/646b47c4/attachment.html>

From rodney_bates at lcwb.coop  Wed Jan 20 01:39:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 19 Jan 2010 18:39:22 -0600
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203406.GE11416@topoi.pooq.com>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
Message-ID: <4B5650BA.6030601@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>> -2147483648 div 2147483647 ?
>> -2147483648 mod 2147483647 ?
>>
>> quotient = -1, remainer = -1 seems reasonable.
>> 2147483647 * -1 + -1 == -2147483648
>>
> 
> There are two kinds of binary integer arithmetic -- two's complement 
> and one's complement.  In my experience, two's complement machines tend 
> to have the remainder being the same sign as the dividend; one's 
> complement machines semm to have a remainder the same sign as the 
> divisor.
> 
> One's complement machines are all but extinct these days.

Tony, you were concerned about showing your age, but 20 years is but an
evening past.  I remember programming ones-complement arithmetic
in assembly language, definitely more decades ago than two.
And that was not my first job.

There is a positive zero and a negative zero, and which one you get
can depend on the operation and operand values that produced the
result, so you have to check for both of them, often with two
separate conditional branches.

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?


> 
>> However, Modula-3 specifies div as rounding down, so
>>
>> -2147483648 div 2147483647  == -2
>>
>> and then
>>
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> The value x DIV y is the floor of 
>> the quotient of x and y; that is, the maximum integer 
>> not exceeding the real number z such that z * y = x.
>> For integers x and y, the value of x MOD y is 
>> defined to be x - y * (x DIV y).
>>
>>
>> This means that for positive y, the value of x MOD y
>> lies in the interval [0 .. y-1], regardless of 
>> the sign of x.  For negative y, the value of
>> x MOD y lies in the interval [y+1 .. 0], regardless 
>> of the sign of x.
> 
> And this is consistent with MOD producing a canonical representative of 
> an equivalence class modulo y.  It's what's wanted for a lot of 
> algorithms.  What it returns for negative y isn't as important, but 
> it is important to have positive MODuli for positive y no matter what 
> the sign of x is.
> 
> But it's not what most two's-complement processors produce naturally.  
> Having a MODulo operation that is mathematically well-behaved takes 
> extra effort on these machines.
> 
> And it's also important to have a remainder that corresponds to the 
> division operator.  On two's complement machines you have to either
>   * use extra instructions to correct the result of the divide 
>     instruction to correspond to the mathematically desirable MOD 
>     operator, or
>   * Have a separate remainder operation that does correspond to 
>     division.
> 
> On one's complement machines MOD will have the same effect as remainder.
> On two's complement, different.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed Jan 20 03:45:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:45:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <COL101-W5066919E7799495954BF25E6640@phx.gbl>


> There is a positive zero and a negative zero, and which one you get 

 
 Rodney you reminded me of something I forgot to ask: 
 
 
Is 0 div -1 = 0 or -1?
 
 
In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
If 0> -0, then 0 div -1 should equal -1 instead of 0.
 
 
My current code I believe returns 0 for 0 div anything.
  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
 
 
The previous code probably also but I'll have to double check.
  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
 
 
  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
 
 
  Nice if anyone can reproduce the problem with K&R + long long as well.
  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
 
 
  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
 
 
  In particular, LONG_MIN div or mod -1 can trap.
 
 
  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
 
 
(anywhere I say "LONG_MIN", INT64_MIN has similar problem)
 
 
 
 - Jay


----------------------------------------
> Date: Tue, 19 Jan 2010 18:39:22 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>
> hendrik at topoi.pooq.com wrote:
>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>> -2147483648 div 2147483647 ?
>>> -2147483648 mod 2147483647 ?
>>>
>>> quotient = -1, remainer = -1 seems reasonable.
>>> 2147483647 * -1 + -1 == -2147483648
>>>
>>
>> There are two kinds of binary integer arithmetic -- two's complement
>> and one's complement. In my experience, two's complement machines tend
>> to have the remainder being the same sign as the dividend; one's
>> complement machines semm to have a remainder the same sign as the
>> divisor.
>>
>> One's complement machines are all but extinct these days.
>
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past. I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
>
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
>
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines? Electromechanical accounting machines?
>
>
>>
>>> However, Modula-3 specifies div as rounding down, so
>>>
>>> -2147483648 div 2147483647 == -2
>>>
>>> and then
>>>
>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>
>>> The value x DIV y is the floor of
>>> the quotient of x and y; that is, the maximum integer
>>> not exceeding the real number z such that z * y = x.
>>> For integers x and y, the value of x MOD y is
>>> defined to be x - y * (x DIV y).
>>>
>>>
>>> This means that for positive y, the value of x MOD y
>>> lies in the interval [0 .. y-1], regardless of
>>> the sign of x. For negative y, the value of
>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>> of the sign of x.
>>
>> And this is consistent with MOD producing a canonical representative of
>> an equivalence class modulo y. It's what's wanted for a lot of
>> algorithms. What it returns for negative y isn't as important, but
>> it is important to have positive MODuli for positive y no matter what
>> the sign of x is.
>>
>> But it's not what most two's-complement processors produce naturally.
>> Having a MODulo operation that is mathematically well-behaved takes
>> extra effort on these machines.
>>
>> And it's also important to have a remainder that corresponds to the
>> division operator. On two's complement machines you have to either
>> * use extra instructions to correct the result of the divide
>> instruction to correspond to the mathematically desirable MOD
>> operator, or
>> * Have a separate remainder operation that does correspond to
>> division.
>>
>> On one's complement machines MOD will have the same effect as remainder.
>> On two's complement, different.
>>
>> -- hendrik
>> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 20 03:59:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:59:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>


That paper also suggests a more efficient algorithm we should probably adopt:
 
 
/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}

 
long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}
 
 
Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)

 
We'd probably want to be sure the / followed by % got optimized into just one divide though.
 
 
or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.
 
 
Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Date: Wed, 20 Jan 2010 02:45:43 +0000
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>> There is a positive zero and a negative zero, and which one you get
>
>
> Rodney you reminded me of something I forgot to ask:
>
>
> Is 0 div -1 = 0 or -1?
>
>
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>
>
> My current code I believe returns 0 for 0 div anything.
> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>
>
> The previous code probably also but I'll have to double check.
> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>
>
> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>
>
> Nice if anyone can reproduce the problem with K&R + long long as well.
> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>
>
> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>
>
> In particular, LONG_MIN div or mod -1 can trap.
>
>
> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>
>
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>
>
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>>
>>
>>
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>>
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>>
>>>
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>>
>>> One's complement machines are all but extinct these days.
>>
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>>
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>>
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>>
>>
>>>
>>>> However, Modula-3 specifies div as rounding down, so
>>>>
>>>> -2147483648 div 2147483647 == -2
>>>>
>>>> and then
>>>>
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>>
>>>>
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>>
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>>
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>>
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>>
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>>
>>> -- hendrik
>>> 		 	   		  

From hosking at cs.purdue.edu  Wed Jan 20 11:07:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:07:45 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>

These are all overflow examples correct?  In which case the meaning is undefined?

But certainly, 0 DIV -1 should be 0.

I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy.  In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations?  I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.

On 19 Jan 2010, at 21:45, Jay K wrote:

> 
>> There is a positive zero and a negative zero, and which one you get 
> 
> 
> Rodney you reminded me of something I forgot to ask: 
> 
> 
> Is 0 div -1 = 0 or -1?
> 
> 
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
> 
> 
> My current code I believe returns 0 for 0 div anything.
>  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> 
> 
> The previous code probably also but I'll have to double check.
>  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> 
> 
>  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> 
> 
>  Nice if anyone can reproduce the problem with K&R + long long as well.
>  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> 
> 
>  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> 
> 
>  In particular, LONG_MIN div or mod -1 can trap.
> 
> 
>  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> 
> 
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>> 
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>> 
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>> 
>>> 
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>> 
>>> One's complement machines are all but extinct these days.
>> 
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>> 
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>> 
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>> 
>> 
>>> 
>>>> However, Modula-3 specifies div as rounding down, so
>>>> 
>>>> -2147483648 div 2147483647 == -2
>>>> 
>>>> and then
>>>> 
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>> 
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>> 
>>>> 
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>> 
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>> 
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>> 
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>> 
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>> 
>>> -- hendrik
>>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 20 11:09:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:09:33 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>

C specifies truncated division.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 19 Jan 2010, at 21:59, Jay K wrote:

> 
> That paper also suggests a more efficient algorithm we should probably adopt:
> 
> 
> /* Floored division */
> long divF( long D, long d )
> {
> long q = D/d;
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
> return q;
> }
> 
> 
> long modF( long D, long d )
> {
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
> return r;
> }
> 
> 
> Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
> or (r < 0) ^ (d < 0)
> 
> 
> We'd probably want to be sure the / followed by % got optimized into just one divide though.
> 
> 
> or maybe what I have is fine.
> As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
> I am assuming C never "rounds", but either truncates or "floors".
> e.g. 1/2 in the face of rounding is 1.
> 
> 
> Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
>> Date: Wed, 20 Jan 2010 02:45:43 +0000
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>>> There is a positive zero and a negative zero, and which one you get
>> 
>> 
>> Rodney you reminded me of something I forgot to ask:
>> 
>> 
>> Is 0 div -1 = 0 or -1?
>> 
>> 
>> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
>> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>> 
>> 
>> My current code I believe returns 0 for 0 div anything.
>> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>> 
>> 
>> The previous code probably also but I'll have to double check.
>> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>> 
>> 
>> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>> 
>> 
>> Nice if anyone can reproduce the problem with K&R + long long as well.
>> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>> 
>> 
>> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>> 
>> 
>> In particular, LONG_MIN div or mod -1 can trap.
>> 
>> 
>> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>> 
>> 
>> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] integer division/mod questions?
>>> 
>>> 
>>> 
>>> hendrik at topoi.pooq.com wrote:
>>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>>> -2147483648 div 2147483647 ?
>>>>> -2147483648 mod 2147483647 ?
>>>>> 
>>>>> quotient = -1, remainer = -1 seems reasonable.
>>>>> 2147483647 * -1 + -1 == -2147483648
>>>>> 
>>>> 
>>>> There are two kinds of binary integer arithmetic -- two's complement
>>>> and one's complement. In my experience, two's complement machines tend
>>>> to have the remainder being the same sign as the dividend; one's
>>>> complement machines semm to have a remainder the same sign as the
>>>> divisor.
>>>> 
>>>> One's complement machines are all but extinct these days.
>>> 
>>> Tony, you were concerned about showing your age, but 20 years is but an
>>> evening past. I remember programming ones-complement arithmetic
>>> in assembly language, definitely more decades ago than two.
>>> And that was not my first job.
>>> 
>>> There is a positive zero and a negative zero, and which one you get
>>> can depend on the operation and operand values that produced the
>>> result, so you have to check for both of them, often with two
>>> separate conditional branches.
>>> 
>>> Anyone remember nines- or tens-complement arithmetic on decimal
>>> machines? Electromechanical accounting machines?
>>> 
>>> 
>>>> 
>>>>> However, Modula-3 specifies div as rounding down, so
>>>>> 
>>>>> -2147483648 div 2147483647 == -2
>>>>> 
>>>>> and then
>>>>> 
>>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>> 
>>>>> The value x DIV y is the floor of
>>>>> the quotient of x and y; that is, the maximum integer
>>>>> not exceeding the real number z such that z * y = x.
>>>>> For integers x and y, the value of x MOD y is
>>>>> defined to be x - y * (x DIV y).
>>>>> 
>>>>> 
>>>>> This means that for positive y, the value of x MOD y
>>>>> lies in the interval [0 .. y-1], regardless of
>>>>> the sign of x. For negative y, the value of
>>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>>> of the sign of x.
>>>> 
>>>> And this is consistent with MOD producing a canonical representative of
>>>> an equivalence class modulo y. It's what's wanted for a lot of
>>>> algorithms. What it returns for negative y isn't as important, but
>>>> it is important to have positive MODuli for positive y no matter what
>>>> the sign of x is.
>>>> 
>>>> But it's not what most two's-complement processors produce naturally.
>>>> Having a MODulo operation that is mathematically well-behaved takes
>>>> extra effort on these machines.
>>>> 
>>>> And it's also important to have a remainder that corresponds to the
>>>> division operator. On two's complement machines you have to either
>>>> * use extra instructions to correct the result of the divide
>>>> instruction to correspond to the mathematically desirable MOD
>>>> operator, or
>>>> * Have a separate remainder operation that does correspond to
>>>> division.
>>>> 
>>>> On one's complement machines MOD will have the same effect as remainder.
>>>> On two's complement, different.
>>>> 
>>>> -- hendrik
>>>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/8fa44102/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 12:20:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:20:03 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
Message-ID: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>


Ok with changing LONGINT to be __int128, *but*

you really should not change it with a compiler flag.

For any given platform, "basics" like this should not change meaning.

It makes it such that you can't link code safely.

 

 

Basically, "platform" or "target" should map to one "ABI".

 

 

I really kind of like what I proposed earlier.

  Let the user define things.

  TYPE INT64 = BITS 64 FOR INTEGER;

  TYPE INT128 = BITS 128 FOR INTEGER;

 

TYPE INT256 = BITS 256 FOR INTEGER;

  (* either an error, or the compiler generates calls to multi-precision library *)

 

 

This is btw why the user thread stuff should be either 1) a runtime alterable decision

or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).

So that there aren't multiple ABIs and you can link together any code for

a given platform.

With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.

That forces recompilation of everything affected.

 

 

 - Jay

 


Subject: Re: [M3devel] __int128 coming to gcc
From: darko at darko.org
Date: Wed, 20 Jan 2010 14:23:32 +1100
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.




On 19/01/2010, at 1:03 AM, Tony Hosking wrote:



On 18 Jan 2010, at 08:05, Jay K wrote:


gcc 4.6 apparently will have __int128.
How long until we have LONGLONGINT or INT128?
Presumably we should have LONGLONGINT or INT128 to expose it?
:)



Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as


BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]



 Or, again, I should look at the arithemetic library...
 
 
 - Jay
 
 
Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091

... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
255919 by: Kai Tietz <ktietz70@>

...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
....

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

From jay.krell at cornell.edu  Wed Jan 20 12:21:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:21:00 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>,
	<D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
Message-ID: <COL101-W557F59387EF941814B75F4E6640@phx.gbl>


Only lately with C99.

Prior to that it was unspecified.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 05:09:33 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

C specifies truncated division.




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 19 Jan 2010, at 21:59, Jay K wrote:


That paper also suggests a more efficient algorithm we should probably adopt:


/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}


long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}


Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)


We'd probably want to be sure the / followed by % got optimized into just one divide though.


or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.


Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)


- Jay


----------------------------------------

From: jay.krell at cornell.edu

To: rodney_bates at lcwb.coop; m3devel at elegosoft.com

Date: Wed, 20 Jan 2010 02:45:43 +0000

Subject: Re: [M3devel] integer division/mod questions?






There is a positive zero and a negative zero, and which one you get





Rodney you reminded me of something I forgot to ask:





Is 0 div -1 = 0 or -1?





In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.

If 0> -0, then 0 div -1 should equal -1 instead of 0.





My current code I believe returns 0 for 0 div anything.

And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.





The previous code probably also but I'll have to double check.

The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.





Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.





Nice if anyone can reproduce the problem with K&R + long long as well.

I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.





The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.





In particular, LONG_MIN div or mod -1 can trap.





div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.





(anywhere I say "LONG_MIN", INT64_MIN has similar problem)







- Jay





----------------------------------------


Date: Tue, 19 Jan 2010 18:39:22 -0600


From: rodney_bates at lcwb.coop


To: m3devel at elegosoft.com


Subject: Re: [M3devel] integer division/mod questions?











hendrik at topoi.pooq.com wrote:



On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:




-2147483648 div 2147483647 ?




-2147483648 mod 2147483647 ?









quotient = -1, remainer = -1 seems reasonable.




2147483647 * -1 + -1 == -2147483648












There are two kinds of binary integer arithmetic -- two's complement



and one's complement. In my experience, two's complement machines tend



to have the remainder being the same sign as the dividend; one's



complement machines semm to have a remainder the same sign as the



divisor.







One's complement machines are all but extinct these days.





Tony, you were concerned about showing your age, but 20 years is but an


evening past. I remember programming ones-complement arithmetic


in assembly language, definitely more decades ago than two.


And that was not my first job.





There is a positive zero and a negative zero, and which one you get


can depend on the operation and operand values that produced the


result, so you have to check for both of them, often with two


separate conditional branches.





Anyone remember nines- or tens-complement arithmetic on decimal


machines? Electromechanical accounting machines?














However, Modula-3 specifies div as rounding down, so









-2147483648 div 2147483647 == -2









and then









http://www.modula3.com/cm3/doc/reference/arithmetic.html









The value x DIV y is the floor of




the quotient of x and y; that is, the maximum integer




not exceeding the real number z such that z * y = x.




For integers x and y, the value of x MOD y is




defined to be x - y * (x DIV y).














This means that for positive y, the value of x MOD y




lies in the interval [0 .. y-1], regardless of




the sign of x. For negative y, the value of




x MOD y lies in the interval [y+1 .. 0], regardless




of the sign of x.







And this is consistent with MOD producing a canonical representative of



an equivalence class modulo y. It's what's wanted for a lot of



algorithms. What it returns for negative y isn't as important, but



it is important to have positive MODuli for positive y no matter what



the sign of x is.







But it's not what most two's-complement processors produce naturally.



Having a MODulo operation that is mathematically well-behaved takes



extra effort on these machines.







And it's also important to have a remainder that corresponds to the



division operator. On two's complement machines you have to either



* use extra instructions to correct the result of the divide



instruction to correspond to the mathematically desirable MOD



operator, or



* Have a separate remainder operation that does correspond to



division.







On one's complement machines MOD will have the same effect as remainder.



On two's complement, different.







-- hendrik



    

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5060991a/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 12:27:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:27:17 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
Message-ID: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>


No, not overflow examples.

 

 

LONG_MIN divided by any negative number was a negative number.

  But I believe it should be positive.

  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.

    The result is representable.

  LONG_MIN mod negative numbers also had the wrong sign.

 

 

You don't really have to view a diff.

I left the old functions m3_mod, m3_div, present, renamed

to m3_mod_old, m3_div_old.

 

 

So you can see both versions.

The new versions don't look particularly like the old ones.

The "proof" to me is the behavior per testing.

There is test code in there as well, under #if 0.

I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.

Mostly on Darwin/x86 though.

Both with gcc (4.0.1) and gcc-4.2.

 

 

Old:

 

static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}


 

long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}


 

"new" or "current":

 

long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}


 

long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}


 

In the case of div, I believe my code is clear and I understand it.

But perhaps could be more efficient.

 

 

In the case of mod, I don't know what is going on actually.

I just made it look something like old and tested it.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5cd68a5d/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 12:31:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:31:18 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>, ,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>,
	<COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
Message-ID: <COL101-W22FDCE853B21D87623183FE6640@phx.gbl>


Actually I think the new mod/div functions are still a little

risky for negative div or mod negative.

They'd more reliable/predictable/portable if if they used unsigned

numbers.

 

 

The reason I started looking at this stuff is because I was

reading about gcc assuming signed overflow won't occur

and then making optimizations with that assumption.

You can ask it to warn when it does so.
I thought this might break the new but unused m3_add and

such. The warning triggered for the existing div (but not mod) functions.

So I set about rewriting them to use unsigned math, which

is the recommendation here -- because its overflow is

well defined by the C standard -- and then comparing

mine with the previous/current code..and noticed wrong behavior

in the previous/current.

 

 - Jay



 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 11:27:17 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?



No, not overflow examples.
 
 
LONG_MIN divided by any negative number was a negative number.
  But I believe it should be positive.
  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.
    The result is representable.
  LONG_MIN mod negative numbers also had the wrong sign.
 
 
You don't really have to view a diff.
I left the old functions m3_mod, m3_div, present, renamed
to m3_mod_old, m3_div_old.
 
 
So you can see both versions.
The new versions don't look particularly like the old ones.
The "proof" to me is the behavior per testing.
There is test code in there as well, under #if 0.
I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.
Mostly on Darwin/x86 though.
Both with gcc (4.0.1) and gcc-4.2.
 
 
Old:
 
static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}

 
long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}

 
"new" or "current":
 
long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}

 
long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}

 
In the case of div, I believe my code is clear and I understand it.
But perhaps could be more efficient.
 
 
In the case of mod, I don't know what is going on actually.
I just made it look something like old and tested it.
 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5a443bbb/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 12:40:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:40:03 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
Message-ID: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>


So..I have m3back using Target.Int a bunch.

And converting back and forth some between Target.Int and

INTEGER and doing match with Target.Int.

And various operations can fail.

 

 

And my current diff results in:

 

 

  new source -> compiling Lex.m3  
  "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed  
  "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed  
  2 errors encountered  
  new source -> compiling Scan.i3  

 

 

  which is nice to see, it means my code is actually running.  

 

 

  So I look at the code in question:  

 

 

  PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN): Word.T  
  VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN 
...

    IF signed AND
       ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
        (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
      RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
....

 

 

-FIRST(INTEGER).

 

 

What is that supposed to do?

 

 

I mean, I kind of know, I'm slightly playing stupid, partly not.

Does the compiler know what is an INTEGER vs. what is a "Word"?

Or it is just obligated to assume everything is a Word?

 To do the negation at compile time and ignore the overflow?

 

 

Does the language need work here?

I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

 

 

 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/70e3767e/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 12:55:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:55:14 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
Message-ID: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>


I propose we add WarningHandler, set_warning_handler.

The signatures are either identical to the existing ErrorHandler, set_error_handler.

Or possibly there is a warning "level".

For now I'm implementing it such that the warning level

is hardcoded as 2.

 

 

This is so I can report but ignore the overflows when I use TInt in m3back.

 

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/61d4067c/attachment.html>

From jay.krell at cornell.edu  Wed Jan 20 16:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 15:05:23 +0000
Subject: [M3devel] m3back using Target.Int in place of INTEGER a lot now
In-Reply-To: <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
Message-ID: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>


This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.

I did look through pretty much every single line in search of the one bug I saw working on it.

It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.

Which broke INC, it was adding 0 instead 1.

You could see the bug in RTIO.PutString where it just kept outputing the first character.

So I use TInt.Multiply instead.

 

 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3



diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/2a2f079c/attachment.html>

From hendrik at topoi.pooq.com  Wed Jan 20 17:23:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:23:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <20100120162315.GA18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 02:59:43AM +0000, Jay K wrote:
>  
> Integer division probably not a big concern anyway, esp. with any 
> negative numbers. The main place I ever see division/mod used is hash 
> tables, and the numbers are always positive

And that's where it's important that the remainder has the same sign as 
the divisor.

> (I rarely see negative numbers used anywhere in "systems" programming 
> actually -- file sizes, array indices, array sizes..all positive; 
> "math" needs floating point often...)

You can get negative numbers in the subscripting calculations for an 
array whose subscripts are in the range like 10000..10345.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:26:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:26:20 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <20100120162620.GB18214@topoi.pooq.com>

On Tue, Jan 19, 2010 at 06:39:22PM -0600, Rodney M. Bates wrote:
> 
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past.  I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
> 
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
> 
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines?

Conputers, no.  The decimal computer I used has signed-magnitude 
representation.  And it did addition by looking pairs of digits up in an 
array in RAM.  YOu could get interesting effects by replacing the 
addition tables.

>  Electromechanical accounting machines?

Yes.  I remember using these when studying statistics.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:30:39 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:30:39 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <20100120163039.GC18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> 
> you really should not change it with a compiler flag.
> 
> For any given platform, "basics" like this should not change meaning.
> 
> It makes it such that you can't link code safely.
> 
>  
> 
>  
> 
> Basically, "platform" or "target" should map to one "ABI".
> 
>  
> 
>  
> 
> I really kind of like what I proposed earlier.
> 
>   Let the user define things.
>
>   TYPE INT64 = BITS 64 FOR INTEGER;
> 
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> 
> TYPE INT256 = BITS 256 FOR INTEGER;
> 
> 
>   (* either an error, or the compiler generates calls to multi-precision library *)

Well, with INTEGER being defined as the type for efficient integer 
arithmetic, you's have to say

  TYPE INT64 = BITS 64 FOR LONGINT;

  TYPE INT128 = BITS 128 FOR LONGINT;

 

TYPE INT256 = BITS 256 FOR LONGINT;

and on many current machines, file offset should then be defined as 
BITS64 instead of LONGINT.

-- hendrik

> This is btw why the user thread stuff should be either 1) a runtime alterable decision


From rcolebur at SCIRES.COM  Wed Jan 20 21:02:11 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 20 Jan 2010 15:02:11 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com> <4B5650BA.6030601@lcwb.coop>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6ED53@ATLEX02-SRV.SCIRES.LOCAL>

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Tuesday, January 19, 2010 7:39 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?

[Randy Coleburn] 
[Randy Coleburn] My first "programming" experience dates back to the old IBM tabulating machine where you had to plug up the wires to form the tabulating logic.  Also, the old keypunch machines, card sorters, etc.  My first real computer had core memory and we used the old teletype machines with canary yellow paper and paper tape.  But, given where we are today, I don't think any of us would remember these as "the good ol' days" of computing, though I do have some fond memories.

Regards,
Randy


From hosking at cs.purdue.edu  Thu Jan 21 00:50:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:50:08 -0500
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
Message-ID: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>

I don't understand why you need this.
Why would you have overflows in m3back?
Are you constant folding or something?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:55, Jay K wrote:

> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>  
>  
> This is so I can report but ignore the overflows when I use TInt in m3back.
>  
>  
>  - Jay
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Thu Jan 21 00:59:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:59:30 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
Message-ID: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 10:05, Jay K wrote:

> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 

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

From hosking at cs.purdue.edu  Thu Jan 21 01:02:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:02:33 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>

But INTEGER is the natural integer size.  Not the maximum (perhaps less efficient) integer size supported by the compiler.
What's wrong with:

BITS 64 FOR LONGINT

?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:20, Jay K wrote:

> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/7f1a3a17/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 21 01:03:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:03:01 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100120163039.GC18214@topoi.pooq.com>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<20100120163039.GC18214@topoi.pooq.com>
Message-ID: <2EF1DA6A-281F-49EA-8612-AD30CE6D7EBB@cs.purdue.edu>

Yes, exactly.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 11:30, hendrik at topoi.pooq.com wrote:

> On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> 
>> you really should not change it with a compiler flag.
>> 
>> For any given platform, "basics" like this should not change meaning.
>> 
>> It makes it such that you can't link code safely.
>> 
>> 
>> 
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> 
>> 
>> 
>> I really kind of like what I proposed earlier.
>> 
>>  Let the user define things.
>> 
>>  TYPE INT64 = BITS 64 FOR INTEGER;
>> 
>>  TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> 
>> 
>>  (* either an error, or the compiler generates calls to multi-precision library *)
> 
> Well, with INTEGER being defined as the type for efficient integer 
> arithmetic, you's have to say
> 
>  TYPE INT64 = BITS 64 FOR LONGINT;
> 
>  TYPE INT128 = BITS 128 FOR LONGINT;
> 
> 
> 
> TYPE INT256 = BITS 256 FOR LONGINT;
> 
> and on many current machines, file offset should then be defined as 
> BITS64 instead of LONGINT.
> 
> -- hendrik
> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision

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

From hosking at cs.purdue.edu  Thu Jan 21 01:35:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:35:17 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
Message-ID: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>

On 20 Jan 2010, at 19:29, Darko wrote:

> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.

M3 defines all arithmetic as operating on the base type.  It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.

> You're using the syntax for packed types in your example, but I think they'd have to be subranges.

Sorry, yes. [Jet-lag]

> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.

Agreed!

> 
> 
> 
> On 20/01/2010, at 10:20 PM, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/09ea7216/attachment.html>

From Highjinks at gmx.com  Thu Jan 21 01:50:20 2010
From: Highjinks at gmx.com (Chris)
Date: Thu, 21 Jan 2010 01:50:20 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
Message-ID: <20100120205327.e8547d50.Highjinks@gmx.com>

It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.

Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
Trestle is easy to write for, but it really is butt ugly.

Is anyone else looking at this area of the system?


-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Thu Jan 21 01:58:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:58:44 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <D04D87A0-B24A-4EE3-95AE-90D4F3A78938@cs.purdue.edu>

That would be a great idea.  Given that we are linking with X11R6 anyway...  :-)

On 20 Jan 2010, at 19:50, Chris wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
> 
> Is anyone else looking at this area of the system?
> 
> 
> -- 
> Chris <Highjinks at gmx.com>

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

From hosking at cs.purdue.edu  Thu Jan 21 02:00:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 20:00:39 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
Message-ID: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>

Jay, I don't know what you are talking about there being a bug in TWord.Multiply.

This little program prints out 2, as would be expected:

MODULE Main;
IMPORT RTIO, TInt, TWord, Target;

VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.


On 20 Jan 2010, at 18:59, Tony Hosking wrote:

> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 20 Jan 2010, at 10:05, Jay K wrote:
> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>>  
>>  - Jay
>>  
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>>  
>> > Date: Wed, 20 Jan 2010 16:01:32 +0000
>> > To: m3commit at elegosoft.com
>> > From: jkrell at elego.de
>> > Subject: [M3commit] CVS Update: cm3
>> > 
>> > CVSROOT: /usr/cvs
>> > Changes by: jkrell at birch. 10/01/20 16:01:32
>> > 
>> > Modified files:
>> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
>> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
>> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
>> > 
>> > Log message:
>> > convert much of m3back to use Target.Int instead of INTEGER
>> > This should at least allow it to propagate constant LONGINTs
>> > as well as perhaps otherwise help with implementing LONGINT,
>> > since the virtual stack is now of Target.Int instead of INTEGER
>> > 
>> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>> > 
>> > Also note that there's still a lot of "INTEGER" used.
>> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/2107472c/attachment.html>

From jay.krell at cornell.edu  Thu Jan 21 03:49:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:49:15 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
Message-ID: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>


That would be fine too.
Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
 
  - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:02:33 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; darko at darko.org
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
> What's wrong with:
>
> BITS 64 FOR LONGINT
>
> ?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:20, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:50:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:50:05 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>,
	<87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
Message-ID: <COL101-W1693D675BA116E2C556EF9E6630@phx.gbl>


> Are you constant folding or something?

Exactly.
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 18:50:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] proposed addition m3cg_ops: set_warning_handler
>
>
>
> I don't understand why you need this.
> Why would you have overflows in m3back?
> Are you constant folding or something?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:55, Jay K wrote:
>
> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>
>
> This is so I can report but ignore the overflows when I use TInt in m3back.
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:52:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:52:13 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>


I'll look into it again.
There's definitely a problem somewhere.
 Maybe in my change. Maybe.
 
 
Using TInt.Multiply vs. TWord.Multiply made the difference
between INC() incrementing by zero or the correct amount.
I had some number, I multiplied it by a variable
that also happened to be 1, and I got zero.
This was the only problem I ran into in changing
from INTEGER to Target.Int.
 
 
 - Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>
>
>
>
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>
> This little program prints out 2, as would be expected:
>
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
>
> VAR i := TInt.Two;
> j: Target.Int;
> buf: ARRAY[0..10] OF CHAR;
> BEGIN
> TWord.Multiply (i, TInt.One, j);
> FOR k := 0 TO TInt.ToChars (i, buf) DO
> RTIO.PutChar(buf[k]);
> END;
> RTIO.PutChar('\n');
> RTIO.Flush();
> END Main.
>
>
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 10:05, Jay K wrote:
>
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>
> - Jay
>
> ________________________________
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
>
> diff attached
>
>
>
>
>
>
>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>> To: m3commit at elegosoft.com
>> From: jkrell at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>
>> Modified files:
>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>
>> Log message:
>> convert much of m3back to use Target.Int instead of INTEGER
>> This should at least allow it to propagate constant LONGINTs
>> as well as perhaps otherwise help with implementing LONGINT,
>> since the virtual stack is now of Target.Int instead of INTEGER
>>
>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>
>> Also note that there's still a lot of "INTEGER" used.
>>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:54:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:54:10 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
Message-ID: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>


> I think the idea that "basics" don't change
> meaning doesn't wash because you can't
> make assumptions about what hardware you're
> running on and therefore might be condemning
> the language to inefficiency on certain hardware.
>
> Agreed!

 
The "basics" *for a given target*.
LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
Some other future platform can use 56 bits or 128 bits or whatever.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:35:17 -0500
> To: darko at darko.org
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> On 20 Jan 2010, at 19:29, Darko wrote:
>
> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>
> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>
> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>
> Sorry, yes. [Jet-lag]
>
> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>
> Agreed!
>
>
>
>
> On 20/01/2010, at 10:20 PM, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 04:57:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 03:57:45 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>,
	<5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
Message-ID: <COL101-W404F04F00E1BF980DD7075E6630@phx.gbl>


But you need certain things to not change *per platform* if you expect to be able to link code together and not crash.
Different platforms of course can use different sizes and such.
 
 
It should not be possible to compile one module with one size INTEGER and nother with another size, if they can be linked together.
 
 
Various systems do allow that sort of thing and it is imho a bad idea.
It leads to "ABI bifurcation".
Like, let's say you want to provide a library for use by "anyone".
You end up having to compile it multiple times with various options, so that no matter what your user uses, there is a variant that matches.
Sometimes this stuff gets checked at link time, sometimes not.
 
 
Again this is why the way user threads is an "option" isn't great.
You have to recompile everything if you switch the option.
(I believe there are incrementality bugs here as well; basically many sorts of m3makefile edits are not handled correctly by cm3; for example moving a source file from one package to another..)
 
 
Having [0L .. Long.Shift(1L, 129)] work and use a 128bit LONGINT is a fine idea, agreed. "LONGINT" can indicate "possibly less efficient.
 
 
However, this is again a dangerous change *on preexisting platforms*, because it leads to LAST(LONGINT) changing.
 
 
 - Jay


----------------------------------------
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Thu, 21 Jan 2010 14:34:26 +1100
> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I think you want to get away from concrete representations on particular platforms. All you need to know is that INTEGER is a good, efficient size for the platform, and LONGINT is possibly bigger size but still reasonably efficient. That way the code will compile on any platform and you don't care what size INTEGER or LONGINT is. If this were a Star Wars movie Obiwan would be saying "Use Abstraction, Jay".
>
>
> On 21/01/2010, at 1:54 PM, Jay K wrote:
>
>
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>>
>> Agreed!
>
>
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
>
>
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>>
>>
>>
>> On 20 Jan 2010, at 19:29, Darko wrote:
>>
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>>
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>>
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>>
>> Sorry, yes. [Jet-lag]
>>
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>>
>> Agreed!
>>
>>
>>
>>
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>>
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>>
>>
>> Basically, "platform" or "target" should map to one "ABI".
>>
>>
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>>
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>>
>>
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>>
>>
>> - Jay
>>
>>
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>>
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>>
>>
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>>
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>>
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>>
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>>
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>>
>> Or, again, I should look at the arithemetic library...
>>
>>
>> - Jay
>>
>>
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>>
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>>
>> ...
>>
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>>
>>
>>
>> Hello,
>>
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>>
>> ChangeLog gcc/
>> ....
>>
>>
>>
>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 08:02:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:02:41 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>


Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.

 

 

MODULE Main;
IMPORT RTIO, Target, TInt, TWord;

VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.


 

prints 0.

 

The code in m3back:

 

 

PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...

        (* Beware TWord.Multiply: x * 1 = 0 *)

        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;


 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


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

From jay.krell at cornell.edu  Thu Jan 21 08:14:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:14:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <COL101-W2749C76BB19D4AA0997E77E6630@phx.gbl>


TInt.Multiply is reasonable anyway, since the code wasn't using Word.Multiply but just INTEGER *.

 

 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 07:02:41 +0000
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now



Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply? 
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


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

From hosking at cs.purdue.edu  Thu Jan 21 09:36:24 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:36:24 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
Message-ID: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>

Subranges have a memory size that depends on the size of the subrange.  All arithmetic is performed using the precision of the base type however.

These things are all documented in the language spec.

On 20 Jan 2010, at 21:49, Jay K wrote:

> 
> That would be fine too.
> Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
> 
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:02:33 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; darko at darko.org
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
>> What's wrong with:
>> 
>> BITS 64 FOR LONGINT
>> 
>> ?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 06:20, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Thu Jan 21 09:37:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:37:00 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
Message-ID: <B4981016-C75D-468E-9506-87C48506C00F@cs.purdue.edu>

Agreed, yes, the sizes are in the target definition.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:54, Jay K wrote:

> 
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>> 
>> Agreed!
> 
> 
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> On 20 Jan 2010, at 19:29, Darko wrote:
>> 
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>> 
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>> 
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>> 
>> Sorry, yes. [Jet-lag]
>> 
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>> 
>> Agreed!
>> 
>> 
>> 
>> 
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/8ee49afc/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 21 09:38:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:38:45 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W236A596B7446D4793B7590E6630@phx.gbl>
Message-ID: <1DFF961A-09C7-4BAF-8593-D8128577786D@cs.purdue.edu>

INC is defined on INTEGER values, not Word.T.

I think your problem is somewhere else.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:52, Jay K wrote:

> 
> I'll look into it again.
> There's definitely a problem somewhere.
> Maybe in my change. Maybe.
> 
> 
> Using TInt.Multiply vs. TWord.Multiply made the difference
> between INC() incrementing by zero or the correct amount.
> I had some number, I multiplied it by a variable
> that also happened to be 1, and I got zero.
> This was the only problem I ran into in changing
> from INTEGER to Target.Int.
> 
> 
> - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 20:00:39 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>> 
>> 
>> 
>> 
>> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>> 
>> This little program prints out 2, as would be expected:
>> 
>> MODULE Main;
>> IMPORT RTIO, TInt, TWord, Target;
>> 
>> VAR i := TInt.Two;
>> j: Target.Int;
>> buf: ARRAY[0..10] OF CHAR;
>> BEGIN
>> TWord.Multiply (i, TInt.One, j);
>> FOR k := 0 TO TInt.ToChars (i, buf) DO
>> RTIO.PutChar(buf[k]);
>> END;
>> RTIO.PutChar('\n');
>> RTIO.Flush();
>> END Main.
>> 
>> 
>> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>> 
>> Where's the bug in TWord.Multiply?
>> If there were a bug we would have seen it by now surely?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 10:05, Jay K wrote:
>> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>> 
>> - Jay
>> 
>> ________________________________
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>> 
>>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>>> To: m3commit at elegosoft.com
>>> From: jkrell at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>> 
>>> Log message:
>>> convert much of m3back to use Target.Int instead of INTEGER
>>> This should at least allow it to propagate constant LONGINTs
>>> as well as perhaps otherwise help with implementing LONGINT,
>>> since the virtual stack is now of Target.Int instead of INTEGER
>>> 
>>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>> 
>>> Also note that there's still a lot of "INTEGER" used.
>>> 
>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu Jan 21 09:40:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:40:36 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>

You should not assume that aliasing works for any of these operations.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 02:02, Jay K wrote:

> Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
>  
>  
> MODULE Main;
> IMPORT RTIO, Target, TInt, TWord;
> VAR a,b:Target.Int;
> BEGIN
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
> TWord.Multiply(a, b, a);
> RTIO.PutText(TInt.ToText(a));
> RTIO.Flush();
> END Main.
> 
>  
> prints 0.
>  
> The code in m3back:
>  
>  
> PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
> ...
>         (* Beware TWord.Multiply: x * 1 = 0 *)
>         IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
>           t.Err("doindex_address: multiply overflowed");
>         END;
> 
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
> 
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
> 
> This little program prints out 2, as would be expected:
> 
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
> 
> VAR i := TInt.Two;
>     j: Target.Int;
>     buf: ARRAY[0..10] OF CHAR;
> BEGIN
>   TWord.Multiply (i, TInt.One, j);
>   FOR k := 0 TO TInt.ToChars (i, buf) DO
>     RTIO.PutChar(buf[k]);
>   END;
>   RTIO.PutChar('\n');
>   RTIO.Flush();
> END Main.
> 
> 
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
> 
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> 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 20 Jan 2010, at 10:05, Jay K wrote:
> 
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/90bb8142/attachment.html>

From jay.krell at cornell.edu  Thu Jan 21 09:42:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 08:42:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>,
	<8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
Message-ID: <COL101-W366A4B875AA2D047EF4DE9E6630@phx.gbl>


I changed it to no longer:

 

        IF NOT TInt.Multiply(stop0.imm, tsize, tint) THEN
          t.Err("doindex_address: multiply overflowed");
        END;
        stop0.imm := tint;


 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 03:40:36 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now


You should not assume that aliasing works for any of these operations.



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 21 Jan 2010, at 02:02, Jay K wrote:

Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 



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

From jay.krell at cornell.edu  Thu Jan 21 10:11:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 09:11:24 +0000
Subject: [M3devel] atomics addressing modes, it looks like none needed
Message-ID: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>


I tried a few differnt switches.

They always seem to get the actual address into a register.


C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod


long __cdecl _InterlockedExchange(long volatile*, long);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedIncrement(long volatile*);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedExchangeAdd(long volatile*, long);
#pragma intrinsic(_InterlockedExchangeAdd)

 

 

long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
#pragma intrinsic(_InterlockedCompareExchange)

 

 

long F1(volatile long* a)
{
return _InterlockedIncrement(&a[10]);
}

 


typedef struct S1 { int a; long b; } S1;

long F2(volatile S1* a)
{
return _InterlockedExchangeAdd(&a->b, 123);
}

 


long F3(volatile S1* a)
{
return _InterlockedCompareExchange(&a->b, 1, 2);
}

 


long F4(volatile S1* a)
{
return _InterlockedExchange(&a->b, 1);
}


 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08


        TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
        .686P
        .XMM
        include listing.inc
        .model  flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC  _F1
; Function compile flags: /Ogtpy
; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F1     PROC

; 15   : return _InterlockedIncrement(&a[10]);

  00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
  00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
  00007 b8 01 00 00 00   mov     eax, 1
  0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
  00010 40               inc     eax

; 16   : }

  00011 c3               ret     0
_F1     ENDP
_TEXT   ENDS
PUBLIC  _F2
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F2     PROC

; 23   : return _InterlockedExchangeAdd(&a->b, 123);

  00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
  00029 83 c1 04         add     ecx, 4
  0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax

; 24   : }

  00030 c3               ret     0
_F2     ENDP
_TEXT   ENDS
PUBLIC  _F3
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F3     PROC

; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);

  00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
  00044 b9 01 00 00 00   mov     ecx, 1
  00049 83 c2 04         add     edx, 4
  0004c b8 02 00 00 00   mov     eax, 2
  00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx

; 30   : }

  00055 c3               ret     0
_F3     ENDP
_TEXT   ENDS
PUBLIC  _F4
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F4     PROC

; 35   : return _InterlockedExchange(&a->b, 1);

  00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00064 b8 01 00 00 00   mov     eax, 1
  00069 83 c1 04         add     ecx, 4
  0006c 87 01            xchg    DWORD PTR [ecx], eax

; 36   : }

  0006e c3               ret     0
_F4     ENDP
_TEXT   ENDS
END

C:\dev2\cm3.2\m3-sys\m3back\src>



probably should try IA64 though.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/282ae614/attachment.html>

From jay.krell at cornell.edu  Thu Jan 21 14:29:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 13:29:12 +0000
Subject: [M3devel] fetch_and_op?
Message-ID: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>


(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)



Tony, are you sure you want to return the old value, not the new value?

That's not great on x86.

I believe for "or" and "and", you end up having to do a compare exchange loops.

 

 

For xor, add, sub, you can compute the old value, ok.

But if caller wanted the old value, he can do that himself also.

Caller can also write a compare_exchange loop.

 

 

Therefore, I think it should be:

 

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)


There is of course value in storing the value in mem and stack, since mem

can change right away.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/5268cabb/attachment.html>

From dabenavidesd at yahoo.es  Thu Jan 21 14:57:31 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 13:57:31 +0000 (GMT)
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <512318.52973.qm@web23601.mail.ird.yahoo.com>

Hi all:
I think you could research some deep into gcc lists
http://gcc.gnu.org/ml/gcc/2006-12/msg00467.html 
>From what I read you are getting different results depending of optimization with overflowing

I hope this helps a bit.

El dom, 17/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] in favor of mixed operators..
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 04:38
> 
> 
> 
> 
>  
> http://python-history.blogspot.com/2009/03/problem-with-integer-division.html
> 
> 
> He argues that for a "high level" language, of
> course
> I should be able to add int to long, int to float, etc.
> And that int / int should not be int.
> At least Modula-3 spells them differently, / vs. MOD.
> 
> 
> Of course, "high level" vs. "systems"
> vs. "one size to fit all"...
> 
> 
> Anyway, I give up here.
> 
> 
>  - Jay
> 
> 
> 
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Thu Jan 21 15:21:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:21:22 -0500
Subject: [M3devel] atomics addressing modes, it looks like none needed
In-Reply-To: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
References: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
Message-ID: <1A39E99D-F8A7-4D8A-B1E6-AC9D4A53651E@cs.purdue.edu>

OK, so no indexed mode?  gcc may generate it differently.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 04:11, Jay K wrote:

> I tried a few differnt switches.
> They always seem to get the actual address into a register.
> 
> C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod
> 
> long __cdecl _InterlockedExchange(long volatile*, long);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedIncrement(long volatile*);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedExchangeAdd(long volatile*, long);
> #pragma intrinsic(_InterlockedExchangeAdd)
>  
>  
> long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
> #pragma intrinsic(_InterlockedCompareExchange)
>  
>  
> long F1(volatile long* a)
> {
> return _InterlockedIncrement(&a[10]);
> }
>  
> 
> typedef struct S1 { int a; long b; } S1;
> long F2(volatile S1* a)
> {
> return _InterlockedExchangeAdd(&a->b, 123);
> }
>  
> 
> long F3(volatile S1* a)
> {
> return _InterlockedCompareExchange(&a->b, 1, 2);
> }
>  
> 
> long F4(volatile S1* a)
> {
> return _InterlockedExchange(&a->b, 1);
> }
> 
>  
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
> t.c
> ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08
> 
>         TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
>         .686P
>         .XMM
>         include listing.inc
>         .model  flat
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
> PUBLIC  _F1
> ; Function compile flags: /Ogtpy
> ; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F1     PROC
> ; 15   : return _InterlockedIncrement(&a[10]);
>   00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
>   00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
>   00007 b8 01 00 00 00   mov     eax, 1
>   0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
>   00010 40               inc     eax
> ; 16   : }
>   00011 c3               ret     0
> _F1     ENDP
> _TEXT   ENDS
> PUBLIC  _F2
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F2     PROC
> ; 23   : return _InterlockedExchangeAdd(&a->b, 123);
>   00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
>   00029 83 c1 04         add     ecx, 4
>   0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
> ; 24   : }
>   00030 c3               ret     0
> _F2     ENDP
> _TEXT   ENDS
> PUBLIC  _F3
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F3     PROC
> ; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);
>   00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
>   00044 b9 01 00 00 00   mov     ecx, 1
>   00049 83 c2 04         add     edx, 4
>   0004c b8 02 00 00 00   mov     eax, 2
>   00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx
> ; 30   : }
>   00055 c3               ret     0
> _F3     ENDP
> _TEXT   ENDS
> PUBLIC  _F4
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F4     PROC
> ; 35   : return _InterlockedExchange(&a->b, 1);
>   00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00064 b8 01 00 00 00   mov     eax, 1
>   00069 83 c1 04         add     ecx, 4
>   0006c 87 01            xchg    DWORD PTR [ecx], eax
> ; 36   : }
>   0006e c3               ret     0
> _F4     ENDP
> _TEXT   ENDS
> END
> C:\dev2\cm3.2\m3-sys\m3back\src>
> 
> 
> probably should try IA64 though.
>  
>  
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/9a2587ee/attachment.html>

From hosking at cs.purdue.edu  Thu Jan 21 15:23:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:23:59 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
Message-ID: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 08:29, Jay K wrote:

> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 

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

From dabenavidesd at yahoo.es  Thu Jan 21 15:28:50 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 14:28:50 +0000 (GMT)
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs. head?
In-Reply-To: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>
Message-ID: <1444.87625.qm@web23608.mail.ird.yahoo.com>

Hi:
this problem was present in the code since some time ago, even before merge original cvsup sources in cm3 tree. You could see a how to repeat detailed here:
http://aivwiki.alma.cl/index.php/Installing_CVSup
This wiki entry has more than a year of existence.
I couldn't deep more because because some time ago I repeated the sequence and got the same result (first try works, and background doesn't). But not too long ago I repeated and got even worse the first attempt (non-background process didn't work) neither background so I just guessed something could be wrong on both cases with LINUXLIBC6 systems.

Please could you give me some pointers to build CM3 system with user threads on AMD64_LINUX or LINUXLIBC6 to see if this repeats 

Thanks in advance

--- El dom, 17/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release vs. head?
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 11:13
> On 17 Jan
> 2010, at 08:42, Jay K
> wrote:
> We can stick
> with the current release branch if that is indeed much
> easier.
> 
> 
> I thought there was some agreement we shouldn't release
> LONGINT as it was.
> 
> Indeed!
> I can undo the
> changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff
> or diff (again, cvs
> seems not to help).
> 
> Surely we can move forward on this.
> Many/most/all of
> the fixes went first into head, so there's
> "nothing" to merge back,
> but diff tells us better.
> 
> I agree.
> I'm still
> planning on setting up some more machines and can do
> FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them
> first...)
> 
> Let's not worry about additional
> targets. 
> Does anyone have
> the missing steps for the cvsup bug report, like the
> configuration file,
> can show the callstacks, try it with user threads..etc..?
> 
> Maybe cvsup should not be part of the
> release?
> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 -->
> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat
> selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what
> varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more
> or less
> > a nightmare. We cannot make incompatible extensions to
> the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT
> changes into the
> > next release would be to start anew. Meaning declaring
> 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of
> course we'd
> > have to carefully merge back any fixes that might be
> missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the
> energy to do all
> > that cleanly. I didn't even get round to set up
> release builds
> > on new.elego.de via Hudson in
> order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my
> home machine's
> > complete crash in December. So the release engineering
> support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate
> release,
> > but somebody really needs to do all the housekeeping
> of comparing
> > and merging branches. And we shouldn't start a new
> release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the
> release engineering
> > tasks (including Hudson management and re-targeting to
> the new release)?
> > 
> > Please keep in mind that we haven't managed to get
> out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869
> fax: +49 30 23 45 86 95
> > http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> > 
> 
> 


      


From hendrik at topoi.pooq.com  Thu Jan 21 19:02:29 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:02:29 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
Message-ID: <20100121180229.GA13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
> Subranges have a memory size that depends on the size of the subrange.  
> All arithmetic is performed using the precision of the base type 
> however.

If the compiler can prove it makes no difference, shorter arithmetic is 
sometimes possible.

-- hendrik


From hendrik at topoi.pooq.com  Thu Jan 21 19:14:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:14:56 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <20100121181456.GC13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. 
> Bring the X interface up to date(X11R6) and support things like DRM, 
> XRandr, etc... And update OpenGL for NURBS, VBOs, etc...

I hear the OpenGL itself is undergoing massive change at the moment.  We 
may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
told, no longer deals in individual triangles, squares, and the like, 
but only in arrays of same, to better use graphic card parallelism.

-- hendrik


From peter.mckinna at gmail.com  Thu Jan 21 20:33:54 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 22 Jan 2010 06:33:54 +1100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>

I've been looking at this area a bit. I have just completed the interface to
GLUT which should be ready to commit in a few weeks as soon as i get a few
more examples tested. This gives you the conventional opengl/X linking. Its
taken a while to get my head around swig which seems a better way to feed
into the C world. I have also nearly completed a new interface for mysql
giving it a safe M3 interface and gives the complete mysql.h api. I was
thinking of using swig for the gtk bindings but not sure how well the c++
mappings are handled

regards Peter

On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui
> haven't been touched or updated since the early 90s.
>
> Seems like modernising it might attract some more developers. i.e. Bring
> the X interface up to date(X11R6) and support things like DRM, XRandr,
> etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
>
> Is anyone else looking at this area of the system?
>
>
> --
> Chris <Highjinks at gmx.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/fe7d8419/attachment.html>

From jay.krell at cornell.edu  Thu Jan 21 23:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 22:30:00 +0000
Subject: [M3devel] fetch_and_op?
In-Reply-To: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
Message-ID: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>


ok.

 

But notice that they offer both forms really since they also have "modifying asignment operators".
Is that useful/possible to expose?

 


http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html

 


"The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "

 


For now I'll probably just expose add, sub, xor, but not or and and.
We can do them later via a compareexchange loop (see winbase.h which
does something similar for different reasons: lack of intrinsics).

 


Still a ways away from calling this done, because modifying
m3x86.m3 so far requires a lot of guessing/patternmatching.
I don't understand e.g. what "locked" means (not the
one I introduced, what was there).

 


 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 09:23:59 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] fetch_and_op?

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.




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 21 Jan 2010, at 08:29, Jay K wrote:

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)


Tony, are you sure you want to return the old value, not the new value?
That's not great on x86.
I believe for "or" and "and", you end up having to do a compare exchange loops.
 
 
For xor, add, sub, you can compute the old value, ok.
But if caller wanted the old value, he can do that himself also.
Caller can also write a compare_exchange loop.
 
 
Therefore, I think it should be:
 
(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)

There is of course value in storing the value in mem and stack, since mem
can change right away.
 
 
 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/0f3714c0/attachment.html>

From dragisha at m3w.org  Thu Jan 21 23:27:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 21 Jan 2010 23:27:12 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
Message-ID: <1264112832.3531.22.camel@faramir.m3w.org>

Modernizing of GUI is not so big a problem - lots of C(++) libraries
around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
- there's nothing like a manual touch! And I've wrapped pthreads, mysql,
sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.

Modula-3 philosophy (at least it looks to me sometimes) is to think
about Modula-3 legacy libraries/project like it's something carved in
stone... To be kosher we must use right (legacy of course and
all-platforms of coursier :)) libraries for every job.... Nice idea, esp
when we whink longer term maintenance... But what made projects like,
for example, Linux desktop successful is not single solution path - it's
diversity of possible solutions.

Main problem with diversity of solutions is multi-platform nature of
Modula-3 - solutions not multi-platform are not likely to be accepted...
And while it's relatively easy to wrte your Modula-3 code multiplatfom,
taking care of C(++) libraries can be real pain....

Thus said - I can tell you one thing - JUST DO IT :). I don't see a
problem if my projects work only on Linux - once I have incentive to go
through a hassle to make it work on Windows, I'll synchronize. But it's
important to to many things with Modula-3 - more will come a lot easier.

On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> I've been looking at this area a bit. I have just completed the
> interface to GLUT which should be ready to commit in a few weeks as
> soon as i get a few more examples tested. This gives you the
> conventional opengl/X linking. Its taken a while to get my head around
> swig which seems a better way to feed into the C world. I have also
> nearly completed a new interface for mysql giving it a safe M3
> interface and gives the complete mysql.h api. I was thinking of using
> swig for the gtk bindings but not sure how well the c++ mappings are
> handled 
>  
> regards Peter 
> 
> 
> On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
>         It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
>         in m3-ui haven't been touched or updated since the early 90s.
>         
>         Seems like modernising it might attract some more developers.
>         i.e. Bring the X interface up to date(X11R6) and support
>         things like DRM, XRandr, etc... And update OpenGL for NURBS,
>         VBOs, etc...
>         Trestle is easy to write for, but it really is butt ugly.
>         
>         Is anyone else looking at this area of the system?
>         
>         
>         --
>         Chris <Highjinks at gmx.com>
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Fri Jan 22 00:23:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 18:23:52 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100121180229.GA13592@topoi.pooq.com>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
Message-ID: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>

Possibly, but it would require some fairly strong type analysis in the compiler.  And of course it is not fully general.

On 21 Jan 2010, at 13:02, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
>> Subranges have a memory size that depends on the size of the subrange.  
>> All arithmetic is performed using the precision of the base type 
>> however.
> 
> If the compiler can prove it makes no difference, shorter arithmetic is 
> sometimes possible.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Fri Jan 22 01:02:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 19:02:25 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
	<COL101-W444844DDB04656E4B49275E6630@phx.gbl>
Message-ID: <433C7056-D71E-4A01-8C82-7B3F44FC363F@cs.purdue.edu>

Wrong link.  I'm talking C not C++.

Here's the C link:

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf

PS I am shortly about to change the specs on compare exchange in M3CG_Ops.i3.  Stay tuned.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 17:30, Jay K wrote:

> ok.
>  
> But notice that they offer both forms really since they also have "modifying asignment operators".
> Is that useful/possible to expose?
>  
> 
> http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html
>  
> 
> "The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "
>  
> 
> For now I'll probably just expose add, sub, xor, but not or and and.
> We can do them later via a compareexchange loop (see winbase.h which
> does something similar for different reasons: lack of intrinsics).
>  
> 
> Still a ways away from calling this done, because modifying
> m3x86.m3 so far requires a lot of guessing/patternmatching.
> I don't understand e.g. what "locked" means (not the
> one I introduced, what was there).
>  
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 21 Jan 2010 09:23:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] fetch_and_op?
> 
> I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.
> 
> 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 21 Jan 2010, at 08:29, Jay K wrote:
> 
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 
> 
> 

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

From Highjinks at gmx.com  Fri Jan 22 01:29:35 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 01:29:35 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100121181456.GC13592@topoi.pooq.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<20100121181456.GC13592@topoi.pooq.com>
Message-ID: <20100121203246.25046ad5.Highjinks@gmx.com>

On Thu, 21 Jan 2010 13:14:56 -0500
hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers. i.e. 
> > Bring the X interface up to date(X11R6) and support things like DRM, 
> > XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> 
> I hear the OpenGL itself is undergoing massive change at the moment.  We 
> may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
> told, no longer deals in individual triangles, squares, and the like, 
> but only in arrays of same, to better use graphic card parallelism.
> 
> -- hendrik

Definitely a chore. As an excercise I plan to start porting the NeHe tutorials over to Modula 3. However, a big question for me is where to begin.

Idealy an application written to the older standards should still be able to compile and run on new cards, which MIGHT mean mapping the current bindings over top a set bindings to the new standards. We'll see how the standards board deals with that issue.

Also upgrading the X bindings will also be a challenge. The nice thing about the current X window system is that it's far more modular than the X11R4 in the current library. That should make it easier to upgrade the interface systematically, one piece at a time.
-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 12:55:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 11:55:29 +0000
Subject: [M3devel] NT386 div/mod
Message-ID: <COL101-W5358CF13F1BCC0A6C02A8DE6620@phx.gbl>


It is interesting to note that NT386 doesn't use the m3_mod/div functions, but generates inline code:

 

PROCEDURE diffdivOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>
    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*   MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*   XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*   JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*   XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*   CDQ               *)
    END;
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*   JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab        *)
    noargOp(t, Op.oCDQ);                              (*   CDQ               *)
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*   CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*   JE  endlab        *)
    decOp(t, t.reg[EAX]);                             (*   DEC EAX           *)
    set_label(t, endlab);                             (* .endlab             *)
  END diffdivOp;

 

PROCEDURE diffmodOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>

    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*    MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*    XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*    JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*    XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*    CDQ               *)
    END;
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*    JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab         *)
    noargOp(t, Op.oCDQ);                              (*    CDQ               *)
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*    CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*    JE  endlab        *)
    binOp(t, Op.oADD, t.reg[EDX], divisor);           (*    ADD EDX, divisor  *)
    set_label(t, endlab);                             (* .endlab              *)
  END diffmodOp;


 

I haven't tested it yet, but of course you can see that same signed inputs are simpler, like with the code in hand.c.

I'm really starting to like CARDINAL and not INTEGER. :)

(Plus the subtlety that CARDINAL has a default initialization to 0 that Tony told me about.)

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/5bf37fec/attachment.html>

From jay.krell at cornell.edu  Fri Jan 22 13:05:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:05:10 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>


 > Linux desktop successful 

 

Haha. Military intelligence.

 

 

 > it's diversity of possible solutions.

 

Chaos! Lack of interop. Duplicated effort.

Granted, Darwinism/Capitalism, but very wasteful.

 


 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 


 

I'm sure we can win here, if we do anything.

  (I'm not volunteering. The idea of using Swig is good.)

Just wrap Qt or FLTK or Tk or wxWidgets or such.

Qt is my preferred.

  It seems to have the most active resources spent on it and

  is in the best condition already.

GTk on Windows doesn't seem to get enough attention.

Tk has a seemingly good track record in that

 people have successfully used it already from several

 languages: Python, Perl, Tcl (blech!), C.

wxWidgets also has Python bindings at least.

 

 

Things only get less clear if you worry about non Win32/64/XWindows

platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.

And Trestle doesn't support any of those anyway, and they are all

"obsolete" except non-X Mac (see also: iPhone!)

I'm surprised I haven't see that Qt supports iPhone.

If a library does support Carbon/Cocoa that is a point in favor imho.

 


 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/ad0b88a8/attachment.html>

From jay.krell at cornell.edu  Fri Jan 22 13:11:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:11:47 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W10C5CCBC345BFB0C3AF22DE6620@phx.gbl>


> > Trestle is easy to write for, but it really is butt ugly.


 

I should point that making Trestle not look ugly is perhaps

a much smaller task than wrapping any other library.

 

 

Randy's Win32 changes to Trestle definitely make it look better for example.

 

 

It was previously asserted that X Trestle shall not look like Win32.

However, X Trestle doesn't look like anything except itself, right?

So I figure Win32 is among the good choices.

Besides, given that there is no "standard X look", even if X Trestle

does look like *something*, Win32 would still be preferable.

(This would remove the forking we have where only one fork

or another has a bug, X vs. Win32..really need to merge/refactor

that code, no matter the decision and the resulting look..)

 

 - Jay

 


From: jay.krell at cornell.edu
To: dragisha at m3w.org; peter.mckinna at gmail.com
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Modernising m3-ui?
Date: Fri, 22 Jan 2010 12:05:10 +0000



 > Linux desktop successful 
 
Haha. Military intelligence.
 
 
 > it's diversity of possible solutions.
 
Chaos! Lack of interop. Duplicated effort.
Granted, Darwinism/Capitalism, but very wasteful.
 

 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 

 
I'm sure we can win here, if we do anything.
  (I'm not volunteering. The idea of using Swig is good.)
Just wrap Qt or FLTK or Tk or wxWidgets or such.
Qt is my preferred.
  It seems to have the most active resources spent on it and
  is in the best condition already.
GTk on Windows doesn't seem to get enough attention.
Tk has a seemingly good track record in that
 people have successfully used it already from several
 languages: Python, Perl, Tcl (blech!), C.
wxWidgets also has Python bindings at least.
 
 
Things only get less clear if you worry about non Win32/64/XWindows
platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.
And Trestle doesn't support any of those anyway, and they are all
"obsolete" except non-X Mac (see also: iPhone!)
I'm surprised I haven't see that Qt supports iPhone.
If a library does support Carbon/Cocoa that is a point in favor imho.
 

 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/9a1ddafa/attachment.html>

From jay.krell at cornell.edu  Fri Jan 22 13:39:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:39:21 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
Message-ID: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>


Anyone have any thoughts on how to implement LONGINT on NT386?

 


The code is setup to do pretty good constant folding and enregistration.

 


I did the work so that constant folding should work for LONGINT.

 


However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 

In particular, there is still this notion of an "operand"
that might be held in one register.


 

I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.

 


96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.


 

Returning LONGINT from a function also needs separate attention.

Maybe I really should go ahead and use an array of registers?

 


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/5c313ffc/attachment.html>

From hosking at cs.purdue.edu  Fri Jan 22 15:49:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 09:49:28 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
Message-ID: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>

That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.

On 22 Jan 2010, at 07:39, Jay K wrote:

> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/191742a5/attachment.html>

From hendrik at topoi.pooq.com  Fri Jan 22 20:13:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 22 Jan 2010 14:13:14 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
	<DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
Message-ID: <20100122191314.GA6271@topoi.pooq.com>

On Thu, Jan 21, 2010 at 06:23:52PM -0500, Tony Hosking wrote:
> Possibly, but it would require some fairly strong type analysis in the 
compiler.

Analysis that could be done during code generation.

>  And of course it is not fully general.

Of course.  Optimisations only work when they can be proved to.  But 
when they do work, they can make a lot of difference.

-- hendrik


From rodney_bates at lcwb.coop  Fri Jan 22 20:56:37 2010
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Fri, 22 Jan 2010 19:56:37 -0000 (GMT)
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
Message-ID: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>

>
> So..I have m3back using Target.Int a bunch.
>
> And converting back and forth some between Target.Int and
>
> INTEGER and doing match with Target.Int.
>
> And various operations can fail.
>
>
>
>
>
> And my current diff results in:
>
>
>
>
>
>   new source -> compiling Lex.m3
>   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
>   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
>   2 errors encountered
>   new source -> compiling Scan.i3
>
>
>
>
>
>   which is nice to see, it means my code is actually running.
>
>
>
>
>
>   So I look at the code in question:
>
>
>
>
>
>   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> Word.T
>   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> ...
>
>     IF signed AND
>        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
>         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
>       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> ....
>
>
>
>
>
> -FIRST(INTEGER).
>
>
>
>
>
> What is that supposed to do?
>
>
>
>
>
> I mean, I kind of know, I'm slightly playing stupid, partly not.
>
> Does the compiler know what is an INTEGER vs. what is a "Word"?
  ---------------------------------------------------------Word.T?

No, they are the same type.

> Or it is just obligated to assume everything is a Word?

It is obligated to do the builtin operators (unary - being one
of these) using signed interpretation of the value and functions
in Word using unsigned interpretation.

The signed operators don't assume anything about the machine
representation.  The functions in Word do assume two-s complement
binary, in order to be defined.  This is a low-level facility.

>  To do the negation at compile time and ignore the overflow?

This may be poorly specified.  The code sample you cite clearly assumes
this is what it does.  The compile errors indicate the assumption
has become wrong.

> Does the language need work here?

Overflow detection wars!  But surely, we could agree that compile time
arithmetic should do the same thing as runtime would, for a given
implementation.

> I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

Yes, it's a statically unconditional overflow, and the language doesn't
specify what happens.

As long as we are assuming two-s complement binary, I would just remove
the - in front of FIRST(INTEGER). If the compiler does not consider it
and overflow error and wraps around, in this particular case, the - is
an identity operation on the bits.  Maybe the writer intended the -
to hint to a human reader that unsigned interpretation is about to be
applied to this value.

>
>
>
>
>  - Jay
>
>
>




From Highjinks at gmx.com  Fri Jan 22 22:09:53 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 22:09:53 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
Message-ID: <20100122171259.f8cdc16c.Highjinks@gmx.com>

My opinion on what to do as far as these libs are concerned...

First, we should just stick to updating what's already there, right? Add bindings to Xrandr, XCBlib, Cairo, etc.. in a new X11R6 directory. Break down that X.i3 file into several smaller modules. Major changes should wait till later. Bindings to QT, GTK, etc.. are good ideas, but should be OPTIONAL, not required. Undoubtedly many platforms that will be running Modula 3 applications will not have one or either of these libraries installed.
Theres also the possibility of building our own Windowing toolkit. We already have Trestle. Maybe call it "Beam"?

The same with OpenGL. Point in case, MiniGLX. Theres a good chance that any platform using MiniGLX will not have X Windows, or any other Windowing environment installed. 

Consider embedded and kiosk environments. Modula 3 is well suited to these sorts of applications, but these environments are usually limited in the size and scope of the libraries and code they can run.

Later on, we could extend Trestle and even create our own Scenegraph library for OpenGL, if it makes sense to do so.  Hrrrmmm...Call the Scenegraph lib "Ray"?

I have a little free time coming up this weekend. I'll be porting some of the demos I have over to OpenGL, and doing a little M3/XCBlib hacking. Anyone want me to post these up somewhere, for the "lulz" as it were?

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 23:51:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:51:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
Message-ID: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>


I think there is a language hole here.The language should perhaps allow forunsigned literals and unsigned constantexpressions.

Something I don't quite have my head around as well,maybe a language/library hole, is how to doe.g. the below, without assuming two's complementrepresentation of signed integers.

Can we maybe add Word.AbsoluteValueOfInteger?The implementation would, roughly:  IF i < 0 THEN     i := -i;  END;  RETURN i;  END;
with the extra qualification that overflow is silent

 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.
Uh huh. This is why you need *different types* (or interfaces)for the variety of integer overflow behavior and not a runtimesetting. Otherwise the compiler can't know what theruntime behavior is.

As well, using static typing instead of a runtime setting,allows for efficiency. Imagine, say, if x86 does requireextra code to check for overflow.Well, if using "integer-with-silent-overflow", thatwould be omitted. If using "integer-with-overflow"the code would be included.

I introduce the error. It used to be silent.I changed it to a warning, for thevery specific case of negating FIRST(INTEGER).Any other overflow here, which is probably notpossible, will still error.
 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> >   new source -> compiling Lex.m3
> >   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> >   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> >   2 errors encountered
> >   new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> >   which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> >   So I look at the code in question:
> >
> >
> >
> >
> >
> >   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> >   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> >     IF signed AND
> >        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> >         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> >       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
>   ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation.  The functions in Word do assume two-s complement
> binary, in order to be defined.  This is a low-level facility.
> 
> >  To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified.  The code sample you cite clearly assumes
> this is what it does.  The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars!  But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits.  Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> >  - Jay
> >
> >
> >
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/e3ab2126/attachment.html>

From jay.krell at cornell.edu  Fri Jan 22 23:53:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:53:41 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W56A6FF0AF064BA0D485D6DE6620@phx.gbl>


I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/14d9d0fe/attachment.html>

From hosking at cs.purdue.edu  Sat Jan 23 00:52:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 18:52:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
Message-ID: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>

There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.

Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.

Constant expressions:

CONST x = Word.Plus(16_FFFF, 1)


On 22 Jan 2010, at 17:51, Jay K wrote:

> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/2b9bcb0a/attachment.html>

From jay.krell at cornell.edu  Sat Jan 23 06:00:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 05:00:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W286ECA1F5DDC64BBA034F7E6610@phx.gbl>


Sorry, not literals.

 

How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?

 

How do I express -FIRST(INTEGER)? Without incurring signed overflow

while evaluating the constant expression?

 

For a one's complement system, nothing wrong with -FIRST(INTEGER).

  It equals LAST(INTEGER).

 

But for a two's complement system, evaluating -FIRST(INTEGER)

 incurs overflow.

 

Maybe:

 Word.Add(-(FIRST(INTEGER) + 1)), 1)

 

?

 

Probably. I'll try that.

 

You know, C has the same dilemna and similar solution.

not a great idea to write

unsigned u = (unsigned)-INT_MIN;

 

nor

 

unsigned u = -(unsigned)INT_MIN;

 

though the second is maybe ok.

The first incurs signed overflow in C as well.

Which isn't defined. The first also gets a warning

with some compilers: "negating unsigned is still unsigned".

 

An idiom is

unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;

 

derivation:

INT_MIN + 1 yields a negative number that can be safely negated.

Which yields a positive number one less than the desired value.

 

 

 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here.
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100123/8dcb02d6/attachment.html>

From dragisha at m3w.org  Sat Jan 23 11:53:28 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 11:53:28 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244008.3883.777.camel@faramir.m3w.org>

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
>  > Linux desktop successful 
>  
> Haha. Military intelligence.

Orders of magnitude more than yours and mine favorite project.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sat Jan 23 12:06:04 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 12:06:04 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244764.3883.803.camel@faramir.m3w.org>

What SWiG does is only tiniest possible piece of work. Modula-3's way is
not about accepting somebody's (especially C-world's) ideas on
modularity/API's/... and mappping variables/procedures/functions/... to
Modula-3 ones. C world  API's are more or less nightmare, my "favourite"
being pthreads which is full of compromises made to get (mainly) Sun's
signature on standard... sqlite3 is another one not too away from....

But, of course, it's everybody's right to spend her time SWiG-ging
around :)... Me, after tons of experience with it, I'll continue to work
mostly by hand. Automated solutions we need aren't in SWiG... To make,
for example, proper Modula-3 objects from Gtk gobjects, we need custom
conversions...

I've already dipped into this with Gtk and it's enlightening... It's
customary in Python/Perl (h2def, gtkdoc) world to use regexps for
parsing.... When I saw it first I smiled, but when I tried two different
tools and got same buggy output, it became more serious :). 

What we need to exploit widely available C libraries is good and
proper .h parser, and then some tools to rewrite them into Modula-3...
What SWiG offers is one posibility, but we need someone proficient with
Modula-3 to join them - first guy who tried it went Haskell some time
ago.

dd

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
> > Main problem with diversity of solutions is multi-platform nature
> of 
>  > Modula-3 - solutions not multi-platform are not likely to be
> accepted... 
> 
>  
> I'm sure we can win here, if we do anything.
>   (I'm not volunteering. The idea of using Swig is good.)
> Just wrap Qt or FLTK or Tk or wxWidgets or such.
> Qt is my preferred.
-- 
Dragi?a Duri? <dragisha at m3w.org>



From m3 at sol42.com  Sat Jan 23 12:17:07 2010
From: m3 at sol42.com (Daniel Solaz)
Date: Sat, 23 Jan 2010 12:17:07 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
Message-ID: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>

I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.

Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.

Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.

Regards.
-Daniel

From jay.krell at cornell.edu  Sat Jan 23 16:31:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 15:31:38 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>


 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000








I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From jay.krell at cornell.edu  Sat Jan 23 20:30:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 19:30:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>


Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?

As well, should we go the extra bit and disallow it even if it doesn't overflow?
  ie: on one's complement?

 

 

I already disallow it in some code -- depending on which code gets

hit in the backend. But this disallowing is new.

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
Date: Sat, 23 Jan 2010 05:00:34 +0000



Sorry, not literals.
 
How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
 
How do I express -FIRST(INTEGER)? Without incurring signed overflow
while evaluating the constant expression?
 
For a one's complement system, nothing wrong with -FIRST(INTEGER).
  It equals LAST(INTEGER).
 
But for a two's complement system, evaluating -FIRST(INTEGER)
 incurs overflow.
 
Maybe:
 Word.Add(-(FIRST(INTEGER) + 1)), 1)
 
?
 
Probably. I'll try that.
 
You know, C has the same dilemna and similar solution.
not a great idea to write
unsigned u = (unsigned)-INT_MIN;
 
nor
 
unsigned u = -(unsigned)INT_MIN;
 
though the second is maybe ok.
The first incurs signed overflow in C as well.
Which isn't defined. The first also gets a warning
with some compilers: "negating unsigned is still unsigned".
 
An idiom is
unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
 
derivation:
INT_MIN + 1 yields a negative number that can be safely negated.
Which yields a positive number one less than the desired value.
 
 
 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here. 
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100123/8d175afb/attachment.html>

From Highjinks at gmx.com  Sat Jan 23 23:02:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 23 Jan 2010 23:02:22 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
Message-ID: <20100123180535.9ee26d0e.Highjinks@gmx.com>

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hendrik at topoi.pooq.com  Sat Jan 23 23:13:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:13:35 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <20100123221335.GC6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> 
> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> 
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?

The only reason for disallowing it is overflow, and then only for an 
implementation that checks overflow.  But if it doesn't overflow, 
it doesn't overflow, and it's valid.

-- hendrik

> I already disallow it in some code -- depending on which code gets
> 
> hit in the backend. But this disallowing is new.

It might warrant a portability warning, if we issue such.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan 23 23:15:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:15:03 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <20100123221503.GD6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
> 
> > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> > 
> > Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > 
> > Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> > 
> > Regards.
> > -Daniel
> 
> Good points.
> 
> I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> 
> Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> 
> So, bindings are the way to start at least. Alright then. Time to get hacking.

Especially bindings to subsystems and toolkits that are available in a 
variety fo platforms.

-- hendrik

> -- 
> Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Sun Jan 24 01:35:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:35:18 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123221503.GD6033@topoi.pooq.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>,
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<20100123221503.GD6033@topoi.pooq.com>
Message-ID: <COL101-W45BB63A36E65A8F0A9421E6600@phx.gbl>


 > wraps the native toolkit on each platform

 

I don't think wrapping native is the way to go.

Too much work to then have a common interface.


> Especially bindings to subsystems and toolkits that are available in a variety fo platforms.

 

 

Yes.

E.g. Qt, FLTK, Tk, etc.

I think Qt is the best, based on highly non-scientific data.

 

 

- Jay
 
> Date: Sat, 23 Jan 2010 17:15:03 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> > On Sat, 23 Jan 2010 12:17:07 +0100
> > Daniel Solaz <m3 at sol42.com> wrote:
> > 
> > > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets. Where there is no single native toolkit, choose the best or most used. Portability, full interoperability and looking/feeling native are the key points here.
> > > 
> > > Developing a new toolkit in pure Modula-3 is a waste of effort. Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on. Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect. SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > > 
> > > Making Trestle look good will only get us so far. I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts. Text handling comes to mind, and scrollbars too.
> > > 
> > > Regards.
> > > -Daniel
> > 
> > Good points.
> > 
> > I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> > 
> > Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> > 
> > So, bindings are the way to start at least. Alright then. Time to get hacking.
> 
> Especially bindings to subsystems and toolkits that are available in a 
> variety fo platforms.
> 
> -- hendrik
> 
> > -- 
> > Chris <Highjinks at gmx.com>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/9217803c/attachment.html>

From jay.krell at cornell.edu  Sun Jan 24 01:45:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:45:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>,
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>,
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <COL101-W78609AC77B82C715B3289E6600@phx.gbl>


What I meant was..like..hypothetically..if we had a one's complement

target, would we error for -FIRST(INTEGER), since it would

overflow on other systems. Nevermind.

 

 

 - Jay 

 

> Date: Sat, 23 Jan 2010 17:13:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> CC: hendrik at topoi.pooq.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> > 
> > Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> > 
> > As well, should we go the extra bit and disallow it even if it doesn't overflow?
> > ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow. But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
> > I already disallow it in some code -- depending on which code gets
> > 
> > hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/563207ef/attachment.html>

From darko at darko.org  Sun Jan 24 02:59:26 2010
From: darko at darko.org (Darko)
Date: Sun, 24 Jan 2010 12:59:26 +1100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <3E4F467C-0634-4566-9248-CC1D1F79EC64@darko.org>

Here is the Cairo API done in M3 and I have a few others. I'd like to promote this style of naming, where prefixes matching the interface name are removed, so CairoSave in C becomes Cairo.Save in M3.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cairo.i3
Type: application/octet-stream
Size: 21401 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/51166a02/attachment.obj>
-------------- next part --------------



On 24/01/2010, at 9:02 AM, Chris wrote:

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Sun Jan 24 10:23:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:23:29 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <6F19D0A2-AAE4-4268-AACE-7F24E348A122@cs.purdue.edu>

I still don't understand what is broken here...

On 23 Jan 2010, at 14:30, Jay K wrote:

> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?
>  
>  
> I already disallow it in some code -- depending on which code gets
> hit in the backend. But this disallowing is new.
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
> Date: Sat, 23 Jan 2010 05:00:34 +0000
> 
> Sorry, not literals.
>  
> How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
>  
> How do I express -FIRST(INTEGER)? Without incurring signed overflow
> while evaluating the constant expression?
>  
> For a one's complement system, nothing wrong with -FIRST(INTEGER).
>   It equals LAST(INTEGER).
>  
> But for a two's complement system, evaluating -FIRST(INTEGER)
>  incurs overflow.
>  
> Maybe:
>  Word.Add(-(FIRST(INTEGER) + 1)), 1)
>  
> ?
>  
> Probably. I'll try that.
>  
> You know, C has the same dilemna and similar solution.
> not a great idea to write
> unsigned u = (unsigned)-INT_MIN;
>  
> nor
>  
> unsigned u = -(unsigned)INT_MIN;
>  
> though the second is maybe ok.
> The first incurs signed overflow in C as well.
> Which isn't defined. The first also gets a warning
> with some compilers: "negating unsigned is still unsigned".
>  
> An idiom is
> unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
>  
> derivation:
> INT_MIN + 1 yields a negative number that can be safely negated.
> Which yields a positive number one less than the desired value.
>  
>  
>  - Jay
> 
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 18:52:05 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.
> 
> Literals:
> 
> If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.
> 
> Constant expressions:
> 
> CONST x = Word.Plus(16_FFFF, 1)
> 
> 
> On 22 Jan 2010, at 17:51, Jay K wrote:
> 
> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/1c654099/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 24 10:24:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:24:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>

Agreed.  If we allow overflow at run-time we should at compile-time.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 17:13, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
>> 
>> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
>> 
>> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>>  ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow.  But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
>> I already disallow it in some code -- depending on which code gets
>> 
>> hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/001d7332/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 24 10:25:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:25:07 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
	<COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
Message-ID: <283D5C6F-607F-47E1-A53A-BFE01EA3018D@cs.purdue.edu>

Yes, I meant the machine stack for LONGINT values.  Regs only for INTEGER.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 10:31, Jay K wrote:

>  > You might easily just push/pop operands and return values on the stack
> 
> I don't think I understood you.
> My "worst case" was to store everything in temporaries.
> But I think I see now.
> Some sort of stack is required.
> There is the "virtual stack" already in use. (I assume "v" = "virtual").
>    It should already handle constant folding, but its register manipulation isn't right for 64bit values.
> I think what I see now -- just use the machine stack.
> Even to push immediate values.
> And, to be really lame, most/all operations can be function calls.
>  And not even in the "normal" way, but like:
> 
> 
> #ifdef _WIN32
> 
> 
> void __stdcall m3_add64(__int64 a)
> {
>     (&a)[1] += a;
> }
> 
> 
> void __cdecl m3_neg64(__int64 a)
> {
>     a = -a;
> }
> 
> 
> where we convince the C compiler to do the right stack maintenance.
> We'd just generate parameter-less calls.
> For actually passing longint parameters to real Modula-3 functions,
> I'd have to look, but, like, pop_param would do nothing.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] thoughts on NT386/LONGINT?
> Date: Fri, 22 Jan 2010 22:53:41 +0000
> 
> I'll see what I can figure out.
> 
> 
> I considered pushings pairs of operands in m3x86.m3 but I think
> that won't work.
> 
> 
> Noticing how integer vs. floating point is handled
> is perhaps useful, as this is another way in which m3cg
> is "homogenous" but backends have to act differently
> based on type.
> 
> 
>  - Jay
> 
> 
> 
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 09:49:28 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] thoughts on NT386/LONGINT?
> 
> That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
> 
> On 22 Jan 2010, at 07:39, Jay K wrote:
> 
> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/4a9b00f9/attachment.html>

From dmuysers at hotmail.com  Sun Jan 24 10:32:13 2010
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Sun, 24 Jan 2010 10:32:13 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>

What about IUP ?
It's the one with the narrowest interface...

--------------------------------------------------
From: "Chris" <Highjinks at gmx.com>
Sent: Saturday, January 23, 2010 11:02 PM
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] On Trestle, OpenGL, etc...

> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
>
>> I think the only way to go is a single Modula-3 API that wraps the native 
>> toolkit on each platform, sort of like wxwidgets.  Where there is no 
>> single native toolkit, choose the best or most used.  Portability, full 
>> interoperability and looking/feeling native are the key points here.
>>
>> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has 
>> spent years and billions in Swing, and it still sucks in a different way 
>> every platform it works on.  Worst of all (for me at least) is how it 
>> incorrectly and incompletely mimics the native look and feel, mainly 
>> Motif and GTK, but Mac OS X too; on Windows it looks way better but is 
>> still far from perfect.  SWT is a bit more difficult to use, and not 
>> available (yet?) on every platform, but to me it is the right way to go.
>>
>> Making Trestle look good will only get us so far.  I haven't looked at it 
>> for years, but unless it has changed quite a bit it would require 
>> rewriting significant parts.  Text handling comes to mind, and scrollbars 
>> too.
>>
>> Regards.
>> -Daniel
>
> Good points.
>
> I think your correct that creating bindings to some toolkits are the way 
> to go, for now. Of course the lower level X and OpenGL bindings will still 
> need to be upgraded, just so that thier available for those who want to 
> use them.(I know I will.)
>
> Right now, as far as toolkits go, I'm looking at bindings to 
> Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are 
> good. Maybe bindings to Clutter(http://clutter-project.org/) and 
> Amanith(http://www.amanith.org/) would be useful.
>
> So, bindings are the way to start at least. Alright then. Time to get 
> hacking.
> -- 
> Chris <Highjinks at gmx.com>
> 


From jay.krell at cornell.edu  Sun Jan 24 12:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 11:13:07 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <COL101-W19EFB4F971A68D816BA2D9E6600@phx.gbl>


I had never heard of it. Looks good.

 

 - Jay
 
> From: dmuysers@
> To: Highjinks@; m3devel@
> Date: Sun, 24 Jan 2010 10:32:13 +0100
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> What about IUP ?
> It's the one with the narrowest interface...
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/f570b384/attachment.html>

From hendrik at topoi.pooq.com  Sun Jan 24 14:00:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:00:33 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <20100124130032.GA27093@topoi.pooq.com>

On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> What about IUP ?
> It's the one with the narrowest interface...

Does it run on OS X?  With or without X?

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 24 14:16:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:16:51 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
Message-ID: <20100124131650.GB16928@topoi.pooq.com>

On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> Agreed.  If we allow overflow at run-time we should at compile-time.

But perhaps a compile-time warning is in order for overflow -- in cases 
where we do the arithmetic at compile-time, anyway.  We may avoid 
run-time checks for speed reasons, but there's no such constraint 
on compile-time checks.

-- hendrik


From jay.krell at cornell.edu  Sun Jan 24 14:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 13:50:17 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100124130032.GA27093@topoi.pooq.com>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>,
	<20100124130032.GA27093@topoi.pooq.com>
Message-ID: <COL101-W14D28108FC156C65A1F4BDE6600@phx.gbl>


Mac support unclear.

That's maybe a reason to favor e.g. Qt, Tk, wxWidgets.

 

http://www.tecgraf.puc-rio.br/iup/

http://www.tecgraf.puc-rio.br/iup/en/to_do.html

 

They don't clearly list that they have any currently, but they

do list that they want to..even using Carbon (not sure

Carbon is viable going forward, to AMD64_DARWIN).

 

 - Jay

 
> Date: Sun, 24 Jan 2010 08:00:33 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> > What about IUP ?
> > It's the one with the narrowest interface...
> 
> Does it run on OS X? With or without X?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/b40de143/attachment.html>

From hosking at cs.purdue.edu  Sun Jan 24 23:38:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 17:38:30 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100124131650.GB16928@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
Message-ID: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>

But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
>> Agreed.  If we allow overflow at run-time we should at compile-time.
> 
> But perhaps a compile-time warning is in order for overflow -- in cases 
> where we do the arithmetic at compile-time, anyway.  We may avoid 
> run-time checks for speed reasons, but there's no such constraint 
> on compile-time checks.
> 
> -- hendrik

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

From jay.krell at cornell.edu  Mon Jan 25 12:14:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Jan 2010 11:14:57 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W41670ACD92514D9933EF99E65F0@phx.gbl>


 >> I think what I see now -- just use the machine stack.


I'm not sure this works so easily if you consider function calls.

  Taking a mix of LONGINT and non-LONGINT parameters.

 

There'd be a series of load_integer and pop_param calls.

Normally all the machine stack pushes are in pop_param.

Now they'd be in a mix of load_integer and pop_param.

If pop_param is called as each parameter is computed, ok.

If they are all computed and then all popped, not ok.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out.




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From jay.krell at cornell.edu  Tue Jan 26 13:15:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 12:15:21 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W25B5537DA495533A5E563EE65E0@phx.gbl>


I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.

 

In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.

And also double (LONGFLOAT, whatever).

 

This would help with atomic compare exchange on 64 bit values on x86.

It would probably let us drop the m3cg x86 -mno-align-double switch.

  That would have saved me quite some debugging time a while ago....

Not sure about -munaligned-doubles though on Linux/sparc.

 

I'd have to check what the language allows, but if there is "adequate" and

"ideal" alignment, then users should maybe be able to ask for "adequate"

if they have large arrays and want to optimize for memory.

 

Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.

Though max_align doesn't appear to be applied to jmpbufs.

 

Notice that the language doesn't let you declare such high alignment.

 

- Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/6742ac38/attachment.html>

From jay.krell at cornell.edu  Tue Jan 26 14:04:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:04:38 +0000
Subject: [M3devel] doextract_mn, doextract_n, insert_mn, insert_n
Message-ID: <COL101-W350F45564A26EDD4ADECADE65E0@phx.gbl>


doextract_mn, doextract_n, insert_mn, insert_n

 


We don't *really* need any of these in M3CG.i3.
They make it easier for the backend to optimize,
but the integrated backend *always* optimizes
as well as these allow for.

 


I noticed in the frontend that its helper function Insert_mn (capital I)
is never used, because GenInsert.mg fails to do the
optimizations that GenExtract.mg does.

 


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/c9f2d54e/attachment.html>

From jay.krell at cornell.edu  Tue Jan 26 14:21:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:21:44 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W344C1DE585165E3C53E644E65E0@phx.gbl>


Visual C++/x86:

 

 

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(__int64));
 return 0;
}

gcc/Linux/x86:

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(long long));
 return 0;
}

 

 

both print "8 8".

 

 

Fixing this would break some pickles that contain LONGINT and/or LONGREAL, depending on if they needed padding to align.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: max_align
Date: Tue, 26 Jan 2010 12:15:21 +0000



I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.
 
In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.
And also double (LONGFLOAT, whatever).
 
This would help with atomic compare exchange on 64 bit values on x86.
It would probably let us drop the m3cg x86 -mno-align-double switch.
  That would have saved me quite some debugging time a while ago....
Not sure about -munaligned-doubles though on Linux/sparc.
 
I'd have to check what the language allows, but if there is "adequate" and
"ideal" alignment, then users should maybe be able to ask for "adequate"
if they have large arrays and want to optimize for memory.
 
Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.
Though max_align doesn't appear to be applied to jmpbufs.
 
Notice that the language doesn't let you declare such high alignment.
 
- Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/495e228a/attachment.html>

From jay.krell at cornell.edu  Wed Jan 27 15:01:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 14:01:04 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
Message-ID: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>


MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.

 

 

 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked


 

 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.



 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/383d90a1/attachment.html>

From hosking at cs.purdue.edu  Wed Jan 27 16:57:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 10:57:09 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
Message-ID: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>

If we declare it as a 32-bit subrange it should just work, right?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 27 Jan 2010, at 09:01, Jay K wrote:

> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>   the closure marker being a 4 byte -1 instead of an INTEGER.
>  
>  
>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
> 
>  
>  That is, we should probably make their be a per-target variable "closure marker size"
>   that is 4 for all current targets (IA64 should probably be 16 though),
>   though one would have to look into the various instruction encodings.
> 
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/1f8764ec/attachment.html>

From jay.krell at cornell.edu  Wed Jan 27 17:17:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 16:17:50 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>


yes, but I think it is target-specific. IA64 would use 16 bytes.

It isn't even in library code, but generated code.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 27 Jan 2010 10:57:09 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"

If we declare it as a 32-bit subrange it should just work, right?




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 27 Jan 2010, at 09:01, Jay K wrote:

MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.
 
 
 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked

 
 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.


 - Jay

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

From hosking at cs.purdue.edu  Wed Jan 27 17:19:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 11:19:54 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <EE6487AA-9BA1-4D9A-BFCA-053FC6B8487C@cs.purdue.edu>

Sorry.  Just realised this is deeply embedded in the Target files.


On 27 Jan 2010, at 10:57, Tony Hosking wrote:

> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>>   the closure marker being a 4 byte -1 instead of an INTEGER.
>>  
>>  
>>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
>> 
>>  
>>  That is, we should probably make their be a per-target variable "closure marker size"
>>   that is 4 for all current targets (IA64 should probably be 16 though),
>>   though one would have to look into the various instruction encodings.
>> 
>> 
>>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/41b44d37/attachment.html>

From rodney_bates at lcwb.coop  Wed Jan 27 23:19:21 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 27 Jan 2010 16:19:21 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
Message-ID: <4B60BBE9.7020401@lcwb.coop>

Before anybody fiddles with closure markers, *please* do *both* the following:

1)  Let me know.  M3gdb needs to both recognize and construct closures
     (and it currently does.)  Changing them will break it, unless it is
     modified accordingly.

2)  Make sure there is some reasonable way m3gdb can tell by looking at
     the object code being debugged, whether it was generated by a
     compiler version that uses the old or the new closure marker
     representation.

I have worked hard to make m3gdb able to adapt to the various compilers
and versions, but periodically I get undermined on 1) and/or 2) above
by some quiet change somebody makes without thinking about m3gdb.

Also, think about the implications on linking together code produced
by different compiler versions.  I am quite sure changing the closure
representation would mean *all* linked-in libraries would have to be
recompiled, along with the main program, by the same compiler version.

Right now, closure markers are always the same size as pointers, and I think
there are multiple places in the compiler and runtime, in addition to m3gdb,
that rely on this.  They would all have to be located and fixed.  And I
don't think they all key off any single declaration, e.g. closure_marker_size.

Jay K wrote:
> yes, but I think it is target-specific. IA64 would use 16 bytes.
> It isn't even in library code, but generated code.
>  
>  - Jay
> 
>  
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 27 Jan 2010 10:57:09 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
> 
> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>     MIPS64, SPARC64 and maybe others could probably all benefit slightly
>     from
>       the closure marker being a 4 byte -1 instead of an INTEGER.
>      
>      
>      That is: 64bit architectures with a fixed size 4 byte instruction
>     where alignment is checked
> 
>      
>      That is, we should probably make their be a per-target variable
>     "closure marker size"
>       that is 4 for all current targets (IA64 should probably be 16 though),
>       though one would have to look into the various instruction encodings.
> 
> 
>      - Jay
> 
> 


From jay.krell at cornell.edu  Thu Jan 28 02:30:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 28 Jan 2010 01:30:21 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>, ,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>,
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>,
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <COL101-W28BF8C4DD648F3633CB288E65C0@phx.gbl>


Thanks, understood.
No "mainstream" target would be affected -- no x86 target (32bit or 64bit), probably not any 32bit target.
 
 
For IA64 either we we probably want a 128 bit marker, since that is the instruction size, sort of (multiple instructions packed into 128 bit chunks).
 
 
Basically any architecture that has a fixed size 4 byte instruction, 4 byte aligned instructions, where alignment is checked, where pointer is 8 bytes, would be a little more efficient with a 4 byte marker instead of an 8 byte marker. Like, probably any MIPS64 or SPARC64 platform, and maybe some others (HPPA, Alpha, PPC64). Not any x86 or AMD64 though.
 
 
The closure would be smaller and the alignment would naturally be ok. Currently such architectures have to fiddle around with the pointer since it might not be 8 byte aligned. Any call through a function pointer would save a few instructions.
 
 
Really what bugs me most about this area is the time I have wasted in the past learning about it bringing up new platforms!
 
 
It bugs me otherwise -- the assumption that -1 is invalid code. The lack of a good solution here in general -- gcc has nested functions, but it doesn't do it in a good way either -- they generate code on the stack, on some platforms use mprotect to make the page executable, and on some platforms just fail completely (I think iPhone for example).
 
 
I suppose another improvement would be to make the value (-1) configurable per target. I haven't gone to the trouble of disasm'ing -1 on various platforms yet. Probably it is ok. It doesn't even have to be invalid, it just has to not to be the first instruction of a function.
 
 
 - Jay


----------------------------------------
> Date: Wed, 27 Jan 2010 16:19:21 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>
> Before anybody fiddles with closure markers, *please* do *both* the following:
>
> 1) Let me know. M3gdb needs to both recognize and construct closures
> (and it currently does.) Changing them will break it, unless it is
> modified accordingly.
>
> 2) Make sure there is some reasonable way m3gdb can tell by looking at
> the object code being debugged, whether it was generated by a
> compiler version that uses the old or the new closure marker
> representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions. I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this. They would all have to be located and fixed. And I
> don't think they all key off any single declaration, e.g. closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>
>> - Jay
>>
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly
>> from
>> the closure marker being a 4 byte -1 instead of an INTEGER.
>>
>>
>> That is: 64bit architectures with a fixed size 4 byte instruction
>> where alignment is checked
>>
>>
>> That is, we should probably make their be a per-target variable
>> "closure marker size"
>> that is 4 for all current targets (IA64 should probably be 16 though),
>> though one would have to look into the various instruction encodings.
>>
>>
>> - Jay
>>
>> 		 	   		  

From wagner at elegosoft.com  Thu Jan 28 11:31:56 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 28 Jan 2010 11:31:56 +0100
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>

Shouldn't we insert a short version of this warning into the source
code? Or is there no central location where it could be placed and
will be noticed?

This is a non-obvious dependency, and though Jay and Tony will remember
now, there may be others in a few years who don't.

Olaf

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Before anybody fiddles with closure markers, *please* do *both* the   
> following:
>
> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>     (and it currently does.)  Changing them will break it, unless it is
>     modified accordingly.
>
> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>     the object code being debugged, whether it was generated by a
>     compiler version that uses the old or the new closure marker
>     representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions.  I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this.  They would all have to be located and fixed.  And I
> don't think they all key off any single declaration, e.g.   
> closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>  - Jay
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>    from
>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>               That is: 64bit architectures with a fixed size 4 byte  
>>  instruction
>>    where alignment is checked
>>
>>          That is, we should probably make their be a per-target variable
>>    "closure marker size"
>>      that is 4 for all current targets (IA64 should probably be 16 though),
>>      though one would have to look into the various instruction encodings.
>>
>>
>>     - Jay
>>
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Jan 28 17:55:53 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 28 Jan 2010 10:55:53 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>	<4B60BBE9.7020401@lcwb.coop>
	<20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
Message-ID: <4B61C199.2040000@lcwb.coop>

Well, there are many aspects of the runtime organization that affect
m3gdb, and I am afraid they are scattered far and wide in the source
code, so it might be hard to do this systematically.  I have, on
one or two occasions in the past, put a comment in the compiler
or runtime source code, regarding some specific matter that affects
m3gdb.

Maybe I'll look for a good place to note about closure markers.

Olaf Wagner wrote:
> Shouldn't we insert a short version of this warning into the source
> code? Or is there no central location where it could be placed and
> will be noticed?
> 
> This is a non-obvious dependency, and though Jay and Tony will remember
> now, there may be others in a few years who don't.
> 
> Olaf
> 
> Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:
> 
>> Before anybody fiddles with closure markers, *please* do *both* the  
>> following:
>>
>> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>>     (and it currently does.)  Changing them will break it, unless it is
>>     modified accordingly.
>>
>> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>>     the object code being debugged, whether it was generated by a
>>     compiler version that uses the old or the new closure marker
>>     representation.
>>
>> I have worked hard to make m3gdb able to adapt to the various compilers
>> and versions, but periodically I get undermined on 1) and/or 2) above
>> by some quiet change somebody makes without thinking about m3gdb.
>>
>> Also, think about the implications on linking together code produced
>> by different compiler versions.  I am quite sure changing the closure
>> representation would mean *all* linked-in libraries would have to be
>> recompiled, along with the main program, by the same compiler version.
>>
>> Right now, closure markers are always the same size as pointers, and I 
>> think
>> there are multiple places in the compiler and runtime, in addition to 
>> m3gdb,
>> that rely on this.  They would all have to be located and fixed.  And I
>> don't think they all key off any single declaration, e.g.  
>> closure_marker_size.
>>
>> Jay K wrote:
>>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>>> It isn't even in library code, but generated code.
>>>  - Jay
>>>
>>> ------------------------------------------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>>
>>> If we declare it as a 32-bit subrange it should just work, right?
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>>
>>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>>    from
>>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>>               That is: 64bit architectures with a fixed size 4 byte 
>>>  instruction
>>>    where alignment is checked
>>>
>>>          That is, we should probably make their be a per-target variable
>>>    "closure marker size"
>>>      that is 4 for all current targets (IA64 should probably be 16 
>>> though),
>>>      though one would have to look into the various instruction 
>>> encodings.
>>>
>>>
>>>     - Jay
>>>
>>>
> 
> 
> 


From Highjinks at gmx.com  Fri Jan 29 00:23:55 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 29 Jan 2010 00:23:55 +0100 (CET)
Subject: [M3devel] Which libraries to use?
Message-ID: <20100128192638.03b7590e.Highjinks@gmx.com>

Or better yet, should I just write my own.

Getting started writing bindings from the header files in ../include/X11/extensions

However, some of those depend on ../include/X11/Xmd.h and ../include/X11/Xfuncproto.h

Writing bindings for these probably shouldn't be necessary. However, I just want to make sure.

Does anyone forsee a problem if I just stick the values defined in the CM3 libs?
 
It's also looking fairly certain that I'm going to break off Xlib and XUtil into thier own .i3 files.

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 29 11:09:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 10:09:46 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W35838671ED7CF50D3D70D5E65B0@phx.gbl>


So I looked again -- how is floating point dealt with?
Well, it has its own stack. That helps here (even if it is otherwise lame).

 

 

The "easy" way would be to have M3x86.m3 

do stuff "directly", but each function would have

a little local array of __int64 that push/pop/add/sub/mult

used. It would be very inefficient but would work.

Passing parameters would pop from the local array

and push onto the machine stack. 

 

 

You can see this approach if you watch the

talk on the "XMLVM" where they implement Java for iPhone.

They disassemble .class files into a direct xml representation,

then use XSL style sheets to translate to Objective-C,

or JavaScript, or almost anything.

They give each function a little array to model the Java VM stack.

 

 

I'm still spinning on an efficient approach.

I can actually generate a *little* bit of correct reasonable

code, but not much yet.

Just 64bit moves of constants into variables.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Mon, 25 Jan 2010 11:14:57 +0000



 >> I think what I see now -- just use the machine stack.

I'm not sure this works so easily if you consider function calls.
  Taking a mix of LONGINT and non-LONGINT parameters.
 
There'd be a series of load_integer and pop_param calls.
Normally all the machine stack pushes are in pop_param.
Now they'd be in a mix of load_integer and pop_param.
If pop_param is called as each parameter is computed, ok.
If they are all computed and then all popped, not ok.
 
 
 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out. 




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/1c964751/attachment.html>

From hendrik at topoi.pooq.com  Fri Jan 29 15:32:50 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 29 Jan 2010 09:32:50 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
	<2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
Message-ID: <20100129143250.GA9515@topoi.pooq.com>

On Sun, Jan 24, 2010 at 05:38:30PM -0500, Tony Hosking wrote:
> But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

If the compiler can determine statically that an overflow will happen, 
and the overflow cause incorrect behaviour of the program, it just 
might be helpful to inform him.

But I wouldn't go so far as to say it's a problem.  It would be a 
problem for him to be unable to get overflow checking even if he's 
willing to pay the run-time cost.  But that wasn't what I was talking 
about.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> >> Agreed.  If we allow overflow at run-time we should at compile-time.
> > 
> > But perhaps a compile-time warning is in order for overflow -- in cases 
> > where we do the arithmetic at compile-time, anyway.  We may avoid 
> > run-time checks for speed reasons, but there's no such constraint 
> > on compile-time checks.
> > 
> > -- hendrik
> 


From hosking at cs.purdue.edu  Fri Jan 29 18:40:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 29 Jan 2010 12:40:51 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
Message-ID: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>

Note that the front-end refuses to do any constant folding that results in overflow.  Instead, it generates code that will execute at run-time.  If that causes a run-time error then fine.  Similarly, the back-end should never do constant folding for things that overflow.


On 29 Jan 2010, at 11:48, Jay K wrote:

> For now I'm treating the error as a warning and continuing on.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 29 Jan 2010 10:31:35 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Why do you need that?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/29 09:57:33
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.m3 
> 
> Log message:
> in ToInt and IntI, do the conversion even if there is overflow (still returning FALSE for overflow)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/389af581/attachment.html>

From rodney_bates at lcwb.coop  Fri Jan 29 19:11:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 29 Jan 2010 12:11:39 -0600
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
Message-ID: <4B6324DB.7040809@lcwb.coop>



Tony Hosking wrote:
> Note that the front-end refuses to do any constant folding that results 
> in overflow.  Instead, it generates code that will execute at run-time. 
>  If that causes a run-time error then fine.  Similarly, the back-end 
> should never do constant folding for things that overflow.

Hmm, I didn't know that.  I think that is a very good idea.  It really
preserves language semantics, while gaining efficiency where possible.


> 
> On 29 Jan 2010, at 11:48, Jay K wrote:
> 
>> For now I'm treating the error as a warning and continuing on.
>>  
>>  - Jay
>>
>>  
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>> Date: Fri, 29 Jan 2010 10:31:35 -0500
>> To: jkrell at elego.de <mailto:jkrell at elego.de>
>> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> Why do you need that?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>> University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 29 Jan 2010, at 09:57, Jay Krell wrote:
>>
>>     CVSROOT: /usr/cvs
>>     Changes by: jkrell at birch. 10/01/29 09:57:33
>>
>>     Modified files:
>>     cm3/m3-sys/m3middle/src/: Target.m3 
>>
>>     Log message:
>>     in ToInt and IntI, do the conversion even if there is overflow
>>     (still returning FALSE for overflow)
>>
>>
>>
> 


From jay.krell at cornell.edu  Fri Jan 29 22:02:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 21:02:01 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <4B6324DB.7040809@lcwb.coop>
References: <20100129085733.63129CC308@birch.elegosoft.com>, ,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>,
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>,
	<4B6324DB.7040809@lcwb.coop>
Message-ID: <COL101-W63294B6BEEF06B0124FA1E65B0@phx.gbl>


There isn't really overflow here, just having trouble implementing longint.

For example 

  ToInt(FIRST(INTEGER) & MAXU32)) overflows, though it shouldn't matter.

 

 - Jay
 
> Date: Fri, 29 Jan 2010 12:11:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> 
> 
> Tony Hosking wrote:
> > Note that the front-end refuses to do any constant folding that results 
> > in overflow. Instead, it generates code that will execute at run-time. 
> > If that causes a run-time error then fine. Similarly, the back-end 
> > should never do constant folding for things that overflow.
> 
> Hmm, I didn't know that. I think that is a very good idea. It really
> preserves language semantics, while gaining efficiency where possible.
> 
> 
> > 
> > On 29 Jan 2010, at 11:48, Jay K wrote:
> > 
> >> For now I'm treating the error as a warning and continuing on.
> >> 
> >> - Jay
> >>
> >> 
> >> ------------------------------------------------------------------------
> >> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >> Date: Fri, 29 Jan 2010 10:31:35 -0500
> >> To: jkrell at elego.de <mailto:jkrell at elego.de>
> >> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
> >> Subject: Re: [M3commit] CVS Update: cm3
> >>
> >> Why do you need that?
> >>
> >> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >> University
> >> 305 N. University Street | West Lafayette | IN 47907 | USA
> >> Office +1 765 494 6001 | Mobile +1 765 427 5484
> >>
> >>
> >>
> >>
> >> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> >>
> >> CVSROOT: /usr/cvs
> >> Changes by: jkrell at birch. 10/01/29 09:57:33
> >>
> >> Modified files:
> >> cm3/m3-sys/m3middle/src/: Target.m3 
> >>
> >> Log message:
> >> in ToInt and IntI, do the conversion even if there is overflow
> >> (still returning FALSE for overflow)
> >>
> >>
> >>
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/6cdd7e37/attachment.html>

From mbishop at esoteriq.org  Sun Jan 31 01:19:20 2010
From: mbishop at esoteriq.org (Martin Bishop)
Date: Sat, 30 Jan 2010 18:19:20 -0600
Subject: [M3devel] 5.8 Release?
Message-ID: <4B64CC88.6070409@esoteriq.org>

I don't want to be a buzz kill, but it's almost February 2010, and 5.8 
stable is still not out.  Are there still any issues left?  Anything 
that can be ignored until after release?




From hosking at cs.purdue.edu  Sun Jan 31 04:31:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 30 Jan 2010 22:31:18 -0500
Subject: [M3devel] 5.8 Release?
In-Reply-To: <4B64CC88.6070409@esoteriq.org>
References: <4B64CC88.6070409@esoteriq.org>
Message-ID: <E67ECCE2-26D3-4496-9417-3BD4494A8904@cs.purdue.edu>

Surely we are close.  What stability issues are there on the release branch?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 30 Jan 2010, at 19:19, Martin Bishop wrote:

> I don't want to be a buzz kill, but it's almost February 2010, and 5.8 stable is still not out.  Are there still any issues left?  Anything that can be ignored until after release?
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100130/4ba7fd3b/attachment.html>

From jay.krell at cornell.edu  Sun Jan 31 13:21:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:21:19 +0000
Subject: [M3devel] platform-independent packing/alignment?
Message-ID: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>


These are more potential ABI breaking changes.

Not sure if they'd break pickles or not.

 

 

I suggest we can probably get by with platform-independent packing/alignment settings.

Align everything by its size, up to 8. ?

That is increased alignment for LONGINT and LONGFLOAT on some systems.

  Which they probably should have been in the first place.

It would also increase alignment for obsolete M68K platforms.

 

 

I also suggest we need pragmas to declare something is packed/aligned

differently. But that might be avoided via C layers.

 

 

See, in mklib we have:

 

 

TYPE
  PIMAGE_SYMBOL = <* UNALIGNED *> UNTRACED REF IMAGE_SYMBOL;
  IMAGE_SYMBOL = RECORD
    N: ARRAY [0 .. 7] OF UINT8;
    Value              : UINT32;
    SectionNumber      : INT16;
    Type               : UINT16;
    StorageClass       : UINT8;
    NumberOfAuxSymbols : UINT8;
  END;

 

CONST
    IMAGE_SIZEOF_SYMBOL = 18;


 

But BYTESIZE(IMAGE_SYMBOL) is probably 20 on all platforms (except maybe M68K ones).

 

 

Then Target.Int8, etc. could be constants.

Maybe not worth anything.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/6b8cddf1/attachment.html>

From jay.krell at cornell.edu  Sun Jan 31 13:28:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?
Message-ID: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>


I'm seeing:

Just me?

I'll keep digging.

 

== package C:\dev2\cm3.2\m3-libs\m3core ==

 +++ 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

 

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/5cff08fc/attachment.html>

From jay.krell at cornell.edu  Sun Jan 31 13:37:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:37:23 +0000
Subject: [M3devel] errors compiling?
In-Reply-To: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
References: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
Message-ID: <COL101-W53FB7810A7679FB145A8E5E6590@phx.gbl>


nevermind, I fixed it

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?



I'm seeing:
Just me?
I'll keep digging.
 
== package C:\dev2\cm3.2\m3-libs\m3core ==
 +++ 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
 
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/7e06ff02/attachment.html>

From dragisha at m3w.org  Sun Jan 31 17:29:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 17:29:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
Message-ID: <1264955387.4240.2.camel@faramir.m3w.org>

I've asked this before, but didn't catch answer:

On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> I suggest we can probably get by with platform-independent
> packing/alignment settings.

Some time ago I've used pickles (CM3) to save some data... My program
does not read that pickle anymore.... 

Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Sun Jan 31 19:59:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Jan 2010 13:59:53 -0500
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <C987DE66-5EF6-4581-817C-FBFA9986ACC0@cs.purdue.edu>

That should not be the case.  Any changes should have made for more capability rather than less.  Any chance you know what data type is not being read properly? 



On 31 Jan 2010, at 11:29, Dragi?a Duri? wrote:

> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 
> 
> Someone remembers moment when this incompatible changes were made? 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From rodney_bates at lcwb.coop  Sun Jan 31 21:00:08 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 31 Jan 2010 14:00:08 -0600
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <4B65E148.4090105@lcwb.coop>



Dragi?a Duri? wrote:
> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 

And you are certain your program that tries to read still contains
exact structurally equivalent types to all the types in the pickle?

> 
> Someone remembers moment when this incompatible changes were made? 


From dragisha at m3w.org  Sun Jan 31 22:14:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 22:14:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <4B65E148.4090105@lcwb.coop>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>
Message-ID: <1264972487.4240.4.camel@faramir.m3w.org>

I've not changed my code, that is for sure.... But now I am not sure
some parent type (esp MUTEX here an there) was not changed... I'll take
a look on this again sometime soon and report my findings.

Thanks for clues.

On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> 
> Dragi?a Duri? wrote:
> > I've asked this before, but didn't catch answer:
> > 
> > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> >> I suggest we can probably get by with platform-independent
> >> packing/alignment settings.
> > 
> > Some time ago I've used pickles (CM3) to save some data... My program
> > does not read that pickle anymore.... 
> 
> And you are certain your program that tries to read still contains
> exact structurally equivalent types to all the types in the pickle?
> 
> > 
> > Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Fri Jan  1 21:30:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 15:30:42 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
Message-ID: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>

What does -C do?

On 29 Dec 2009, at 12:47, Olaf Wagner wrote:

> Any ideas? Interaction problem between threads and select?
> 
> Olaf
> 
> ----- Forwarded message from bugs at elego.de -----
>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>    From: CM3 <bugs at elego.de>
> Reply-To: CM3 <bugs at elego.de>
> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>      To: @MISSING_DOMAIN
> 
> #1080: CVSUPD server hangs if used with -C option
> -----------------------------+----------------------------------------------
>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>      Type:  sw-bug          |           Status:  new
>  Priority:  high            |        Milestone:
> Component:  sys             |          Version:  5.8-RC3
>  Severity:  critical        |         Keywords:
>   Relnote:                  |     Confidential:  no
>       Org:  Collabnet       |   Estimatedhours:  0
>     Hours:  0               |         Billable:  0
> Totalhours:  0               |
> -----------------------------+----------------------------------------------
> Htr:
> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
> 
> Start the cvsupd server with -C option
> 
> ./cvsupd -b /data/cvsupd -C 2
> 
> Try cvsup client to connect to the sever
> 
> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> 
> The client connection will hang and after sometime we will get "Inactivity timeout"
> 
> 
> Fix:
> 
> 
> 
> Env:
> 
> 
> -----------------------------+----------------------------------------------
> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
> cvsup installed.
> 
> The server starts find and there was no issues if I start the server
> without -C option.
> 
> Starting cvsupd server without -C option
> 
> $ ./cvsupd -b /u2/site/data/cvsupd
> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> 
> Then I did a client request as below
> 
> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> Parsing supfile "/tmp/cvsupd.cfg"
> Connecting to myserver.com
> Connected to myserver.com
> Rejected by server: Access denied
> Will retry at 21:37:09
> 
> So the request was successful and I get a valid error message at the
> client.
> 
> But when I start the server with -C option like the one as below, requests
> from client are hanging and eventually getting "Inactivity timeout" after
> sometime.
> 
> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> 
> When ever a new client connection was made, this daemon clones another
> cvsupd process and it also hangs. So none of the client request were
> processed.
> 
> Strace of the main cvsupd server process, when a new client request was
> fired.
> 
> -----------------------------------
> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> gettimeofday({1262103026, 146476}, NULL) = 0
> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> _llseek(7, 0, [0], SEEK_CUR)            = 0
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> close(7)                                = 0
> gettimeofday({1262103026, 147481}, NULL) = 0
> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
> such file or directory)
> write(5, "\0", 1)                       = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0xb7f43708) = 6543
> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> close(6)                                = 0
> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
> unavailable)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> 
> ------------------------------------
> 
> gdb backtrace of the main cvsupd server process
> 
> ------------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> ../src/unix/Common/UnixC.c:301
> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
> M3_A4bqCj_timeout=0xbfed9410) at
> ../src/thread/PTHREAD/ThreadPThread.m3:900
> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> ../src/thread/PTHREAD/ThreadPThread.m3:854
> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:153
> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> ------------------------------------------------
> 
> 
> strace of the cloned cvsupd process
> 
> -----------------------------------
> 
> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> 
> -----------------------------------
> 
> gdb backtrace of the cloned cvsupd process
> 
> -----------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/libpthread.so.0
> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> ../src/FSServer.m3:231
> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:227
> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> 
> -------------------------------------------
> 
> So it looks like both the main and cloned cvsupd processes were waiting
> for a response from the kernel call "__kernel_vsyscall ()". Under what
> condition will this happen? Am I doing something wrong here?
> 
> -- 
> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> CM3 <http://projects.elego.de/cm3>
> Critical Mass Modula3 Compiler
> 
> 
> ----- End forwarded message -----
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/4d7ee17c/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  1 23:56:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 22:56:00 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
Message-ID: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>


I can understand that the name on the left isn't in scope "yet" on the right,
but what is the algorithm for anyone else using IMPORT?


import foo;
import foo(bar);
import foo(bar) as foobar;
import foo(bar).T as fooT;


I doubt all but the first of these are legal, but I also don't think they are very far fetched
in terms of being reasonable constructs and not difficult to implement.


And I'm not sure the presence of the '(' is enough disambiguation for a quick human reader
or a pleasantly simply enough implementation, but maybe.


All that is to say, I don't think disallowing interface foo = foo(bar) is so bad.


 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 1 Jan 2010 14:43:36 -0500
To: jkrell at elego.de
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3



That's a bug in m3tk scope management.  Probably needs a ticket in the bugs database...


On 30 Dec 2009, at 15:40, Jay Krell wrote:CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/12/30 15:40:06

Modified files:
	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3 
	                              m3makefile 
Added files:
	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg 
Removed files:
	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg 

Log message:
	go back to GenWord
	the other front end (Olivetti m3-tk)
	doesn't understand
	INTERFACE Word = Word(WordRep) END Word.
	but it does't understand
	INTERFACE Word = GenWord(WordRep) END Word.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/ba95343b/attachment-0001.html>

From mika at async.async.caltech.edu  Sat Jan  2 00:02:23 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 01 Jan 2010 15:02:23 -0800
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl> 
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
Message-ID: <20100101230223.355441A2080@async.async.caltech.edu>

Jay K writes:
...
>
>import foo=3B
>import foo(bar)=3B
>import foo(bar) as foobar=3B
>import foo(bar).T as fooT=3B

Modula-3 doesn't work like that.

You have to say

INTERFACE X = G(Y) ...

IMPORT X

You can't import "G(Y)" directly.  Saves having to worry too much about
name mangling.

Having a generic interface and a normal one with the same name is a common
pattern for me, at least.

You often have a single supertype and then many subtypes that are related
to that supertype by being extended with, say, a field of an arbitrary type.

Then you get...

INTERFACE Stuff; TYPE T ... END Stuff.

GENERIC INTERFACE Stuff(Specializing);
IMPORT Stuff;
TYPE T = Stuff.T OBJECT special : Specializing.T END;
END Stuff.

INTERFACE SpecialStuff = Stuff(Special)

Very convenient to use the same name at the top level, I think.

    Mika

>
>
>I doubt all but the first of these are legal=2C but I also don't think they=
> are very far fetched
>in terms of being reasonable constructs and not difficult to implement.
>
>
>And I'm not sure the presence of the '(' is enough disambiguation for a qui=
>ck human reader
>or a pleasantly simply enough implementation=2C but maybe.
>
>
>All that is to say=2C I don't think disallowing interface foo =3D foo(bar) =
>is so bad.
>
>
> - Jay
>
>From: hosking at cs.purdue.edu
>Date: Fri=2C 1 Jan 2010 14:43:36 -0500
>To: jkrell at elego.de
>CC: m3commit at elegosoft.com
>Subject: Re: [M3commit] CVS Update: cm3
>
>
>
>That's a bug in m3tk scope management.  Probably needs a ticket in the bugs=
> database...
>
>
>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:CVSROOT:	/usr/cvs
>Changes by:	jkrell at birch.	09/12/30 15:40:06
>
>Modified files:
>	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3=20
>	                              m3makefile=20
>Added files:
>	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg=20
>Removed files:
>	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg=20
>
>Log message:
>	go back to GenWord
>	the other front end (Olivetti m3-tk)
>	doesn't understand
>	INTERFACE Word =3D Word(WordRep) END Word.
>	but it does't understand
>	INTERFACE Word =3D GenWord(WordRep) END Word.
>
> 		 	   		  =
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I can understand that the name on the left isn't in scope "yet" on the righ=
>t=2C<br>but what is the algorithm for anyone else using IMPORT?<br><br><br>=
>import foo=3B<br>import foo(bar)=3B<br>import foo(bar) as foobar=3B<br>impo=
>rt foo(bar).T as fooT=3B<br><br><br>I doubt all but the first of these are =
>legal=2C but I also don't think they are very far fetched<br>in terms of be=
>ing reasonable constructs and not difficult to implement.<br><br><br>And I'=
>m not sure the presence of the '(' is enough disambiguation for a quick hum=
>an reader<br>or a pleasantly simply enough implementation=2C but maybe.<br>=
><br><br>All that is to say=2C I don't think disallowing interface foo =3D f=
>oo(bar) is so bad.<br><br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">=
>From: hosking at cs.purdue.edu<br>Date: Fri=2C 1 Jan 2010 14:43:36 -0500<br>To=
>: jkrell at elego.de<br>CC: m3commit at elegosoft.com<br>Subject: Re: [M3commit] =
>CVS Update: cm3<br><br>
>
><div><span class=3D"ecxApple-style-span" style=3D"border-collapse: separate=
>=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B=
> font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette=
>r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf=
>orm: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ec=
>xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=
>=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><div style=3D"word-wrap: break-wor=
>d=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: separat=
>e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=
>=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le=
>tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra=
>nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D=
>"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C=
> 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span=
>" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam=
>ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no=
>rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma=
>l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor=
>d-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-coll=
>apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font=
>-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n=
>ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=
>=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"><s=
>pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col=
>or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s=
>tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci=
>ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no=
>ne=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-=
>style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=
>=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font=
>-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h=
>eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n=
>ormal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D=
>"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve=
>tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo=
>nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-=
>indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:=
> 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: sepa=
>rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p=
>x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l=
>etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr=
>ansform: none=3B white-space: normal=3B word-spacing: 0px=3B"><div><span cl=
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B"><font class=3D"e=
>cxApple-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">That's a bug in =
>m3tk scope management. &nbsp=3BProbably needs a ticket in the bugs database=
>...</font></span></div></span></span></span></span></span></span></span></s=
>pan></div></span></span>
></div>
><br><div><div>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:</div><br class=
>=3D"ecxApple-interchange-newline"><blockquote><div>CVSROOT:<span class=3D"e=
>cxApple-tab-span" style=3D"white-space: pre=3B">	</span>/usr/cvs<br>Changes=
> by:<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span=
>>jkrell at birch.<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>09/12/30 15:40:06<br><br>Modified files:<br><span class=3D"ecx=
>Apple-tab-span" style=3D"white-space: pre=3B">	</span>cm3/m3-libs/m3core/sr=
>c/word/: Long.i3 Long.m3 Word.i3 Word.m3 <br><span class=3D"ecxApple-tab-sp=
>an" style=3D"white-space: pre=3B">	</span> &nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
>sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
>=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3Bm3makefile <br>Added fil=
>es:<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</s=
>pan>cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg <br>Removed files:<=
>br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>=
>cm3/m3-libs/m3core/src/word/: Word.ig Word.mg <br><br>Log message:<br><span=
> class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>go back =
>to GenWord<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>the other front end (Olivetti m3-tk)<br><span class=3D"ecxAppl=
>e-tab-span" style=3D"white-space: pre=3B">	</span>doesn't understand<br><sp=
>an class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERF=
>ACE Word =3D Word(WordRep) END Word.<br><span class=3D"ecxApple-tab-span" s=
>tyle=3D"white-space: pre=3B">	</span>but it does't understand<br><span clas=
>s=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERFACE Wor=
>d =3D GenWord(WordRep) END Word.<br></div></blockquote></div><br> 		 	   		=
>  </body>
></html>=
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_--


From jay.krell at cornell.edu  Sat Jan  2 00:05:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 23:05:44 +0000
Subject: [M3devel] C generating back end
Message-ID: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>


Fyi I finally looked at the 2.x implementation and the outputing of
C was implemented fairly directly at the m3front layer.
There wasn't the "M3CG" stuff.


Thus, the "easiest" way to get back such functionality would
probably be to "interleave" the old code and the new code within m3front.


The "cleaner" way is probably to implement a new M3CG though and
leave m3front unchanged.


I still think generating portable C a great way to achieve portability.
Better yet maybe, generate C++ and use its exception handling feature.
(ok, maybe generate both, in case some systems lack C++ support)


I realize there are several ways to view this though.

  gcc backend provides enough portability 
     imagine IA64_NT though. or Plan9. or even OpenBSD 
      or Darwin where there are long standing forks 
      (The OpenBSD patches are small and we carry/apply them.
      The Apple changes I think are mainly in the frontends
      which I think is how we get by.) 

     For efficient exception handling we should be able to use libunwind on most targets. 

  llvm would provide good portability and maybe other benefits like perf 
     less reach than gcc but hits the major platforms 
     difficult for me to get started with sorry 

  integrated backend could/should be ported around and is fast 
     a lot of work 
     I think the first steps here are to learn about mach-o and elf file formats
       as part of ports for other x86 targets. I've started a macho-dumper. 

  burg or others 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/98af7028/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  2 00:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 18:42:34 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
Message-ID: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>

On 1 Jan 2010, at 18:05, Jay K wrote:

> Fyi I finally looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such functionality would
> probably be to "interleave" the old code and the new code within m3front.

I'd like to avoid that sort of interleaving.

> The "cleaner" way is probably to implement a new M3CG though and
> leave m3front unchanged.

This is a much better plan.

> I still think generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception handling feature.
> (ok, maybe generate both, in case some systems lack C++ support)

We can use the gcc-backend exception handling support if anyone was prepared to work on it.

>  realize there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9. or even OpenBSD 
>       or Darwin where there are long standing forks 
>       (The OpenBSD patches are small and we carry/apply them.
>       The Apple changes I think are mainly in the frontends
>       which I think is how we get by.) 
> 
>      For efficient exception handling we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other benefits like perf 
>      less reach than gcc but hits the major platforms 
>      difficult for me to get started with sorry 
> 
>   integrated backend could/should be ported around and is fast 
>      a lot of work 
>      I think the first steps here are to learn about mach-o and elf file formats
>        as part of ports for other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100101/d2789713/attachment-0001.html>

From dabenavidesd at yahoo.es  Sat Jan  2 02:27:55 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 2 Jan 2010 01:27:55 +0000 (GMT)
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <694151.75147.qm@web23608.mail.ird.yahoo.com>

Hi all:
Olivetti had the the original development environment written with a C generating backend written in C for different operating system machines, they intended to realease it fully (probably it was) but performance showed was inferior to that of SRC environment at the time 2.x (Modula-3 to C written in Modula-3), which led to include Olivetti front end part as a library front end being part of the SRC distribution, later to deploy Network Objects high level intermediate code network logical layer.
Having a C backend this days wouldn't make sense if it was actually developed at some point, and up to a Professor remembers RMS wanted this to be donated to FSF so it could led to some sort to GPLed system, but there wasn't such a donation or haven't been done yet and it probably was related to the performance comparison (in the time of Olivetti and SRC 2.x systems) reason mentioned by Mick Jordan (see http://compilers.iecc.com/comparch/article/90-08-046 ) and later to M3CG (due SRC Modula-2+ system low level intermediate code) interface which has proven to be a good compromise between portability and performance.
If we could prove that Olivetti backend could be a plus in terms of M3 performance and portability to get it back and compare its actual performance with nowadays M3CG backend performance then this would have a point

Hope it helps, thanks in advance 
 

--- El vie, 1/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] C generating back end
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 1 de enero, 2010 18:42
> On 1 Jan
> 2010, at 18:05, Jay K
> wrote:
> Fyi I finally
> looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such
> functionality would
> probably be to "interleave" the old code and the
> new code within m3front.
> 
> I'd like to avoid that sort of
> interleaving.
> The
> "cleaner" way is probably to implement a new M3CG
> though and
> leave m3front unchanged.
> 
> This is a much better plan.
> I still think
> generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception
> handling feature.
> (ok, maybe generate both, in case some systems lack C++
> support)
> 
> We can use the gcc-backend exception handling
> support if anyone was prepared to work on it.
>  realize
> there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9.
> or even OpenBSD 
>       or Darwin where there are
> long standing forks 
>       (The OpenBSD patches are
> small and we carry/apply them.
>       The Apple changes I think
> are mainly in the frontends
>       which I think is how we get
> by.) 
> 
>      For efficient exception handling
> we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other
> benefits like perf 
>      less reach than gcc but hits the
> major platforms 
>      difficult for me to get started
> with sorry 
> 
>   integrated backend could/should be ported around and
> is fast 
>      a lot of work 
>      I think the first steps here are
> to learn about mach-o and elf file formats
>        as part of ports for
> other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 
> 
> 


      


From wagner at elegosoft.com  Sat Jan  2 11:54:06 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 02 Jan 2010 11:54:06 +0100
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with	-C
	option
In-Reply-To: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
Message-ID: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> What does -C do?

Make it a server process. From the manual:

      -C maxClients
                  Limits the number of simultaneous clients to maxClients.
                  Clients beyond the specified maximum are politely refused
                  service.

                  If this option is not specified, cvsupd serves one client in
                  the foreground and then exits.

Olaf

> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>
>> Any ideas? Interaction problem between threads and select?
>>
>> Olaf
>>
>> ----- Forwarded message from bugs at elego.de -----
>>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>>    From: CM3 <bugs at elego.de>
>> Reply-To: CM3 <bugs at elego.de>
>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>      To: @MISSING_DOMAIN
>>
>> #1080: CVSUPD server hangs if used with -C option
>> -----------------------------+----------------------------------------------
>>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>>      Type:  sw-bug          |           Status:  new
>>  Priority:  high            |        Milestone:
>> Component:  sys             |          Version:  5.8-RC3
>>  Severity:  critical        |         Keywords:
>>   Relnote:                  |     Confidential:  no
>>       Org:  Collabnet       |   Estimatedhours:  0
>>     Hours:  0               |         Billable:  0
>> Totalhours:  0               |
>> -----------------------------+----------------------------------------------
>> Htr:
>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
>>
>> Start the cvsupd server with -C option
>>
>> ./cvsupd -b /data/cvsupd -C 2
>>
>> Try cvsup client to connect to the sever
>>
>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>
>> The client connection will hang and after sometime we will get   
>> "Inactivity timeout"
>>
>>
>> Fix:
>>
>>
>>
>> Env:
>>
>>
>> -----------------------------+----------------------------------------------
>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
>> cvsup installed.
>>
>> The server starts find and there was no issues if I start the server
>> without -C option.
>>
>> Starting cvsupd server without -C option
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd
>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>
>> Then I did a client request as below
>>
>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>> Parsing supfile "/tmp/cvsupd.cfg"
>> Connecting to myserver.com
>> Connected to myserver.com
>> Rejected by server: Access denied
>> Will retry at 21:37:09
>>
>> So the request was successful and I get a valid error message at the
>> client.
>>
>> But when I start the server with -C option like the one as below, requests
>> from client are hanging and eventually getting "Inactivity timeout" after
>> sometime.
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>
>> When ever a new client connection was made, this daemon clones another
>> cvsupd process and it also hangs. So none of the client request were
>> processed.
>>
>> Strace of the main cvsupd server process, when a new client request was
>> fired.
>>
>> -----------------------------------
>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>> gettimeofday({1262103026, 146476}, NULL) = 0
>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> close(7)                                = 0
>> gettimeofday({1262103026, 147481}, NULL) = 0
>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
>> such file or directory)
>> write(5, "\0", 1)                       = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> clone(child_stack=0,
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> child_tidptr=0xb7f43708) = 6543
>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> close(6)                                = 0
>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
>> unavailable)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>
>> ------------------------------------
>>
>> gdb backtrace of the main cvsupd server process
>>
>> ------------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>> ../src/unix/Common/UnixC.c:301
>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
>> M3_A4bqCj_timeout=0xbfed9410) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:153
>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>> ------------------------------------------------
>>
>>
>> strace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>
>> -----------------------------------
>>
>> gdb backtrace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>> /lib/libpthread.so.0
>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>> ../src/FSServer.m3:231
>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:227
>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>>
>> -------------------------------------------
>>
>> So it looks like both the main and cloned cvsupd processes were waiting
>> for a response from the kernel call "__kernel_vsyscall ()". Under what
>> condition will this happen? Am I doing something wrong here?
>>
>> --
>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>> CM3 <http://projects.elego.de/cm3>
>> Critical Mass Modula3 Compiler
>>
>>
>> ----- End forwarded message -----
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Sat Jan  2 18:20:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:20:04 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F8044.2080403@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 
> Having a generic interface and a normal one with the same name is a common
> pattern for me, at least.
> 
> You often have a single supertype and then many subtypes that are related
> to that supertype by being extended with, say, a field of an arbitrary type.
> 
> Then you get...
> 
> INTERFACE Stuff; TYPE T ... END Stuff.
> 
> GENERIC INTERFACE Stuff(Specializing);
> IMPORT Stuff;
> TYPE T = Stuff.T OBJECT special : Specializing.T END;
> END Stuff.
> 
> INTERFACE SpecialStuff = Stuff(Special)
> 
> Very convenient to use the same name at the top level, I think.
> 
>     Mika

Yuck! I hate this.  One of the things I really hate about Java and C++ is
having many different ways in which a reference to an identifier is looked
up, depending on the context of the reference.  This is one of the big ways
a language gets obscenely overcomplicated without providing any useful benefits.

One of Modula-3's strengths is that when an unqualified identifier is
referenced, it is always looked up according to the same rules, no matter
what kind of thing it is.  Only afterwards are semantic rules applied like,
e.g., the context requires a type but the identifier is a constant.

Except for this example, which I had missed up until now.  IMPORT Stuff
(and also EXPORTS Stuff) looks up Stuff as a global name in a different
way from INTERFACE SpecialStuff = Stuff(Special).  Unfortunately, the language
fails to address this at all in 2.5.5, and the implementation managed to
get away with violating the principle.  So now we have a bit of a slip into
the evil world of junk programming languages.

As for its being convenient, it may save a bit of effort during the initial
coding phase, by not requiring you to think up distinct names, but it is a
cruel and inhuman punishment to inflict on the miserable but innocent wretch who
has to maintain  your code later.  And in just case someone needs to be reminded,
coding is short.  Maintenance is long, sometimes almost forever.

We really should amend the language to say that ordinary and generic interfaces
combined must all have distinct global names.  Likewise for ordinary and
generic modules.

> 


From rodney_bates at lcwb.coop  Sat Jan  2 18:42:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:42:34 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F858A.8070001@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 

On a separate issue, one of the things that the C++ template facility really
botched badly is that instantiations not only can be, but must be, anonymous.
So every single time you want to refer to it, you have to repeat the template
actuals list.  It makes for some very ponderous and confusing code to read,
especially if there are multiple instantiations involved.  It also makes the
semantic analysis unnecessarily difficult for both the human reader and compiler.

In Modula-3 an instantiation must be done once, giving it a simple name, with
the name used thereafter everywhere the instantiation is referred-to.


From jay.krell at cornell.edu  Sat Jan  2 20:18:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 19:18:58 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <4B3F858A.8070001@lcwb.coop>
References: <20091230144007.081152474001@birch.elegosoft.com>, ,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>,
	<20100101230223.355441A2080@async.async.caltech.edu>,
	<4B3F858A.8070001@lcwb.coop>
Message-ID: <COL101-W2278F183A7D8B3C0574A73E6760@phx.gbl>


> Date: Sat, 2 Jan 2010 11:42:34 -0600
> From: rodney
> On a separate issue, one of the things that the C++ template facility really
> botched badly is that instantiations not only can be, but must be, anonymous.


Can be, but not must be.


for types:
  typedef vector<int> vi_t.


for functions, well, usually the parameters are deduced and you
don't have to say them:


template <typename T> T max(const T& a, const T& b)
{
  return (a > b ? a : b);
}


max(1, 2);


If you have something like:


template <typename T> T* New() { return new T(); }

then you do have to say New<Foo>().
You could do something onerous like:
Foo* (*const NewFoo)() = New<T>;


There is a new feature that might enable:


const auto NewFoo = New<T>;



but really, deduction of function template parameters is a very good thing,
no need to fight it, and making the parameters explicit
for some scenarios is not so bad.


There are some very confusing things about templates:
  How much can be checked without instantiation?
  Which names are bound at template definition vs. instantiation?
  Can "template metaprogramming" be done in a more direct way instead
    of seemingly just being an accident?


And (with reverse spin) there are some very powerful things you can do with templates:
   template meta programming :) 
   very good levels of inlining where otherwise you'd have little choice but to use
     function pointers and have poor efficiency (though, not that you can't 
     implement things easily enough and have them at least work without templates)
   not sure the term, but have you seen how in C++ you can write:
     a = b + c + d + e;


where the types involves are vectors/matrices and it compiles down
to have no temporary vectors/matrices.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/76746498/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  2 20:35:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 2 Jan 2010 13:35:59 -0600
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
Message-ID: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>

So, what's changed recently to break this?  It must have been working  
relatively recently.

Sent from my iPhone

On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> What does -C do?
>
> Make it a server process. From the manual:
>
>     -C maxClients
>                 Limits the number of simultaneous clients to  
> maxClients.
>                 Clients beyond the specified maximum are politely  
> refused
>                 service.
>
>                 If this option is not specified, cvsupd serves one  
> client in
>                 the foreground and then exits.
>
> Olaf
>
>> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>>
>>> Any ideas? Interaction problem between threads and select?
>>>
>>> Olaf
>>>
>>> ----- Forwarded message from bugs at elego.de -----
>>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
>>>   From: CM3 <bugs at elego.de>
>>> Reply-To: CM3 <bugs at elego.de>
>>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>>     To: @MISSING_DOMAIN
>>>
>>> #1080: CVSUPD server hangs if used with -C option
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Reporter:  rajeshvadivelu  |            Owner:  wagner
>>>     Type:  sw-bug          |           Status:  new
>>> Priority:  high            |        Milestone:
>>> Component:  sys             |          Version:  5.8-RC3
>>> Severity:  critical        |         Keywords:
>>>  Relnote:                  |     Confidential:  no
>>>      Org:  Collabnet       |   Estimatedhours:  0
>>>    Hours:  0               |         Billable:  0
>>> Totalhours:  0               |
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Htr:
>>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
>>> package.
>>>
>>> Start the cvsupd server with -C option
>>>
>>> ./cvsupd -b /data/cvsupd -C 2
>>>
>>> Try cvsup client to connect to the sever
>>>
>>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>>
>>> The client connection will hang and after sometime we will get   
>>> "Inactivity timeout"
>>>
>>>
>>> Fix:
>>>
>>>
>>>
>>> Env:
>>>
>>>
>>> ----------------------------- 
>>> +----------------------------------------------
>>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
>>> my cvs
>>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
>>> the
>>> cvsup installed.
>>>
>>> The server starts find and there was no issues if I start the server
>>> without -C option.
>>>
>>> Starting cvsupd server without -C option
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd
>>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
>>> 21:02:46
>>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>>
>>> Then I did a client request as below
>>>
>>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>> Parsing supfile "/tmp/cvsupd.cfg"
>>> Connecting to myserver.com
>>> Connected to myserver.com
>>> Rejected by server: Access denied
>>> Will retry at 21:37:09
>>>
>>> So the request was successful and I get a valid error message at the
>>> client.
>>>
>>> But when I start the server with -C option like the one as below,  
>>> requests
>>> from client are hanging and eventually getting "Inactivity  
>>> timeout" after
>>> sometime.
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>>
>>> When ever a new client connection was made, this daemon clones  
>>> another
>>> cvsupd process and it also hangs. So none of the client request were
>>> processed.
>>>
>>> Strace of the main cvsupd server process, when a new client  
>>> request was
>>> fired.
>>>
>>> -----------------------------------
>>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
>>> 553000})
>>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>>> gettimeofday({1262103026, 146476}, NULL) = 0
>>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> close(7)                                = 0
>>> gettimeofday({1262103026, 147481}, NULL) = 0
>>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
>>> ENOENT (No
>>> such file or directory)
>>> write(5, "\0", 1)                       = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> clone(child_stack=0,
>>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>>> child_tidptr=0xb7f43708) = 6543
>>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> close(6)                                = 0
>>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>>
>>> ------------------------------------
>>>
>>> gdb backtrace of the main cvsupd server process
>>>
>>> ------------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>>> ../src/unix/Common/UnixC.c:301
>>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
>>> (M3_Cwb5VA_nfd=4,
>>> M3_A4bqCj_timeout=0xbfed9410) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
>>> '\001')
>>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
>>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:153
>>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>> ------------------------------------------------
>>>
>>>
>>> strace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>>
>>> -----------------------------------
>>>
>>> gdb backtrace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>>> /lib/libpthread.so.0
>>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
>>> M3_AicXUJ_alertable=0
>>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
>>> ThreadPThread.m3:280
>>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
>>> SigHandler.m3:243
>>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>>> ../src/FSServer.m3:231
>>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:227
>>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>>
>>> -------------------------------------------
>>>
>>> So it looks like both the main and cloned cvsupd processes were  
>>> waiting
>>> for a response from the kernel call "__kernel_vsyscall ()". Under  
>>> what
>>> condition will this happen? Am I doing something wrong here?
>>>
>>> --
>>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>>> CM3 <http://projects.elego.de/cm3>
>>> Critical Mass Modula3 Compiler
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>>
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
>>> ermany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
>>>  Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> any
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> rlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>


From jay.krell at cornell.edu  Sat Jan  2 22:42:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 21:42:22 +0000
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with
	-C	option
In-Reply-To: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
Message-ID: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>


 > It must have been working relatively recently.

This is probably the first time it has been tested since getting into our tree.

 - Jay

> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Sat, 2 Jan 2010 13:35:59 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C	option
> 
> So, what's changed recently to break this?  It must have been working  
> relatively recently.
> 
> Sent from my iPhone
> 
> On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> >
> >> What does -C do?
> >
> > Make it a server process. From the manual:
> >
> >     -C maxClients
> >                 Limits the number of simultaneous clients to  
> > maxClients.
> >                 Clients beyond the specified maximum are politely  
> > refused
> >                 service.
> >
> >                 If this option is not specified, cvsupd serves one  
> > client in
> >                 the foreground and then exits.
> >
> > Olaf
> >
> >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> >>
> >>> Any ideas? Interaction problem between threads and select?
> >>>
> >>> Olaf
> >>>
> >>> ----- Forwarded message from bugs at elego.de -----
> >>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
> >>>   From: CM3 <bugs at elego.de>
> >>> Reply-To: CM3 <bugs at elego.de>
> >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> >>>     To: @MISSING_DOMAIN
> >>>
> >>> #1080: CVSUPD server hangs if used with -C option
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Reporter:  rajeshvadivelu  |            Owner:  wagner
> >>>     Type:  sw-bug          |           Status:  new
> >>> Priority:  high            |        Milestone:
> >>> Component:  sys             |          Version:  5.8-RC3
> >>> Severity:  critical        |         Keywords:
> >>>  Relnote:                  |     Confidential:  no
> >>>      Org:  Collabnet       |   Estimatedhours:  0
> >>>    Hours:  0               |         Billable:  0
> >>> Totalhours:  0               |
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Htr:
> >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
> >>> package.
> >>>
> >>> Start the cvsupd server with -C option
> >>>
> >>> ./cvsupd -b /data/cvsupd -C 2
> >>>
> >>> Try cvsup client to connect to the sever
> >>>
> >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>>
> >>> The client connection will hang and after sometime we will get   
> >>> "Inactivity timeout"
> >>>
> >>>
> >>> Fix:
> >>>
> >>>
> >>>
> >>> Env:
> >>>
> >>>
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
> >>> my cvs
> >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
> >>> the
> >>> cvsup installed.
> >>>
> >>> The server starts find and there was no issues if I start the server
> >>> without -C option.
> >>>
> >>> Starting cvsupd server without -C option
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd
> >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
> >>> 21:02:46
> >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> >>>
> >>> Then I did a client request as below
> >>>
> >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>> Parsing supfile "/tmp/cvsupd.cfg"
> >>> Connecting to myserver.com
> >>> Connected to myserver.com
> >>> Rejected by server: Access denied
> >>> Will retry at 21:37:09
> >>>
> >>> So the request was successful and I get a valid error message at the
> >>> client.
> >>>
> >>> But when I start the server with -C option like the one as below,  
> >>> requests
> >>> from client are hanging and eventually getting "Inactivity  
> >>> timeout" after
> >>> sometime.
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> >>>
> >>> When ever a new client connection was made, this daemon clones  
> >>> another
> >>> cvsupd process and it also hangs. So none of the client request were
> >>> processed.
> >>>
> >>> Strace of the main cvsupd server process, when a new client  
> >>> request was
> >>> fired.
> >>>
> >>> -----------------------------------
> >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
> >>> 553000})
> >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> >>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> >>> gettimeofday({1262103026, 146476}, NULL) = 0
> >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> _llseek(7, 0, [0], SEEK_CUR)            = 0
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> close(7)                                = 0
> >>> gettimeofday({1262103026, 147481}, NULL) = 0
> >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
> >>> ENOENT (No
> >>> such file or directory)
> >>> write(5, "\0", 1)                       = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> clone(child_stack=0,
> >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> >>> child_tidptr=0xb7f43708) = 6543
> >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> >>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> close(6)                                = 0
> >>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>>
> >>> ------------------------------------
> >>>
> >>> gdb backtrace of the main cvsupd server process
> >>>
> >>> ------------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> >>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> >>> ../src/unix/Common/UnixC.c:301
> >>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
> >>> (M3_Cwb5VA_nfd=4,
> >>> M3_A4bqCj_timeout=0xbfed9410) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> >>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> >>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
> >>> '\001')
> >>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
> >>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> >>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> >>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:153
> >>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>> ------------------------------------------------
> >>>
> >>>
> >>> strace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> >>>
> >>> -----------------------------------
> >>>
> >>> gdb backtrace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> >>> /lib/libpthread.so.0
> >>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> >>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
> >>> M3_AicXUJ_alertable=0
> >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> >>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
> >>> ThreadPThread.m3:280
> >>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> >>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
> >>> SigHandler.m3:243
> >>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> >>> ../src/FSServer.m3:231
> >>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:227
> >>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>>
> >>> -------------------------------------------
> >>>
> >>> So it looks like both the main and cloned cvsupd processes were  
> >>> waiting
> >>> for a response from the kernel call "__kernel_vsyscall ()". Under  
> >>> what
> >>> condition will this happen? Am I doing something wrong here?
> >>>
> >>> --
> >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> >>> CM3 <http://projects.elego.de/cm3>
> >>> Critical Mass Modula3 Compiler
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>>
> >>>
> >>> --
> >>> Olaf Wagner -- elego Software Solutions GmbH
> >>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
> >>> ermany
> >>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
> >>>  Berlin
> >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> >>> DE163214194
> >>>
> >>
> >>
> >
> >
> >
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> >               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> > any
> > phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> > rlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> > DE163214194
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/c756c57e/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan  3 17:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Jan 2010 11:48:05 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
	<COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
Message-ID: <E842F070-580A-4D68-850F-DD4119515F35@cs.purdue.edu>

Can someone try with user threading to see if it is something in  
thread waiting?

Sent from my iPhone

On Jan 2, 2010, at 4:42 PM, Jay K <jay.krell at cornell.edu> wrote:

>  > It must have been working relatively recently.
>
> This is probably the first time it has been tested since getting  
> into our tree.
>
>  - Jay
>
> > From: hosking at cs.purdue.edu
> > To: wagner at elegosoft.com
> > Date: Sat, 2 Jan 2010 13:35:59 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if  
> used with -C	option
> >
> > So, what's changed recently to break this? It must have been working
> > relatively recently.
> >
> > Sent from my iPhone
> >
> > On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com>  
> wrote:
> >
> > > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > >
> > >> What does -C do?
> > >
> > > Make it a server process. From the manual:
> > >
> > > -C maxClients
> > > Limits the number of simultaneous clients to
> > > maxClients.
> > > Clients beyond the specified maximum are politely
> > > refused
> > > service.
> > >
> > > If this option is not specified, cvsupd serves one
> > > client in
> > > the foreground and then exits.
> > >
> > > Olaf
> > >
> > >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> > >>
> > >>> Any ideas? Interaction problem between threads and select?
> > >>>
> > >>> Olaf
> > >>>
> > >>> ----- Forwarded message from bugs at elego.de -----
> > >>> Date: Tue, 29 Dec 2009 16:23:23 -0000
> > >>> From: CM3 <bugs at elego.de>
> > >>> Reply-To: CM3 <bugs at elego.de>
> > >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> > >>> To: @MISSING_DOMAIN
> > >>>
> > >>> #1080: CVSUPD server hangs if used with -C option
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Reporter: rajeshvadivelu | Owner: wagner
> > >>> Type: sw-bug | Status: new
> > >>> Priority: high | Milestone:
> > >>> Component: sys | Version: 5.8-RC3
> > >>> Severity: critical | Keywords:
> > >>> Relnote: | Confidential: no
> > >>> Org: Collabnet | Estimatedhours: 0
> > >>> Hours: 0 | Billable: 0
> > >>> Totalhours: 0 |
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Htr:
> > >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz
> > >>> package.
> > >>>
> > >>> Start the cvsupd server with -C option
> > >>>
> > >>> ./cvsupd -b /data/cvsupd -C 2
> > >>>
> > >>> Try cvsup client to connect to the sever
> > >>>
> > >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>>
> > >>> The client connection will hang and after sometime we will get
> > >>> "Inactivity timeout"
> > >>>
> > >>>
> > >>> Fix:
> > >>>
> > >>>
> > >>>
> > >>> Env:
> > >>>
> > >>>
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror
> > >>> my cvs
> > >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to  
> get
> > >>> the
> > >>> cvsup installed.
> > >>>
> > >>> The server starts find and there was no issues if I start the  
> server
> > >>> without -C option.
> > >>>
> > >>> Starting cvsupd server without -C option
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd
> > >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> > >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30
> > >>> 21:02:46
> > >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> > >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> > >>>
> > >>> Then I did a client request as below
> > >>>
> > >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>> Parsing supfile "/tmp/cvsupd.cfg"
> > >>> Connecting to myserver.com
> > >>> Connected to myserver.com
> > >>> Rejected by server: Access denied
> > >>> Will retry at 21:37:09
> > >>>
> > >>> So the request was successful and I get a valid error message  
> at the
> > >>> client.
> > >>>
> > >>> But when I start the server with -C option like the one as  
> below,
> > >>> requests
> > >>> from client are hanging and eventually getting "Inactivity
> > >>> timeout" after
> > >>> sometime.
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> > >>>
> > >>> When ever a new client connection was made, this daemon clones
> > >>> another
> > >>> cvsupd process and it also hangs. So none of the client  
> request were
> > >>> processed.
> > >>>
> > >>> Strace of the main cvsupd server process, when a new client
> > >>> request was
> > >>> fired.
> > >>>
> > >>> -----------------------------------
> > >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0,
> > >>> 553000})
> > >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> > >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> > >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> > >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > >>> fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
> > >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > >>> gettimeofday({1262103026, 146476}, NULL) = 0
> > >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY| 
> O_LARGEFILE) = 7
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> _llseek(7, 0, [0], SEEK_CUR) = 0
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> close(7) = 0
> > >>> gettimeofday({1262103026, 147481}, NULL) = 0
> > >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1
> > >>> ENOENT (No
> > >>> such file or directory)
> > >>> write(5, "\0", 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> clone(child_stack=0,
> > >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> > >>> child_tidptr=0xb7f43708) = 6543
> > >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> > >>> futex(0x915a460, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> close(6) = 0
> > >>> accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> gdb backtrace of the main cvsupd server process
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> > >>> #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> > >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410)  
> at
> > >>> ../src/unix/Common/UnixC.c:301
> > >>> #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779
> > >>> (M3_Cwb5VA_nfd=4,
> > >>> M3_A4bqCj_timeout=0xbfed9410) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> > >>> #4 0x00f85c7a in ThreadPThread__XIOWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> > >>> M3_CtKayy_interval=1.7976931348623157e+308,  
> M3_AicXUJ_alertable=1
> > >>> '\001')
> > >>> at ../src/thread/PTHREAD/ThreadPThread.m3:936
> > >>> #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> > >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> > >>> #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> > >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> > >>> #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:153
> > >>> #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0)  
> at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>> ------------------------------------------------
> > >>>
> > >>>
> > >>> strace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> gdb backtrace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > >>> /lib/libpthread.so.0
> > >>> #2 0x00f886e6 in ThreadPThread__pthread_cond_wait  
> (cond=0x89c60b8,
> > >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> > >>> #3 0x00f81d9d in ThreadPThread__XWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,
> > >>> M3_AicXUJ_alertable=0
> > >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> > >>> #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> > >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/
> > >>> ThreadPThread.m3:280
> > >>> #5 0x00bd4e14 in SigHandler__ChangeState  
> (M3_BnMAgS_d=0xb7f9c4bc,
> > >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> > >>> #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/
> > >>> SigHandler.m3:243
> > >>> #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> > >>> ../src/FSServer.m3:231
> > >>> #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:227
> > >>> #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #10 0x00f717c8 in RTLinker__RunMainBody  
> (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>>
> > >>> -------------------------------------------
> > >>>
> > >>> So it looks like both the main and cloned cvsupd processes were
> > >>> waiting
> > >>> for a response from the kernel call "__kernel_vsyscall ()".  
> Under
> > >>> what
> > >>> condition will this happen? Am I doing something wrong here?
> > >>>
> > >>> --
> > >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> > >>> CM3 <http://projects.elego.de/cm3>
> > >>> Critical Mass Modula3 Compiler
> > >>>
> > >>>
> > >>> ----- End forwarded message -----
> > >>>
> > >>>
> > >>> --
> > >>> Olaf Wagner -- elego Software Solutions GmbH
> > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G
> > >>> ermany
> > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sit 
> z:
> > >>> Berlin
> > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > >>> DE163214194
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Olaf Wagner -- elego Software Solutions GmbH
> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ
> > > any
> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Be
> > > rlin
> > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > > DE163214194
> > >


From hendrik at topoi.pooq.com  Mon Jan  4 05:12:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 3 Jan 2010 23:12:22 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
	<0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <20100104041222.GD7180@topoi.pooq.com>

On Fri, Jan 01, 2010 at 06:42:34PM -0500, Tony Hosking wrote:
> On 1 Jan 2010, at 18:05, Jay K wrote:
> 
> > Fyi I finally looked at the 2.x implementation and the outputing of
> > C was implemented fairly directly at the m3front layer.
> > There wasn't the "M3CG" stuff.
> > 
> > 
> > Thus, the "easiest" way to get back such functionality would
> > probably be to "interleave" the old code and the new code within m3front.
> 
> I'd like to avoid that sort of interleaving.
> 
> > The "cleaner" way is probably to implement a new M3CG though and
> > leave m3front unchanged.
> 
> This is a much better plan.
> 
> > I still think generating portable C a great way to achieve portability.
> > Better yet maybe, generate C++ and use its exception handling feature.

There's a potential advantage in generating C++:  it might be possible 
to interoperate with C++.  Whether it's feasible to make the C++ 
readable and its contents stable is a big question, though.

-- hendrik


From jay.krell at cornell.edu  Mon Jan  4 12:50:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Jan 2010 11:50:47 +0000
Subject: [M3devel] exception handling and signal mask?
Message-ID: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>


"try" isn't supposed to save the signal mask, right?
I mean..like..finally doesn't restore it, right?
Nor does I suspect raise/except.


Specifically: Darwin.
There should be underscores in Target.m3 there?


Some of this /might/ be might fault.
In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.


Furthermore, um... you know (or if you don't, I'll tell you):


Many platforms have two versions of setjmp/longjmp.
One saves/restore the signal mask. One does not.
Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.

And then, furthermore, every system I've looked into recently except for NT
offers sigsetjmp/siglongjmp.
Their semantics when present are consistent.
Albeit less efficient.
sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.

So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..


Not saving the signal mask is potentially much faster, as it might require a syscall to get.
(Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)


I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
Not going ahead with sigsetjmp. Just yet.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100104/5ec01fea/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan  4 16:20:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Jan 2010 10:20:53 -0500
Subject: [M3devel] exception handling and signal mask?
In-Reply-To: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
References: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
Message-ID: <27F530A4-62ED-490E-83CA-E3045103B4E1@cs.purdue.edu>

On 4 Jan 2010, at 06:50, Jay K wrote:

> "try" isn't supposed to save the signal mask, right?
> I mean..like..finally doesn't restore it, right?
> Nor does I suspect raise/except.

Good question.   No, exception handling mechanisms should not be responsible for this.  The design principle is usually to make TRY as fast as possible at the expense of the exceptional case.  Signal mask restoration should be programmed explicitly in a FINALLY clause.

> Specifically: Darwin.
> There should be underscores in Target.m3 there?

So, short answer on Darwin is to prefer _setjmp/_longjmp.

Same on all other platforms.

> 
> 
> Some of this /might/ be might fault.
> In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.
> 
> 
> Furthermore, um... you know (or if you don't, I'll tell you):
> 
> 
> Many platforms have two versions of setjmp/longjmp.
> One saves/restore the signal mask. One does not.
> Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
> Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.
> 
> And then, furthermore, every system I've looked into recently except for NT
> offers sigsetjmp/siglongjmp.
> Their semantics when present are consistent.
> Albeit less efficient.
> sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
> They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.
> 
> So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..
> 
> 
> Not saving the signal mask is potentially much faster, as it might require a syscall to get.
> (Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)
> 
> 
> I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
> Not going ahead with sigsetjmp. Just yet.
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100104/12a92d60/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan  6 03:59:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Jan 2010 21:59:42 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
Message-ID: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>

Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question.  What say we clean things up, revert to the original clean language definition, and eliminate LONGINT?  It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away.  The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs.  These can be rewritten to something other than LONGINT.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100105/a780cde2/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan  6 07:12:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 06:12:17 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
Message-ID: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>


Can I still have:
 TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
or
 TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
? defined in an interface, not in the language?
 
 
If so, probably ok.
 
 
(And can I also somehow get:
 TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
 TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
or
 TYPE UINT32 = [0..16_FFFFFFFF];
 TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
?
)
 
 
Even on 32 bit machines?
 
 
I know there is interface Word.
 
 
And then, what is the difference between:
 
 
 on 32bit:
   INTEGER vs. [16_80000000..16_7FFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFF] 
 
 
 on 64bit:
   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 

 
Any at all?
Just that array sizes are cardinal?
 
 
I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

From hosking at cs.purdue.edu  Wed Jan  6 08:06:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:06:34 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
Message-ID: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>

What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.

On 6 Jan 2010, at 01:12, Jay K wrote:

> 
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
> 
> 
> If so, probably ok.
> 
> 
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
> 
> 
> Even on 32 bit machines?
> 
> 
> I know there is interface Word.
> 
> 
> And then, what is the difference between:
> 
> 
> on 32bit:
>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFF] 
> 
> 
> on 64bit:
>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
> 
> 
> Any at all?
> Just that array sizes are cardinal?
> 
> 
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/c075cbdb/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan  6 08:11:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:11:53 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>

PS  Any type that *requires* 64-bit could be represented as:

ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]

or

RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END

Is there ever a need to treat these as 64-bit integers?

On 6 Jan 2010, at 02:06, Tony Hosking wrote:

> What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFF] 
>> 
>> 
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>> 
>>> 
>>> 
>>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>>> 
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/b7a9f856/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan  6 09:01:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 08:01:12 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
Message-ID: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>


Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
 
 
As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
 
 
I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
 
 
Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
 
 
Not to mention inlining via special support in the frontend.
(I realize a good backend could do the same).
 
 
interface int64;
 
T = ARRAY[0..1] OF INTEGER.
 
PROCEDURE +(a,b:T):T;
PROCEDURE *(a,b:T):T;
PROCEDURE /(a,b:T):T;
 
 
?
 
 
etc...
 
 
Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Jan 2010 02:11:53 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> PS Any type that *requires* 64-bit could be represented as:
>
> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>
> or
>
> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>
> Is there ever a need to treat these as 64-bit integers?
>
> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>
> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>
> On 6 Jan 2010, at 01:12, Jay K wrote:
>
>
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
>
>
> If so, probably ok.
>
>
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
>
>
> Even on 32 bit machines?
>
>
> I know there is interface Word.
>
>
> And then, what is the difference between:
>
>
> on 32bit:
> INTEGER vs. [16_80000000..16_7FFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFF]
>
>
> on 64bit:
> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>
>
> Any at all?
> Just that array sizes are cardinal?
>
>
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan  6 13:28:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 12:28:02 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W23D9DB3D782C31760086AFE6720@phx.gbl>


Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we don't yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/26f1fbaf/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan  6 14:17:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 13:17:34 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>


Was truncated!..edited slightly to avoid..


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000








Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/db5c80f2/attachment-0001.html>

From mika at async.async.caltech.edu  Wed Jan  6 17:25:58 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 06 Jan 2010 08:25:58 -0800
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl> 
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <20100106162558.7B4101A2079@async.async.caltech.edu>

Forgot the #endif there?

(81)trs80:~>./a.out
48 4
(82)trs80:~>uname -a
FreeBSD trs80.async.caltech.edu 4.11-RELEASE FreeBSD 4.11-RELEASE #3: Mon Nov 21 20:27:08 PST 2005     root at trs80.async.caltech.edu:/usr/src/sys/compile/TRS80  i386

[lapdog:~] mika% cc jay.c
[lapdog:~] mika% ./a.out
768 4
[lapdog:~] mika% uname -a
Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
[lapdog:~] mika% 

Jay K writes:
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Was truncated!..edited slightly to avoid..
>
>
>From: jay.krell at cornell.edu
>To: m3devel at elegosoft.com
>Subject: double double double double checking jmp_buf size/alignment
>Date: Wed=2C 6 Jan 2010 12:28:02 +0000
>
>
>
>
>
>
>
>
>Getting this right is very important.
>  Well=2C we can overstate but it is wasteful.
>
>
>So anyone with any time=2C please compile/run this and send the "platform" =
>(uname -a) and the output=2C thanks.
>Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
>m3-sys/m3middle/src/Target.m3 and see if all three agree.
>
>
>I have checked a bunch of systems myself but extra checking is good.
>
>
>If you have a system we do not yet or any longer support=2C those are ok to=
>o.
> (e.g. Alpha_*=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)
>
>=20
>#include <setjmp.h>
>#include <stdio.h>
>
>#ifdef __GNUC__
>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B }) - sizeof(x))=
>)
>#else
>#define ALIGN_OF(x) ((int)__alignof(x))
>
>int main()
>{
>  printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIGN_OF(jmp_buf))=3B
>  return 0=3B
>}
>
>
>Thanks=2C
> - Jay
> 		 	   		  =
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Was truncated!..edited slightly to avoid..<br><br><br><hr id=3D"stopSpellin=
>g">From: jay.krell at cornell.edu<br>To: m3devel at elegosoft.com<br>Subject: dou=
>ble double double double checking jmp_buf size/alignment<br>Date: Wed=2C 6 =
>Jan 2010 12:28:02 +0000<br><br>
>
>
>
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Verdana=3B}
></style>
>
>
>Getting this right is very important.<br>&nbsp=3B Well=2C we can overstate =
>but it is wasteful.<br><br><br>So anyone with any time=2C please compile/ru=
>n this and send the "platform" (uname -a) and the output=2C thanks.<br>Or l=
>ook at m3-libs/m3core/src/C/*/Csetjmp.i3 and<br>m3-sys/m3middle/src/Target.=
>m3 and see if all three agree.<br><br><br>I have checked a bunch of systems=
> myself but extra checking is good.<br><br><br>If you have a system we do n=
>ot yet or any longer support=2C those are ok too.<br>&nbsp=3B(e.g. Alpha_*=
>=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)<br><br>&nbsp=3B<br>=
>#include &lt=3Bsetjmp.h&gt=3B<br>#include &lt=3Bstdio.h&gt=3B<br><br>#ifdef=
> __GNUC__<br>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B })=
> - sizeof(x)))<br>#else<br>#define ALIGN_OF(x) ((int)__alignof(x))<br><br>i=
>nt main()<br>{<br>&nbsp=3B printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIG=
>N_OF(jmp_buf))=3B<br>&nbsp=3B return 0=3B<br>}<br><br><br>Thanks=2C<br>&nbs=
>p=3B- Jay<br> 		 	   		  </body>
></html>=
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_--


From hosking at cs.purdue.edu  Wed Jan  6 17:42:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 11:42:56 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
Message-ID: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>

But my question is what are the current use-cases for LONGINT?  Do they justify retaining it?

On 6 Jan 2010, at 03:01, Jay K wrote:

> 
> Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
> 
> 
> As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
> 
> 
> I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
> 
> 
> Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
> 
> 
> Not to mention inlining via special support in the frontend.
> (I realize a good backend could do the same).
> 
> 
> interface int64;
> 
> T = ARRAY[0..1] OF INTEGER.
> 
> PROCEDURE +(a,b:T):T;
> PROCEDURE *(a,b:T):T;
> PROCEDURE /(a,b:T):T;
> 
> 
> ?
> 
> 
> etc...
> 
> 
> Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Jan 2010 02:11:53 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> PS Any type that *requires* 64-bit could be represented as:
>> 
>> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>> 
>> or
>> 
>> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>> 
>> Is there ever a need to treat these as 64-bit integers?
>> 
>> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>> 
>> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>> 
>> On 6 Jan 2010, at 01:12, Jay K wrote:
>> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>> INTEGER vs. [16_80000000..16_7FFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFF]
>> 
>> 
>> on 64bit:
>> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/a6aab279/attachment-0001.html>

From rodney_bates at lcwb.coop  Wed Jan  6 18:49:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 06 Jan 2010 11:49:46 -0600
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
	<1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
Message-ID: <4B44CD3A.9000501@lcwb.coop>



Tony Hosking wrote:
> But my question is what are the current use-cases for LONGINT?  Do they 
> justify retaining it?
> 

I want to code stuff that requires arithmetic in > 2^32 range, and be
portable between 32- and 64-bit targets.  Using a record with two
INTEGERs on 32-bit machines and INTEGER on 64-bit machines would require
a lot of code differences between the targets, and the differences
can be pervasive.

OTOH, using the record on all machines will not take advantage of native
64-bit arithmetic when available.

Encapsulating the arithmetic in function calls also would add a lot of
overhead, unless we had a compiler that would inline them, which, as
I understand, we do not.  It's also not as readable.  I am a staunch
opponent of adding user-definable operator overloading to get this
readability advantage, because it interacts with all kinds of things
and makes the language just absurdly overcomplicated.  But LONGINT
arithmetic is language-defined and highly constrained overloading,
so the language complexity impact is much less.


>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>     
> 


From rcolebur at SCIRES.COM  Wed Jan  6 21:03:02 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Wed, 6 Jan 2010 15:03:02 -0500
Subject: [M3devel] double double double double checking
	jmp_buf	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76F734@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Results on the following platforms are all identical:

Windows 2000, Intel Pentium 3:  64 4
Windows XP, Intel Core Duo T2400:  64 4
Windows Vista, Intel Core2 Duo P9600:  64 4

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, January 06, 2010 8:18 AM
To: m3devel
Subject: Re: [M3devel] double double double double checking jmp_buf size/alignment

Was truncated!..edited slightly to avoid..

________________________________
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000

Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)


#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/15d709fb/attachment-0001.html>

From jdp at polstra.com  Wed Jan  6 22:06:00 2010
From: jdp at polstra.com (John Polstra)
Date: Wed, 06 Jan 2010 13:06:00 -0800
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <4B44FB38.3040704@polstra.com>

File sizes and seek offsets (among other things) are 64 bits even on 
32-bit machines, and files these days are often larger than 4GB.  In 
many applications it is necessary to do arithmetic on such values. 
Also, the fact that Modula-3 traps integer overflows causes trouble when 
only 32 bits are used for file offsets.  I had to put an ugly 
work-around into CVSup to avoid an integer overflow fault caused by more 
than 4GB being sent on a TCP connection.

John

Tony Hosking wrote:
> What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>>
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>>
>>
>> If so, probably ok.
>>
>>
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>>
>>
>> Even on 32 bit machines?
>>
>>
>> I know there is interface Word.
>>
>>
>> And then, what is the difference between:
>>
>>
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFF]
>>
>>
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>>
>>
>> Any at all?
>> Just that array sizes are cardinal?
>>
>>
>> I don't know much about the language issues, but dealing with 64bit 
>> integers in 32bit Modula-3 ought to be about as easy and efficient as 
>> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
>> should be represented as 64bit integers, though they aren't yet..it 
>> seems to be a significant interface breaking change..though maybe 
>> range types aren't where LONGINT would be? I'll have to try that..
>>
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>>
>>>
>>>
>>> Now that Jay has carefully refactored all the C-dependent code, I'd 
>>> like to pose the following question. What say we clean things up, 
>>> revert to the original clean language definition, and eliminate 
>>> LONGINT? It was only ever there for compatibility with C headers 
>>> anyway, and these have all now been nicely abstracted away. The only 
>>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
>>> structs. These can be rewritten to something other than LONGINT.
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> 


From jay.krell at cornell.edu  Thu Jan  7 04:35:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 03:35:55 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <4B44FB38.3040704@polstra.com>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<4B44FB38.3040704@polstra.com>
Message-ID: <COL101-W37A4D23768FBED635EB116E6710@phx.gbl>


We still have a bug where merely browsing to a directory with a file > 4GB with the Trestle GUI raises an unhandled exception.
Ideally LONGINT or [0..16_7FFFFFFFFFFFFFFF or higher] would be the type for file sizes everywhere.
It is currently INTEGER and changing it to LONGINT breaks stuff. I'll try the subrange..maybe that'll compile...
I think I proposed changing the type to "double" but nobody including me is super keen on that.
Double does have an interesting property of offering far more range than a 32bit integer on all systems going way back...
 (53bits typically of precision within a 64bit double)

 - Jay


> Date: Wed, 6 Jan 2010 13:06:00 -0800
> From: jdp at polstra.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] A "radical" proposal:  drop LONGINT
> 
> File sizes and seek offsets (among other things) are 64 bits even on 
> 32-bit machines, and files these days are often larger than 4GB.  In 
> many applications it is necessary to do arithmetic on such values. 
> Also, the fact that Modula-3 traps integer overflows causes trouble when 
> only 32 bits are used for file offsets.  I had to put an ugly 
> work-around into CVSup to avoid an integer overflow fault caused by more 
> than 4GB being sent on a TCP connection.
> 
> John
> 
> Tony Hosking wrote:
> > What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> > machines INTEGER would still be 32-bit.
> > 
> > On 6 Jan 2010, at 01:12, Jay K wrote:
> > 
> >>
> >> Can I still have:
> >> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> or
> >> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> ? defined in an interface, not in the language?
> >>
> >>
> >> If so, probably ok.
> >>
> >>
> >> (And can I also somehow get:
> >> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> >> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> >> or
> >> TYPE UINT32 = [0..16_FFFFFFFF];
> >> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> >> ?
> >> )
> >>
> >>
> >> Even on 32 bit machines?
> >>
> >>
> >> I know there is interface Word.
> >>
> >>
> >> And then, what is the difference between:
> >>
> >>
> >> on 32bit:
> >>   INTEGER vs. [16_80000000..16_7FFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFF]
> >>
> >>
> >> on 64bit:
> >>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
> >>
> >>
> >> Any at all?
> >> Just that array sizes are cardinal?
> >>
> >>
> >> I don't know much about the language issues, but dealing with 64bit 
> >> integers in 32bit Modula-3 ought to be about as easy and efficient as 
> >> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
> >> should be represented as 64bit integers, though they aren't yet..it 
> >> seems to be a significant interface breaking change..though maybe 
> >> range types aren't where LONGINT would be? I'll have to try that..
> >>
> >>
> >> - Jay
> >>
> >>
> >> ________________________________
> >>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >>> Date: Tue, 5 Jan 2010 21:59:42 -0500
> >>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
> >>> Subject: [M3devel] A "radical" proposal: drop LONGINT
> >>>
> >>>
> >>>
> >>> Now that Jay has carefully refactored all the C-dependent code, I'd 
> >>> like to pose the following question. What say we clean things up, 
> >>> revert to the original clean language definition, and eliminate 
> >>> LONGINT? It was only ever there for compatibility with C headers 
> >>> anyway, and these have all now been nicely abstracted away. The only 
> >>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
> >>> structs. These can be rewritten to something other than LONGINT.
> >>>
> >>>
> >>> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >>> University
> >>> 305 N. University Street | West Lafayette | IN 47907 | USA
> >>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/7dd1b511/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan  7 07:59:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 06:59:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
Message-ID: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>


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/20100107/16b32603/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan  7 10:47:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 09:47:07 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>


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/20100107/dd342806/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan  7 12:22:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 11:22:37 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>


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/20100107/6cc326a8/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/6cc326a8/attachment-0001.txt>

From hendrik at topoi.pooq.com  Thu Jan  7 14:11:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 08:11:17 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <20100107131117.GA22266@topoi.pooq.com>

On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> 
> 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

In any case, is the proper type for file offsets [0..7fffffffffffffff] 
or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
effort to make that legal in Modula 3.

-- hendrik


From wagner at elegosoft.com  Thu Jan  7 14:52:10 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 07 Jan 2010 14:52:10 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>

Quoting hendrik at topoi.pooq.com:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>>
>> 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
>
> In any case, is the proper type for file offsets [0..7fffffffffffffff]
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> effort to make that legal in Modula 3.

Well, I don't think that should be any practical problem right now,
shouldn't it? But 32 bit offsets have been overcome for years even
on 32 bit systems, so I definitely think we should keep the LONGINT
type and even try to incompatibly change the internal file length
type (with due care and consideration of course).

And please not for the still unfinished release, but for the next
one.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Thu Jan  7 15:00:08 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 09:00:08 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <20100107140008.GA25288@topoi.pooq.com>

On Thu, Jan 07, 2010 at 02:52:10PM +0100, Olaf Wagner wrote:
> Quoting hendrik at topoi.pooq.com:
> 
> >In any case, is the proper type for file offsets [0..7fffffffffffffff]
> >or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> >effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it?

Not just yet.  But it will be, and I suspect Modula 3 will still be 
around then.

-- hendrik


From hosking at cs.purdue.edu  Thu Jan  7 16:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:12:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <82B392A0-160D-4CD3-A36C-A64DFE7605ED@cs.purdue.edu>

I've generally found it easy enough to fix clients so they use ORD(size) to convert LONGINT to INTEGER at the boundary between the library definitions and the application.  This means they will get a run-time error if they access a file of size > LAST(INTEGER), so more pervasive changes will be needed to handle larger files.  But that is the responsibility of the client code,  not the library.  The whole point of LONGINT was to support large file sizes.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 01:59, Jay K wrote:

> 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/20100107/67014ed0/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:13:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:13:58 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <E6BEA822-6DE6-45E5-BBE9-CE0DCD37664D@cs.purdue.edu>

On 7 Jan 2010, at 04:47, Jay K wrote:

> 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

I discourage both of these, just to emphasize that INTEGER and LONGINT are independent types.  

> Most of the toplevel users will end up throwing in ORD, as they
> require files to fit in memory/addressspace.

Right.

> 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
> 



From hosking at cs.purdue.edu  Thu Jan  7 16:20:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:20:38 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
Message-ID: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>

On 7 Jan 2010, at 06:22, Jay K wrote:

> 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.

Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.

The problem below comes because I made WordRep and LongRep hidden interfaces.  I've just reverted m3core/src/word/m3makefile so things will now work.

> 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
> 
> <1.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/62f5857e/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:21:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:21:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <D21111F3-7947-4E4A-BBD6-9EED9A238C3B@cs.purdue.edu>

It will need to be a LONGINT type:  [0L..16_7fffffffffffffffL]


On 7 Jan 2010, at 08:11, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/400b4b56/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:23:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:23:04 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>

On 7 Jan 2010, at 08:52, Olaf Wagner wrote:

> Well, I don't think that should be any practical problem right now,

> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).

I think I am now persuaded LONGINT should stay.  But, I don't understand what "incompatibly change the internal file length
type (with due care and consideration of course)" means?

> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hendrik at topoi.pooq.com  Thu Jan  7 17:46:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 11:46:20 -0500
Subject: [M3devel] Integers
Message-ID: <20100107164620.GA30061@topoi.pooq.com>

I have some questions as to the constraints that need to be placed on 
integral types.  These issues are fundamental to an understanding of the 
role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
about them.

Is there a need for an integer type that can contain all the sizes of 
integers that can be handled by the language?  I'll call it TOP just so 
I can talk about it easily.

If it is necessary, is TOP only needed to make the language definition 
clean and concise?  Conversely, is it necessary for TOP to be available 
to programmers?  Is it necessary for TOP to be efficiently implemented, 
or implemented at all?

Even if it is not available directly to programmers, are there language 
features that require it internally?

Is it necessary that, for every two integer subranges I and J, there 
exist an integer range K such that both I and J are subranges of K?

The most commonly used integral type is INTEGER.  It seems to be the 
type used by programmers by default when they don't want to think of 
the specific range they will need.  But is it necessary for the type 
called INTEGER to be TOP?  Or, is there is no maximum implemented 
integral type, is it still necessary for INTEGER to be a maximal 
integral type?

-- hendrik



From jay.krell at cornell.edu  Thu Jan  7 18:26:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 17:26:55 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>


> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);



after:
  a := ORD(Rd.Length(b));

  c := ORD(Rd.Index(b));


  Rd.Seek(b, VAL(d, LONGINT));




Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/3fe806a3/attachment-0001.html>

From mika at async.async.caltech.edu  Thu Jan  7 18:47:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 09:47:28 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <20100107174728.3A3D41A207D@async.async.caltech.edu>

Jay K writes:
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
...
>One more compatible alternative might be to add LengthL=2C IndexL=2C SeekL?
>Maybe only break rd/wr implementers but not users?
>
>
>The reason I don't like that though is that it is even more of a no-op.
>Nobody will switch to the new functions.
>Similar to how "today" everybody will just ORD/VAL over the difference.

Isn't this what the <*OBSOLETE*> pragma is for?

     Mika

>
>
>To be clear though=2C the time for this change was 10 or 20 years ago.
>Now=2C 32bit systems are going away and with them this problem.
>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I think Op=
>enBSD..)
>
>
> - Jay
>
>
>> Date: Thu=2C 7 Jan 2010 14:52:10 +0100
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>>=20
>> Quoting hendrik at topoi.pooq.com:
>>=20
>> > On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=2C Jay K wrote:
>> >>
>> >> File.i3:
>> >>
>> >>
>> >>   Status =3D RECORD
>> >>     type: Type=3B
>> >>     modificationTime: Time.T=3B
>> >>     size: CARDINAL (* oops... *)
>> >>   END=3B
>> >>
>> >>
>> >> What to do?
>> >> [0.. higher than 7FFFFFFF] doesn't "just work".
>> >>    higher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"  =
>=20
>> >> on the end=2C
>> >>    which presumably has some relationship to turning it into a  =20
>> >> LONGINT=2C which
>> >>    causes users to fail to compile
>> >
>> > In any case=2C is the proper type for file offsets [0..7fffffffffffffff=
>]
>> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
>> > effort to make that legal in Modula 3.
>>=20
>> Well=2C I don't think that should be any practical problem right now=2C
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems=2C so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>>=20
>> And please not for the still unfinished release=2C but for the next
>> one.
>>=20
>> Olaf
>> --=20
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C G=
>ermany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86=
> 95
>>     http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: B=
>erlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=
>194
>>=20
> 		 	   		  =
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>&gt=3B Not in the current release<br><br>Agreed.<br><br><br>I think I'll ha=
>ve this done in the next few days=2C with the<br>major caveat that it does =
>break a lot of code. I'll fix the cm3 tree.<br><br><br>The breakage is roug=
>hly:<br><br><br>rd/wr users:<br>before:<br>&nbsp=3B a :=3D Rd.Length(b)=3B<=
>br>&nbsp=3B c :=3D Rd.Index(b)=3B<br>&nbsp=3B Rd.Seek(b=2C d)=3B<br>
><br><br>after:<br>&nbsp=3B a :=3D ORD(Rd.Length(b))=3B<br>
>&nbsp=3B c :=3D ORD(Rd.Index(b))=3B<br>
>
>&nbsp=3B Rd.Seek(b=2C VAL(d=2C LONGINT))=3B<br>
>
><br><br>Though I think the last line should just work without change.<br><b=
>r><br>rd/wr implementers:<br>&nbsp=3Bmore substantial changes=2C but still =
>similar=2C lots of ORD/VAL=2C and "L".<br><br><br>One more compatible alter=
>native might be to add LengthL=2C IndexL=2C SeekL?<br>Maybe only break rd/w=
>r implementers but not users?<br><br><br>The reason I don't like that thoug=
>h is that it is even more of a no-op.<br>Nobody will switch to the new func=
>tions.<br>Similar to how "today" everybody will just ORD/VAL over the diffe=
>rence.<br><br><br>To be clear though=2C the time for this change was 10 or =
>20 years ago.<br>Now=2C 32bit systems are going away and with them this pro=
>blem.<br>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I=
> think OpenBSD..)<br><br><br>&nbsp=3B- Jay<br><br><br>&gt=3B Date: Thu=2C 7=
> Jan 2010 14:52:10 +0100<br>&gt=3B From: wagner at elegosoft.com<br>&gt=3B To:=
> m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] what to do about fi=
>le sizes being 32bits?<br>&gt=3B <br>&gt=3B Quoting hendrik at topoi.pooq.com:=
><br>&gt=3B <br>&gt=3B &gt=3B On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=
>=2C Jay K wrote:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B File.i3:<br>=
>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   Status =
>=3D RECORD<br>&gt=3B &gt=3B&gt=3B     type: Type=3B<br>&gt=3B &gt=3B&gt=3B =
>    modificationTime: Time.T=3B<br>&gt=3B &gt=3B&gt=3B     size: CARDINAL (=
>* oops... *)<br>&gt=3B &gt=3B&gt=3B   END=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B What to do?<br>&gt=3B &gt=3B&gt=3B =
>[0.. higher than 7FFFFFFF] doesn't "just work".<br>&gt=3B &gt=3B&gt=3B    h=
>igher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"   <br>&gt=
>=3B &gt=3B&gt=3B on the end=2C<br>&gt=3B &gt=3B&gt=3B    which presumably h=
>as some relationship to turning it into a   <br>&gt=3B &gt=3B&gt=3B LONGINT=
>=2C which<br>&gt=3B &gt=3B&gt=3B    causes users to fail to compile<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B In any case=2C is the proper type for file offs=
>ets [0..7fffffffffffffff]<br>&gt=3B &gt=3B or [0..ffffffffffffffff]?  I sus=
>pect the latter.  It might take some<br>&gt=3B &gt=3B effort to make that l=
>egal in Modula 3.<br>&gt=3B <br>&gt=3B Well=2C I don't think that should be=
> any practical problem right now=2C<br>&gt=3B shouldn't it? But 32 bit offs=
>ets have been overcome for years even<br>&gt=3B on 32 bit systems=2C so I d=
>efinitely think we should keep the LONGINT<br>&gt=3B type and even try to i=
>ncompatibly change the internal file length<br>&gt=3B type (with due care a=
>nd consideration of course).<br>&gt=3B <br>&gt=3B And please not for the st=
>ill unfinished release=2C but for the next<br>&gt=3B one.<br>&gt=3B <br>&gt=
>=3B Olaf<br>&gt=3B -- <br>&gt=3B Olaf Wagner -- elego Software Solutions Gm=
>bH<br>&gt=3B                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 =
>Berlin=2C Germany<br>&gt=3B phone: +49 30 23 45 86 96  mobile: +49 177 2345=
> 869  fax: +49 30 23 45 86 95<br>&gt=3B     http://www.elegosoft.com | Gesc=
>h=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin<br>&gt=3B Handelregister: Amtsg=
>ericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>&gt=3B <br> 		 	=
>   		  </body>
></html>=
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_--


From hosking at cs.purdue.edu  Thu Jan  7 19:58:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 13:58:51 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100107164620.GA30061@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
Message-ID: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>

I think your confusion relates to understanding how the language defines "base" types.

You should understand that INTEGER and LONGINT have *different* base types.  This indicates that they have inherently different representations, and indeed, operations on INTEGER and operations on LONGINT are inherently different.

Every enumeration type similarly has a base type.  If it's range is expressed over INTEGER values then its base type is INTEGER.  If expressed over LONGINT then its base type is LONGINT.

I don't think I understand the rest of your questions.

On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:

> I have some questions as to the constraints that need to be placed on 
> integral types.  These issues are fundamental to an understanding of the 
> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> about them.
> 
> Is there a need for an integer type that can contain all the sizes of 
> integers that can be handled by the language?  I'll call it TOP just so 
> I can talk about it easily.
> 
> If it is necessary, is TOP only needed to make the language definition 
> clean and concise?  Conversely, is it necessary for TOP to be available 
> to programmers?  Is it necessary for TOP to be efficiently implemented, 
> or implemented at all?
> 
> Even if it is not available directly to programmers, are there language 
> features that require it internally?
> 
> Is it necessary that, for every two integer subranges I and J, there 
> exist an integer range K such that both I and J are subranges of K?
> 
> The most commonly used integral type is INTEGER.  It seems to be the 
> type used by programmers by default when they don't want to think of 
> the specific range they will need.  But is it necessary for the type 
> called INTEGER to be TOP?  Or, is there is no maximum implemented 
> integral type, is it still necessary for INTEGER to be a maximal 
> integral type?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/747bbe2e/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 20:07:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:07:03 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>

Jay,

I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony

On 7 Jan 2010, at 12:26, Jay K wrote:

> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/d34fcf55/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 20:17:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:17:40 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>

I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 14:07, Tony Hosking wrote:

> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
>> > Not in the current release
>> 
>> Agreed.
>> 
>> 
>> I think I'll have this done in the next few days, with the
>> major caveat that it does break a lot of code. I'll fix the cm3 tree.
>> 
>> 
>> The breakage is roughly:
>> 
>> 
>> rd/wr users:
>> before:
>>   a := Rd.Length(b);
>>   c := Rd.Index(b);
>>   Rd.Seek(b, d);
>> 
>> 
>> after:
>>   a := ORD(Rd.Length(b));
>>   c := ORD(Rd.Index(b));
>>   Rd.Seek(b, VAL(d, LONGINT));
>> 
>> 
>> Though I think the last line should just work without change.
>> 
>> 
>> rd/wr implementers:
>>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
>> 
>> 
>> One more compatible alternative might be to add LengthL, IndexL, SeekL?
>> Maybe only break rd/wr implementers but not users?
>> 
>> 
>> The reason I don't like that though is that it is even more of a no-op.
>> Nobody will switch to the new functions.
>> Similar to how "today" everybody will just ORD/VAL over the difference.
>> 
>> 
>> To be clear though, the time for this change was 10 or 20 years ago.
>> Now, 32bit systems are going away and with them this problem.
>> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
>> 
>> 
>>  - Jay
>> 
>> 
>> > Date: Thu, 7 Jan 2010 14:52:10 +0100
>> > From: wagner at elegosoft.com
>> > To: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
>> > 
>> > Quoting hendrik at topoi.pooq.com:
>> > 
>> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> > >>
>> > >> 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
>> > >
>> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
>> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
>> > > effort to make that legal in Modula 3.
>> > 
>> > Well, I don't think that should be any practical problem right now,
>> > shouldn't it? But 32 bit offsets have been overcome for years even
>> > on 32 bit systems, so I definitely think we should keep the LONGINT
>> > type and even try to incompatibly change the internal file length
>> > type (with due care and consideration of course).
>> > 
>> > And please not for the still unfinished release, but for the next
>> > one.
>> > 
>> > Olaf
>> > -- 
>> > Olaf Wagner -- elego Software Solutions GmbH
>> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/2b22053a/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan  7 21:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:31:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
Message-ID: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>


Given that files are in fact larger than 4GB, why should we impose such a limit?

Doesn't it make for a pretty lame system?

 

Pretty much no existing 32bit C system for many years now any such limit and

C started going past these limits around 15 years ago.

 

It turns out changes I sent were pretty nearly done. I can now build all of "std"

with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".

 

 

 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:  +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:  +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/ce27e7fb/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan  7 21:33:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:33:22 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>


I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,

and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).

This seems to be about the best we can do.

 

Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?

Therefore INTEGER and LONGINT somewhat interchangable?

 

 

Again, currently merely browsing to a directory with a large file raises an exception.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:07:03 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/b354dd13/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 22:33:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:33:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
Message-ID: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>

What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.

If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.

I am really starting to think the addition of LONGINT was a big mistake.

On 7 Jan 2010, at 15:31, Jay K wrote:

> Given that files are in fact larger than 4GB, why should we impose such a limit?
> Doesn't it make for a pretty lame system?
>  
> Pretty much no existing 32bit C system for many years now any such limit and
> C started going past these limits around 15 years ago.
>  
> It turns out changes I sent were pretty nearly done. I can now build all of "std"
> with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:17:40 -0500
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.
> 
> 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 7 Jan 2010, at 14:07, Tony Hosking wrote:
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone:  +49 30 23 45 86 96  +49 30 23 45 86 96 mobile:  +49 177 2345 869 +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/f80a2cd7/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan  7 22:37:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:37:12 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
Message-ID: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>

On 7 Jan 2010, at 15:33, Jay K wrote:

> I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,
> and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).
> This seems to be about the best we can do.

I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger than address spaces.  If someone really wants to use an OS-specific file size that is bigger than an address space then they can use the C interfaces, along with LONGINT.  If they are working with Rd/Wr then they don't need to mess with the ugliness.

>  Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?
> Therefore INTEGER and LONGINT somewhat interchangable?

Again, this contradicts the design principles of the Modula-3 type system.

>  Again, currently merely browsing to a directory with a large file raises an exception.

What code?  Does it use C interfaces or the Modula-3 interfaces?

>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:07:03 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/6cd9744d/attachment-0001.html>

From mika at async.async.caltech.edu  Fri Jan  8 01:31:10 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 16:31:10 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
	<D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>
Message-ID: <20100108003110.0BC1E1A207D@async.async.caltech.edu>

Tony Hosking writes:
>
>--Apple-Mail-29--1022292864
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=iso-8859-1
>
>On 7 Jan 2010, at 15:33, Jay K wrote:
>
>> I agree it isn't pretty but a big mistake was made many years ago, =
>assuming file sizes are no larger than address spaces,
>> and the current system might also not be so great (not allowing =
>comparing a LONGINT to "0" or assigning it from an INTEGER).
>> This seems to be about the best we can do.
>
>I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger =
>than address spaces.  If someone really wants to use an OS-specific file =
>size that is bigger than an address space then they can use the C =
>interfaces, along with LONGINT.  If they are working with Rd/Wr then =
>they don't need to mess with the ugliness.

Just to add my input to this discussion... 

I have programs that like to write huge log files (> 2GB), and with Wr.PutText
this is a problem.

But it's very easy to work around.  Use the RdWrReset interface implemented as
follows (not sure where I originally got this code from, Blair MacIntyre?):

MODULE RdWrReset;
IMPORT Rd AS R, Wr AS W;
IMPORT RdClass, WrClass;
<*NOWARN*>IMPORT UnsafeWr, UnsafeRd;

(* Since we need to use the Mutex properties of Rd.T and Wr.T, we
   should actually import UnsafeWr and UnsafeRd. We need to add the
   following revelations, as the comment in UnsafeRd points out, if we
   want to include both the Unsafe* and *Class interfaces. *)
REVEAL RdClass.Private <: MUTEX;
REVEAL WrClass.Private <: MUTEX;

PROCEDURE Rd (rd: R.T) =
  BEGIN
    LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END;
  END Rd;

PROCEDURE Wr (wr: W.T) =
  BEGIN
    LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END;
  END Wr;

BEGIN END RdWrReset.

So far this has sufficed for me...
    Mika


From jay.krell at cornell.edu  Fri Jan  8 02:07:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:07:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W19301B1547CB12BC8501ECE6700@phx.gbl>


 > As you are already aware, some systems have only 32-bit addressable files.

 

Really?!

I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.

4G has not been a large file size for quite a long time now.

FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.

Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.

 

 

 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.

 

 

I can build "std" now. It does escape pretty far, but it is actually fairly contained.

It would help a little of an INTEGER could be assigned to a LONGINT.

Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.

Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..

 

 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  

 

Isn't that pretty natural?

Aren't "file" one of the main things used with Rd/Wr?

Besides that, if you consider "streams", going beyond 4G seems even more limiting.

You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.

 

I agree that dealing with such large files can be difficult, depending on the algorithms.

But the "base" of the system shouldn't remove the ability for higher parts to do so.

 

 

And resorting to C seems unnecessary.

The operating system interfaces are essentially identical on Posix, as long you #define whatever.

They vary at the ABI level for compatibility.

 

 

Should I create a branch, or can we review the diffs and decide?

 

 

 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:   +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:   +49 177 2345 869  +49 177 2345 869   +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/7e7b9a43/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 02:09:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:09:11 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W17B8D1C035DBDB2940DF36E6700@phx.gbl>


To repeat myself, basically every system supports 64bit file sizes and they are easy to use from C.

In my opinion, a "systems" language is something you can do "anything" in.

Now, granted, the language isn't the issue here.

But conflation of libraries and languages is common and not entirely invalid.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:    +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96   mobile:    +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869   fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/45864588/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 02:18:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:18:51 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W260CDC61EC90506D4D79D8E6700@phx.gbl>


[truncated]

To repeat myself, basically every system supports 64bit file

sizes and they are easy to use from C.
In my opinion, a "systems" language is something you

can do "anything" in.
Now, granted, the language isn't the issue here.
But conflation of libraries and languages is common

and not entirely invalid.
 
 
 - Jay
 






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 






From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?



What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001        +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484        +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:     +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96        +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96    mobile:     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869       +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869    fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/733c2790/attachment-0001.html>

From rodney_bates at lcwb.coop  Fri Jan  8 02:22:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:22:00 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <4B4688B8.50701@lcwb.coop>

Full-range unsigned integers are a language designer's headache, because
there are conflicts no matter what you do.  The Modula-3 approach is to
use the operations in interface Word.i3 (and now Long.i3) on type
INTEGER (not CARDINAL, which has only half the range).  These apply
unsigned interpretation to values of type INTEGER.

hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 02:45:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:45:03 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B4688B8.50701@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>, <4B4688B8.50701@lcwb.coop>
Message-ID: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>


I understand "full range" is a problem, because, something like,

the set of operations isn't closed.

 

 

I believe you need to define multiple types and/or

multiple operations.

 

 

You need an ability to trap/fail on overflow.

You need an ability for silent wraparound on overflow.

You need perhaps a way to add precision as needed. Slow.

You need perhaps a way to specify arbitrarily high precision,

  and then, again, either trap/fail or silent wraparound.

 

 

Basically, in my opinion, having just "INTEGER" and just "+"

isn't nearly sufficient.

 

 

Not having operator overloading makes pretty much any solution painful to use.

 

 

We and C both have a compromise that covers most cases and

when people really need higher fixed or arbitrary precision, they

either give up the convenient "operator" syntax or use C++.

 

 

As I understand, in C, unsigned integers are defined to "silently wraparound"

and signed integers are implementation defined, could "trap" but in reality

all implementations "silently wraparound".

It is a point of unsafety though, beyond the more well known

buffer overflows, leaks, etc.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:22:00 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Full-range unsigned integers are a language designer's headache, because
> there are conflicts no matter what you do. The Modula-3 approach is to
> use the operations in interface Word.i3 (and now Long.i3) on type
> INTEGER (not CARDINAL, which has only half the range). These apply
> unsigned interpretation to values of type INTEGER.
> 
> hendrik at topoi.pooq.com wrote:
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >> 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
> > 
> > In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some 
> > effort to make that legal in Modula 3.
> > 
> > -- hendrik
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/21906409/attachment-0001.html>

From rodney_bates at lcwb.coop  Fri Jan  8 02:35:20 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:35:20 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <4B468BD8.4020106@lcwb.coop>


I addressed all these details in my original LONGINT proposal, but it
didn't get much attention at the time.  That would have been October
of 2007.  I can't find the posts right now, because the link
http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
too many email account changes to be able to find it in my own
inboxes.

I proposed, and still do, that LONGINT be an ordinal type.  This has
the consequence, by preexisting rules, that INTEGER and LONGINT would
be assignable to each other.  This does not violate the preexisting
language precedent, in fact, it is exactly like the preexisting rules
for INTEGER and all its subtypes--they are assignable if the value is
in the LHS type.

This eliminates the necessity for the ORD and VAL conversions in most
places, where there are mixtures of the types.  Most places in the
language require only assignability, not type equality.  Exceptions
include passing to a VAR formal and use in a type definition of a new
type.

A consequence of existing rules is that there would be, if necessary,
runtime value checks.  In many cases, including the examples we are
discussing here, assigning a LONGINT to an INTEGER could well
introduce a bug when a value is out of range, but this is no different
from what happens when ORD/VAL are coded explicitly.

On the other side of this argument, the necessity of coding ORD/VAL
would point out statically, places where value range errors should be
ruled out by the programmer.  A conscientious programmer would then
make an informed decision whether to just insert ORD/VAL, or whether
it was necessary to change the INTEGER variable to LONGINT.  But
again, the already existing rules for subranges don't do this, so
making INTEGER and LONGINT assignable would be consistent.

Note that right now, the current implementation has a linguistic
contradiction in that, if subranges of LONGINT are allowed, then
LONGINT is an ordinal type, which implies LONGINT and INTEGER are
mutually assignable.  This could, of course be fixed in the language,
but I would prefer making the two types assignable.




Jay K wrote:
> 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
> 


From rodney_bates at lcwb.coop  Fri Jan  8 02:37:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:37:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
Message-ID: <4B468C63.9050404@lcwb.coop>



Tony Hosking wrote:
> On 7 Jan 2010, at 06:22, Jay K wrote:
> 
>> 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.
> 
> Again, I discourage this as not in the spirit of the Modula-3 type 
> system which abhors implicit casts.
> 
Indeed, Modula-3 has no implicit casts at all.  But it does have something
that sometimes accomplishes the same result in a way that is far simpler
to define and represents a higher level of abstraction, namely, the
concept of assignability.  A value, e.g. 10, can be in the value set of
many types (INTEGER, many of its subranges, and now LONGINT and many if
its subranges too).  If so, it can in certain carefully specified cases,
be assigned from one of these types to another, without any syntactically
explicit notation required of the programmer.

This represents the more abstract view that 10 is 10, as opposed to the
usual view that 10 sitting in a byte is not the same as 10 in a word.
Of course, at the machine level. they are not the same, but in Modula-3,
that is only a representation matter that the compiler must take care of,
not a high-level language matter that needs pages of rules to define.

It took me years to fully understand the implications of replacing implicit
type conversions by the assignability concept, but I now consider it one
of Modula-3's great ideas, even if it is a small thing.


From jay.krell at cornell.edu  Fri Jan  8 03:01:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:01:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <COL101-W41E4AFA2D1DDE2CD2C39D7E6700@phx.gbl>


I apologize for not paying close attention at the time.

That seems to make sense to me now.

 

 

There is at least an in-between version where INTEGER

is assignable to LONGINT.

 

 

In your proposal, the amount of source change required would be

I think very very little. Some code would "just work" with large files,

and some code would fail.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:35:20 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time. That would have been October
> of 2007. I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type. This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other. This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.
> 
> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types. Most places in the
> language require only assignability, not type equality. Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.
> 
> A consequence of existing rules is that there would be, if necessary,
> runtime value checks. In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.
> 
> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer. A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT. But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.
> 
> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable. This could, of course be fixed in the language,
> but I would prefer making the two types assignable.
> 
> 
> 
> 
> Jay K wrote:
> > 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/20100108/9394f4b3/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 02:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
Message-ID: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>


I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/3f0be214/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 03:25:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:25:56 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>, ,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>, ,
	<4B468C63.9050404@lcwb.coop>,
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <COL101-W55238865FDCA7966D9D371E6700@phx.gbl>


Here are some of the old messages. I haven't yet found a proposal.


https://mail.elegosoft.com/pipermail/m3devel/2007-July/000323.html
https://mail.elegosoft.com/pipermail/m3devel/2007-July/
https://mail.elegosoft.com/pipermail/m3devel/

You have to allow the exception for the certificate.


 - Jay



From: jay.krell at cornell.edu
To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?








I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ea64c1af/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 04:35:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 03:35:44 +0000
Subject: [M3devel] longint..revisited?
Message-ID: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>


I can't find Rodney's proposal but I think I understand
a lot of it from today's mail.


Can we revisit this?


My understanding is that Rodney's proposal
deems INTEGER assignable to LONGINT,
and vice versa, and that assignments of LONGINT
to INTEGER undergo runtime range checks,
can raise exceptions.


I assume it also follows that:


LONGINT can be added/subtracted/modded to INTEGER,
yielding LONGINT.


INTEGER MOD LONGINT would range check the LONGINT.


INC/DEC(LONGINT, INTEGER) would just work


INC/DEC(INTEGER, LONGINT) would range check.


The downside is that the chance for failure would be
silently injected into various places.


Another proposal would be that INTEGER is assignable to LONGINT,
but not vice versa. I really don't see why not.


   LONGINT := INTEGER  
   LONGINT + INTEGER => LONGINT  
  


LONGINT - INTEGER => LONGINT  
  


LONGINT * INTEGER => LONGINT  
   LONGINT / INTEGER => LONGINT  
  
LONGINT MOD INTEGER => INTEGER (think about it) 
   INC(LONGINT, INTEGER)
  

DEC(LONGINT, INTEGER)





all seem very reasonable.


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/50e11a68/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri Jan  8 04:53:44 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 22:53:44 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
Message-ID: <20100108035343.GA9556@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> 
> I understand "full range" is a problem, because, something like,
> the set of operations isn't closed.

What does this mean?  What exactly do you mean by "full range"?  And 
what do you mean by "closed"?

> 
> I believe you need to define multiple types and/or
> multiple operations.
> 
> You need an ability to trap/fail on overflow.
> 
> You need an ability for silent wraparound on overflow.
> You need perhaps a way to add precision as needed. Slow.
> You need perhaps a way to specify arbitrarily high precision,
>   and then, again, either trap/fail or silent wraparound.
> 
> Basically, in my opinion, having just "INTEGER" and just "+"
> isn't nearly sufficient.
> 
> Not having operator overloading makes pretty much any solution painful to use.

+ is defined on integers and reals.  If that's not an overload, why not 
have + defined on longint as well?

> We and C both have a compromise that covers most cases and
> when people really need higher fixed or arbitrary precision, they
> either give up the convenient "operator" syntax or use C++.
>  
> 
> As I understand, in C, unsigned integers are defined to "silently wraparound"

The wraparound unsigned integers are extremely useful.  The most common 
operations, +, *, and - have a clean, well-defined semantics as 
arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
identifies.

Suppose you have an expression involving +, -, * and integers in 
0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
If you evaluate it with nonwraparound arithmetic, you may get overflow.
Nonetheless, using wraparound arithmetic under these conditions will 
still give the right answer.

This makes wraparound integers useful for indexing strange arrays with, 
say, multiple subscripts in the rante 1000000000..1000000003.  
Intermediate results partway through subscript evaluations can overflow 
to their hearts' content, and you still get the right element in the 
end.

> 
> and signed integers are implementation defined, could "trap" but in reality
> all implementations "silently wraparound".
> It is a point of unsafety though, beyond the more well known
> buffer overflows, leaks, etc.
> 
>  - Jay
> 
>  
> > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Full-range unsigned integers are a language designer's headache, because
> > there are conflicts no matter what you do. The Modula-3 approach is to
> > use the operations in interface Word.i3 (and now Long.i3) on type
> > INTEGER (not CARDINAL, which has only half the range). These apply
> > unsigned interpretation to values of type INTEGER.

The problem with Word.i3 is that expressions involving these integers 
are so unreadable as to be seriously susceptible to error.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 05:03:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 23:03:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
Message-ID: <20100108040333.GB9556@topoi.pooq.com>

On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
> I think your confusion relates to understanding how the language 
> defines "base" types.
> 
> You should understand that INTEGER and LONGINT have *different* base 
> types.  This indicates that they have inherently different 
> representations,

What's implicit in this statment is that all the subranges of INTEGER 
have inherently the same representation.  Why is this inportant?  Are 
there, for example,  places in the language where you have a subrange 
but don't know what the subrange is?

> and indeed, operations on INTEGER and operations on 
> LONGINT are inherently different.

So in the language at present, there is no single type at the top of the 
integer type lattice (and it's not really a lattice).  There are, 
however, two maximal types.  Is this right?

> 
> Every enumeration type similarly has a base type.  If it's range is 
> expressed over INTEGER values then its base type is INTEGER.  If 
> expressed over LONGINT then its base type is LONGINT.
> 
> I don't think I understand the rest of your questions.

Where in the language is it important that INTEGER and LONGINT be 
different base types?  In other words, what advantages does this 
separation convey?

-- hendrik
> 
> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
> 
> > I have some questions as to the constraints that need to be placed on 
> > integral types.  These issues are fundamental to an understanding of the 
> > role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> > about them.
> > 
> > Is there a need for an integer type that can contain all the sizes of 
> > integers that can be handled by the language?  I'll call it TOP just so 
> > I can talk about it easily.
> > 
> > If it is necessary, is TOP only needed to make the language definition 
> > clean and concise?  Conversely, is it necessary for TOP to be available 
> > to programmers?  Is it necessary for TOP to be efficiently implemented, 
> > or implemented at all?
> > 
> > Even if it is not available directly to programmers, are there language 
> > features that require it internally?
> > 
> > Is it necessary that, for every two integer subranges I and J, there 
> > exist an integer range K such that both I and J are subranges of K?
> > 
> > The most commonly used integral type is INTEGER.  It seems to be the 
> > type used by programmers by default when they don't want to think of 
> > the specific range they will need.  But is it necessary for the type 
> > called INTEGER to be TOP?  Or, is there is no maximum implemented 
> > integral type, is it still necessary for INTEGER to be a maximal 
> > integral type?
> > 
> > -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 07:07:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:07:08 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W45DD659513608DE2BE3F86E6700@phx.gbl>


I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case, n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case, 2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0397073c/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 07:41:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:41:09 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W530411D2F9C6E2619BD794E6700@phx.gbl>


[truncated again, I have a knack for
aiming near 80 columns and therefore getting
the period right where the mail software truncates..]




From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 06:07:08 +0000








I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case,
    n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case,
   2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ae9ef910/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 08:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 07:44:53 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
Message-ID: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>


This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.

 

  LONGINT + INTEGER => LONGINT 

  LONGINT - INTEGER => LONGINT 

  LONGINT * INTEGER => LONGINT 

  LONGINT DIV INTEGER => LONGINT 

  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 

  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  

  LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  

  MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

  MAX(INTEGER, LONGINT) => LONGINT  

  LONGINT := INTEGER 

 

Other mixes are less obvious and would require runtime checks.

 

I think the backend will just work but I haven't tried that yet.

 (Truth be told, I can only affectively edit files on NT...)

 

Thoughts?

 

 - Jay 

 

Index: builtinOps/Dec.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
retrieving revision 1.9
diff -u -r1.9 Dec.m3
--- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
+++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
@@ -44,7 +44,7 @@
     IF (NUMBER (ce.args^) > 1) THEN
       IF Type.IsSubtype (t, LInt.T) THEN
         t := Type.Base (Expr.TypeOf (ce.args[1]));
-        IF (t # LInt.T) THEN
+        IF t # LInt.T AND t # Int.T THEN
           Error.Txt (name, "second argument must be a LONGINT");
         END;
       ELSE
Index: builtinOps/Max.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
retrieving revision 1.3
diff -u -r1.3 Max.m3
--- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
+++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
@@ -25,11 +25,14 @@
 
 PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     ta := Type.Base (Expr.TypeOf (ce.args[0]));
     tb := Type.Base (Expr.TypeOf (ce.args[1]));
 
-    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
+    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
+      resultType := LInt.T;
+    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
       Error.Txt (name, "incompatible argument types");
     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
       (* ok *)
@@ -39,7 +42,11 @@
       Error.Txt (name, "wrong argument types");
       ta := Int.T;
     END;
-    ce.type := ta;
+    IF resultType # NIL THEN
+      ce.type := resultType;
+    ELSE
+      ce.type := ta;
+    END;
   END DoCheck;
 
 PROCEDURE Compile (ce: CallExpr.T) =
Index: exprs/AddExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 AddExpr.m3
--- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
+++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -67,6 +67,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -74,8 +75,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
-      p.class := Class.cLINT
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -96,7 +98,11 @@
     ELSE
       ta := Expr.BadOperands ("\'+\'", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/DivExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 DivExpr.m3
--- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,7 +60,7 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF (ta = Int.T) AND (tb = Int.T) THEN
       p.type := Int.T;
-    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.type := LInt.T;
     ELSE
       p.type := Expr.BadOperands ("DIV", ta, tb);
Index: exprs/ModExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 ModExpr.m3
--- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,6 +60,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -67,8 +68,18 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
+
     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
       p.class := Class.cLINT;
+
+    (* The result of MOD cannot be higher than either of its inputs.
+     * small divided by big is 0 remainder small
+     * big divided by small has a remainder of at most small
+     *)
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cINT;
+      resultType := Int.T;
+
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -78,7 +89,11 @@
     ELSE p.class := Class.cERR;  ta := Int.T;
       ta := Expr.BadOperands ("MOD", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/MultiplyExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 MultiplyExpr.m3
--- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
+++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -66,6 +66,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -73,8 +74,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
       p.class := cINT;
-    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := cLINT;
+      resultType := LInt.T;
     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
       p.class := cREAL;
     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
@@ -90,7 +92,11 @@
       ta := Expr.BadOperands ("\'*\'", ta, tb);
       p.class := cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/SubtractExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
retrieving revision 1.4
diff -u -r1.4 SubtractExpr.m3
--- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
+++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -73,6 +73,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -80,8 +81,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -113,7 +115,11 @@
       ta := Expr.BadOperands ("\'-\'", ta, tb);
       p.class := Class.cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: types/Type.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
retrieving revision 1.8
diff -u -r1.8 Type.m3
--- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
+++ types/Type.m3 8 Jan 2010 07:35:43 -0000
@@ -543,6 +543,10 @@
     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
       RETURN TRUE;
     ELSIF IsOrdinal (a) THEN
+      (* INTEGER is assignable to LONGINT *)
+      IF a = LInt.T AND b = Int.T THEN
+        RETURN TRUE;
+      END;
       (* ordinal types:  OK if there is a common supertype
          and they have at least one member in common. *)
       IF IsEqual (Base(a), Base(b), NIL)






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/49a9d43f/attachment-0001.html>

From wagner at elegosoft.com  Fri Jan  8 11:44:48 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 11:44:48 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
Message-ID: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>
>> Well, I don't think that should be any practical problem right now,
>
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems, so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>
> I think I am now persuaded LONGINT should stay.  But, I don't   
> understand what "incompatibly change the internal file length
> type (with due care and consideration of course)" means?

I only just got round to reading all those mails.

I meant changing the file lengths and offsets in all our libraries,
like Rd/Wr. Basically what Jay has started on right away ;-)

I agree that this should be done in a feature branch though.
Changes should be reviewed.
Regression tests need to be run on all platforms.

And of course we should all more or less agree that we want to do that.
I think it has been a mistake that we haven't been able to support
long file sizes in a consistent way throughout our code. Of course this
problem will vanish in some years when everybody is using 64 bit platforms.
But for embedded programming for example 32 bit processors may remain
useful and in use much longer.

I'm not sure if we should support assignability between INTEGER and
LONGINT, as Rodney's original proposal did. Probably yes, but I must
admit that I've been too little engaged in language theory for years now
so that I cannot really oversee the impacts.

Files with sizes larger than 4 GB get more and more common. Just think
of DVD images for example. And I don't think that it will be really
appreciated by users of M3 applications that they immediately crash
just because one has opened a directory browser based on the distributed
libraries :-)

Just my opinion of course. I don't really understand why you are so
drastically opposing LONGINT suddenly. Probably I haven't been able to
follow some of the arguments.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan  8 12:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 11:13:58 +0000
Subject: [M3devel] latest longint file size diffs
Message-ID: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>


Attached is my latest work here.
With the compiler changes (in the diff), I was able to
elminate most uses of VAL(expr, LONGINT).
There's something slightly off such that I had
to add a very small number, like two.

 

 

The compiler change is newer than earlier.

For example you can now assign CARDINAL to LONGINT.

I didn't do it, but you should also be able to add/subtract/etc.

mixing CARDINAL and LONGINT.

 


FOR statements also don't allow the level of mixing
that they should.


 

I'm hoping to get agreement soon just from the diffs

but if necessary I'll look how to create a branch.

My general worry about branches is developers just

go off on their own in a branch and it's impossible to

get anyone to look at it, they are busy enough with one branch,

let alone multiple..

 


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif8.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment-0001.txt>

From wagner at elegosoft.com  Fri Jan  8 12:32:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 12:32:24 +0100
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <20100108123224.rryfffs1kw40k4sk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>
> The compiler change is newer than earlier.
>
> For example you can now assign CARDINAL to LONGINT.
>
> I didn't do it, but you should also be able to add/subtract/etc.
>
> mixing CARDINAL and LONGINT.
>
> FOR statements also don't allow the level of mixing
> that they should.
>
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
>
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..

I think in this case it makes sense, as we need to run full regression
tests on all target platforms IMO.

You just should mark the start of the branch with

   cvs tag branch_feature_longint_offset_start

then create the branch tag itself

   cvs tag -b branch_feature_longint_offset

update your workspace to that branch

   cvs up -r branch_feature_longint_offset

and finally commit the changes

   cvs commit

This all assumes you've started on a fairly recent trunk and
there are no conflicts.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Fri Jan  8 15:28:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 09:28:11 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <20100108142811.GA14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:44:53AM +0000, Jay K wrote:
> 
> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
> 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

No, it was correct.

    MIN( 5, -1000000000000000L) = -1000000000000000L
    So the result really needs to be LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:08:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:08:20 -0500
Subject: [M3devel] longint..revisited?
In-Reply-To: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
References: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
Message-ID: <49C29A52-F861-4875-A6B0-B77758F08781@cs.purdue.edu>

Again, this proposal raises serious problems regarding implicit coercions, against the design principals of the Modula-3 type system.

On 7 Jan 2010, at 22:35, Jay K wrote:

> I can't find Rodney's proposal but I think I understand
> a lot of it from today's mail.
> 
> 
> Can we revisit this?
> 
> 
> My understanding is that Rodney's proposal
> deems INTEGER assignable to LONGINT,
> and vice versa, and that assignments of LONGINT
> to INTEGER undergo runtime range checks,
> can raise exceptions.
> 
> 
> I assume it also follows that:
> 
> 
> LONGINT can be added/subtracted/modded to INTEGER,
> yielding LONGINT.
> 
> 
> INTEGER MOD LONGINT would range check the LONGINT.
> 
> 
> INC/DEC(LONGINT, INTEGER) would just work
> 
> 
> INC/DEC(INTEGER, LONGINT) would range check.
> 
> 
> The downside is that the chance for failure would be
> silently injected into various places.
> 
> 
> Another proposal would be that INTEGER is assignable to LONGINT,
> but not vice versa. I really don't see why not.
> 
> 
>    LONGINT := INTEGER  
>    LONGINT + INTEGER => LONGINT  
>    LONGINT - INTEGER => LONGINT  
>    LONGINT * INTEGER => LONGINT  
>    LONGINT / INTEGER => LONGINT  
>    LONGINT MOD INTEGER => INTEGER (think about it) 
>    INC(LONGINT, INTEGER)
>    DEC(LONGINT, INTEGER)
> 
> 
> all seem very reasonable.
> 
> 
>  - Jay
> 



From hosking at cs.purdue.edu  Fri Jan  8 17:17:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:17:07 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <D75FD9A8-3049-4942-95BD-B9DE79920AFA@cs.purdue.edu>

On 7 Jan 2010, at 23:03, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>> 
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?

A subrange always has a known base type.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?

Correct.  Here is the subtype rule for ordinals:

For ordinal types T and U, we have T <: U if they have the same base type and every member of T is a member of U. That is, subtyping on ordinal types reflects the subset relation on the value sets.

Currently, we have two possible base types for ordinals: INTEGER and LONGINT.  They are distinct, unrelated types.

>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>> 
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

It conveys specific information about what specific machine values and operations implement them.  They can (and usually do) require different code to operate on them.  From a programmer's perspective, I know that every operation on INTEGER base values will involve *natural* integer arithmetic.  For LONGINT I am much less sure, and may require even calling a library to perform the operation (if the machine doesn't naturally support LONGINT).

> 
> -- hendrik
>> 
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>> 
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>> 
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>> 
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>> 
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>> 
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>> 
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>> 
>>> -- hendrik
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/77e170c0/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 17:26:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:26:07 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>

On 7 Jan 2010, at 20:35, Rodney M. Bates wrote:

> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time.  That would have been October
> of 2007.  I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type.

LONGINT *is* an ordinal type.  It just has a different base type than INTEGER so it is not subtype-related.

> This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other.  This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.

The question really is what should the top type be?

We don't want to have all ordinal types base themselves on LONGINT because then they will all incur LONGINT operations (which may be more expensive than the "natural" INTEGER operations).

> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types.  Most places in the
> language require only assignability, not type equality.  Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.

I really don't see how to accomodate this within the Modula-3 type system and its existing rules.

Now, we could introduce an explicit rule that says INTEGER <: LONGINT.  Then we can freely assign INTEGER values to LONGINT values.

> A consequence of existing rules is that there would be, if necessary,
> runtime value checks.  In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.

Allowing assignment of LONGINT to INTEGER requires an implicit range check on assignment, but perhaps that is OK.

> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer.  A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT.  But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.

In this case I prefer the need for explicit conversion just so that programmers are made aware.

> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable.  This could, of course be fixed in the language,
> but I would prefer making the two types assignable.

No, there is no contradiction in the current implementation.  It treats subranges of LONGINT as having base type LONGINT.   So they are unrelated to INTEGER based types.

> 
> 
> 
> 
> Jay K wrote:
>> 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



From hosking at cs.purdue.edu  Fri Jan  8 17:27:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:27:36 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
	<4B468C63.9050404@lcwb.coop>
Message-ID: <F1B2BC0B-A862-4361-8E39-88D6B0061444@cs.purdue.edu>

Agreed.

On 7 Jan 2010, at 20:37, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> On 7 Jan 2010, at 06:22, Jay K wrote:
>>> 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.
>> Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.
> Indeed, Modula-3 has no implicit casts at all.  But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability.  A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too).  If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0de78432/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 17:29:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:29:33 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <303FF080-4129-4669-B264-151C32DE559F@cs.purdue.edu>

On 7 Jan 2010, at 22:53, hendrik at topoi.pooq.com wrote:

> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?

We do have + defined on LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:36:18 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>

I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?

Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).

On 8 Jan 2010, at 05:44, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>> 
>>> Well, I don't think that should be any practical problem right now,
>> 
>>> shouldn't it? But 32 bit offsets have been overcome for years even
>>> on 32 bit systems, so I definitely think we should keep the LONGINT
>>> type and even try to incompatibly change the internal file length
>>> type (with due care and consideration of course).
>> 
>> I think I am now persuaded LONGINT should stay.  But, I don't  understand what "incompatibly change the internal file length
>> type (with due care and consideration of course)" means?
> 
> I only just got round to reading all those mails.
> 
> I meant changing the file lengths and offsets in all our libraries,
> like Rd/Wr. Basically what Jay has started on right away ;-)
> 
> I agree that this should be done in a feature branch though.
> Changes should be reviewed.
> Regression tests need to be run on all platforms.
> 
> And of course we should all more or less agree that we want to do that.
> I think it has been a mistake that we haven't been able to support
> long file sizes in a consistent way throughout our code. Of course this
> problem will vanish in some years when everybody is using 64 bit platforms.
> But for embedded programming for example 32 bit processors may remain
> useful and in use much longer.
> 
> I'm not sure if we should support assignability between INTEGER and
> LONGINT, as Rodney's original proposal did. Probably yes, but I must
> admit that I've been too little engaged in language theory for years now
> so that I cannot really oversee the impacts.
> 
> Files with sizes larger than 4 GB get more and more common. Just think
> of DVD images for example. And I don't think that it will be really
> appreciated by users of M3 applications that they immediately crash
> just because one has opened a directory browser based on the distributed
> libraries :-)
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Fri Jan  8 18:00:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 12:00:01 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	? T <: U, or
	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	? T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 17:49:06 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:49:06 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <4B476202.7010004@lcwb.coop>



Jay K wrote:
> I don't believe currently "10" is assignable
> (or comparable) to LONGINT.
> You have to use 10L.

This is a bit subtle, and I should have been more explicit.  I didn't
mean the Modula-3 expression "10", I meant just the value ten.

 From 2.2:
------------------------------------------------------------------------------
Every expression has a unique type, but a value can be a member of many types.
For example, the value 6 is a member of both [0..9] and
INTEGER.  It would be ambiguous to talk about ``the type of a value''.
Thus the phrase ``type of x'' means ``type of the expression
x'', while ``x is a member of T'' means ``the value of
x is a member of T''.
------------------------------------------------------------------------------

The snippets of Modula-3 _code_ "10" and "10L"  are expressions.  Each has
both a value (which is the same) and a type (which is different).  The value
10 is a member of both types.

The 2.2 quote was written before we had LONGINT and its literals, so referring to
the value 6 wasn't as unclear.  Maybe it would be better to say that the
value 10 when stored in an INTEGER is a different abstract value than
10 stored in a LONGINT.  Then the two types would have disjoint value
sets.  But I think that would be a serious contradiction to the way
subranges work.

>  
>  
> I do believe any INTEGER or CARDINAL expression should be assignable
> to LONGINT, but I don't think it is implemented that way currently.
>  
>  
> And, then, I wonder if subranges are all we need, no LONGINT.
> But I don't understand the language well enough.
>  
>  
>  - Jay
> 


From rodney_bates at lcwb.coop  Fri Jan  8 17:53:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:53:42 -0600
Subject: [M3devel] LONGINT, my original proposal
Message-ID: <4B476316.4000005@lcwb.coop>

Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 64-bitProposal
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment-0001.ksh>

From rodney_bates at lcwb.coop  Fri Jan  8 18:10:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:10:28 -0600
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <4B476704.8010403@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>>
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?
> 

No, this is not implicit.  An implementation can (and probably should)
store a variable of a subrange type in a byte or two, if sufficient to
hold the range.  When the programmer assigns this to an INTEGER, the
compiler will have to make a representation change.  But is has the
necessary information to do this without huge trouble.

Similarly, the implementation _must_ store a subrange in a restricted
size field when it is a field or array element having a BITS type
derived from a subrange type.

What's unique about Modula-3 is that such representation changes are
left to the compiler, while the language merely views values as
sometimes belonging to more than one type, and allows such values to be
assigned when so.  The usual approach in other languages is to elevate
the representation change from a machine-level matter to a language-
level matter by treating it as an implicit type change in addition to
a representation change.  The result is always a lot of unnecessary
complexity in the language.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?
> 
>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>>
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

One thing that is very much needed in a language (not the only thing)
is a type that always matches the implementation's native arithmetic
size, which is most efficient.  If you don't distinguish this type,
it becomes either impossible or horribly convoluted to define arithmetic
so native machine arithmetic can be usually used where possible,
but multi-word arithmetic will be used where needed.

> 
> -- hendrik
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>>
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>>
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>>
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>>
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>>
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>>
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>>
>>> -- hendrik
> 


From mika at async.async.caltech.edu  Fri Jan  8 18:34:12 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 09:34:12 -0800
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu> 
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <20100108173412.8531F1A207A@async.async.caltech.edu>

Tony Hosking writes:
...
>A type T is assignable to a type U if:
>
>	=95 T <: U, or
>	=95 U <: T and T is an array or a reference type other than =
>ADDRESS (This restriction is lifted in unsafe modules.), or
>	=95 T and U are ordinal types with at least one member in =
>common.
>
>This suggests that we don't really need to say that INTEGER <: LONGINT.
>
>We can simply rely on the third clause regarding their both being =
>ordinal types with at least one member in common.  Then assignment =
>simply needs to test that the values are in range.
>

Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
the same "member"?

By a similar argument, you could make REAL and LONGREAL assignable.
Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
the same bit patterns, same as 0 and 0L for that matter, and I can add
that the way you do single-precision floating point on Alpha is by zeroing
a big chunk in the middle of your double-precision fp registers...)

I think I am with you on removing LONGINT from the language.  The proper
way of handling file sizes (or anything else that might be a bigger number
than a machine word) is through abstraction.  I have a suspicion that it's
probably a severe micro-optimization to worry about the efficiency of
operations on file sizes.  The thought that someone is adding automatic
type conversion to Modula-3, a la C, makes me feel slightly sick to
my stomach...

I confess that my position is influenced by the fact that I have written
many programs that generate Modula-3 code as an "intermediate language".
I really really really need M3 to be easy to understand to get this to
work well.  Also being able to parse interfaces and know precisely what
they mean is important to me.  If the rules start getting sloppy.. that
would really upset me.  On the other hand this means that if I'm faced
with a problem that doesn't really fit into M3 well, say, working in
arithmetic mod 2^(wordsize), my first instinct is not to demand changes
to the language definition but to write a code generator that takes
appropriate infix (or maybe more likely prefix) code and turns it into
the appropriate calls through the Word interface.  It's a pain, yes, 
but in the long run that's the right way, because you can do so much
more with that approach than just unsigned integers.

    Mika


From rcolebur at SCIRES.COM  Fri Jan  8 18:36:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 12:36:50 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA67@ATLEX02-SRV.SCIRES.LOCAL>

I agree with Tony that we need a clean proposal to debate.  I also agree with keeping the spirit of the Modula-3 language and type rules.

Randy Coleburn

-----Original Message-----
From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Friday, January 08, 2010 12:00 PM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] mixing INTEGER and LONGINT?

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	* T <: U, or
	* U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	* T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 18:33:52 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:33:52 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <4B476C80.4090601@lcwb.coop>



Jay K wrote:
> This simple diff in the front end allows the "obvious" mixing of INTEGER 
> and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT
>   LONGINT - INTEGER => LONGINT
>   LONGINT * INTEGER => LONGINT
>   LONGINT DIV INTEGER => LONGINT
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should 
> be INTEGER)
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct) 
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct) 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be 
> INTEGER) 
>   MAX(INTEGER, LONGINT) => LONGINT 
>   LONGINT := INTEGER

Making INTEGER and LONGINT mutually assignable (or even one-way
assignability of INTEGER to LONGINT) implies all of the above.
The arithmetic operators are defined as generalizations of Modula-3
procedures, with parameters of VALUE mode.  And the rule for VALUE
requires only that the actual be assignable to the formal, not
have identical type.  This is what I originally proposed.

Actually, with LONGINT in the picture, the arithmetic operators have
to be defined more carefully, in order to avoid or remove ambiguity in
resolution of builtin overloaded arithmetic operators. Particularly,
we have to eliminate the possibility that, e.g., an expression of the form
INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
operator, by assignability of INTEGER to LONGINT.  This would completely
the efficiency of native machine arithmetic.

Whatever we do, I feel very strongly that we should preserve consistency
with both the existing rules that assignment statements and passing
VALUE parameters require assignability.  That means that explicitly coded
VAL/ORD functions will be required either in both assignments and mixed
arithmetic, or neither.  The same applies to a number of other places
that require assignability.


>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 


From hosking at cs.purdue.edu  Fri Jan  8 19:00:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:00:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:

> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.

We have this.

> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.

>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.

> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.

We have this right now.

>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!

>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.

The current implementation illustrates that this is not a problem.

> 4. LONGINT # INTEGER.

We have this right now.

>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.

Agreed.

> 5. LONGINT is an ordinal type. 

We have this right now.

>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.

> 6. Neither LONGINT nor INTEGER is a subtype of the other.  

We have this right now.

>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.

Agreed.

> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.

We have this.

> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.

>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.

Agreed.

>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.

>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.

OK.  I think I see how to implement this...

> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.

> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.

We already support this.

> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.

Already supported.

> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.

>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.

> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.	

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.

> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.

This is the current implementation.

>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  

Agreed.

>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.

This is the current implementation.

>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.

Agreed.

> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).

> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation. 

> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.

Agreed.

> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.

>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).

> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range. 

This is the current implementation.

> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.

This is the current implementation.

> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here. 

This is the current implementation.

> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.

This is the current implementation.

> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.

>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.

Until we see the need I hesitate to implement it.

>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.

Agreed.

> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.

I just added these.

>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0c578d06/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 19:08:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:08:46 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <3BB40DAB-60F8-461E-A9C8-FF80A81F74A8@cs.purdue.edu>

On 8 Jan 2010, at 12:34, Mika Nystrom wrote:

> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>> 
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>> 
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>> 
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>> 
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?

Yes, we could potentially do that.  It is straightforward because their significant bits are the same.

> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)

Not so reasonable, because their bits are different and need explicit conversion.

> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree with those sentiments.  While LONGINT can be accomodated (and more elegantly if we evolve towards Rodney's proposal -- see my other e-mail) I am still not convinced that it is worth all the complications.  If LONGINT is there only for large file sizes then abstraction is a *much* better way to go.  Why add a general-purpose type for a one-off use-case?

> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.

Agreed.

From hosking at cs.purdue.edu  Fri Jan  8 19:19:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:19:58 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B476C80.4090601@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<4B476C80.4090601@lcwb.coop>
Message-ID: <18553308-F36F-44B9-857F-E53B859B02C0@cs.purdue.edu>

To summarise the discussion so far...

1. Do we really need LONGINT?  Some have expressed a desire for it.  The only use-case so far is large file sizes.

2. If we do need LONGINT then Rodney's proposal seems sound apart from the question of resolution of the builtin overloaded arithmetic operators.  Rodney's proposal is that they resolve to the maximal type of their operands.  Jay, I am very concerned about your definitions for MOD/DIV below because I think they are inherently unintuitive (witness your own claims of "subtlety" -- Modula-3 should not ever have subtle semantics!).  I forget what the rules for C happen to be... (with good reason since I've never wanted to try to remember them and avoid mixed type operands like the plague!).  So, do I hear strong arguments for or against mixed type integer operands?

On 8 Jan 2010, at 12:33, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>   LONGINT + INTEGER => LONGINT
>>  LONGINT - INTEGER => LONGINT
>>  LONGINT * INTEGER => LONGINT
>>  LONGINT DIV INTEGER => LONGINT
>>  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)
>>  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)   MAX(INTEGER, LONGINT) => LONGINT   LONGINT := INTEGER
> 
> Making INTEGER and LONGINT mutually assignable (or even one-way
> assignability of INTEGER to LONGINT) implies all of the above.
> The arithmetic operators are defined as generalizations of Modula-3
> procedures, with parameters of VALUE mode.  And the rule for VALUE
> requires only that the actual be assignable to the formal, not
> have identical type.  This is what I originally proposed.
> 
> Actually, with LONGINT in the picture, the arithmetic operators have
> to be defined more carefully, in order to avoid or remove ambiguity in
> resolution of builtin overloaded arithmetic operators. Particularly,
> we have to eliminate the possibility that, e.g., an expression of the form
> INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
> operator, by assignability of INTEGER to LONGINT.  This would completely
> the efficiency of native machine arithmetic.
> 
> Whatever we do, I feel very strongly that we should preserve consistency
> with both the existing rules that assignment statements and passing
> VALUE parameters require assignability.  That means that explicitly coded
> VAL/ORD functions will be required either in both assignments and mixed
> arithmetic, or neither.  The same applies to a number of other places
> that require assignability.
> 
> 
>> Other mixes are less obvious and would require runtime checks.
>> I think the backend will just work but I haven't tried that yet.
>> (Truth be told, I can only affectively edit files on NT...)
>> Thoughts?
>>  - Jay
>> Index: builtinOps/Dec.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
>> retrieving revision 1.9
>> diff -u -r1.9 Dec.m3
>> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
>> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
>> @@ -44,7 +44,7 @@
>>     IF (NUMBER (ce.args^) > 1) THEN
>>       IF Type.IsSubtype (t, LInt.T) THEN
>>         t := Type.Base (Expr.TypeOf (ce.args[1]));
>> -        IF (t # LInt.T) THEN
>> +        IF t # LInt.T AND t # Int.T THEN
>>           Error.Txt (name, "second argument must be a LONGINT");
>>         END;
>>       ELSE
>> Index: builtinOps/Max.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 Max.m3
>> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
>> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
>> @@ -25,11 +25,14 @@
>>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     ta := Type.Base (Expr.TypeOf (ce.args[0]));
>>     tb := Type.Base (Expr.TypeOf (ce.args[1]));
>> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
>> +      resultType := LInt.T;
>> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>>       Error.Txt (name, "incompatible argument types");
>>     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>>       (* ok *)
>> @@ -39,7 +42,11 @@
>>       Error.Txt (name, "wrong argument types");
>>       ta := Int.T;
>>     END;
>> -    ce.type := ta;
>> +    IF resultType # NIL THEN
>> +      ce.type := resultType;
>> +    ELSE
>> +      ce.type := ta;
>> +    END;
>>   END DoCheck;
>>  PROCEDURE Compile (ce: CallExpr.T) =
>> Index: exprs/AddExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 AddExpr.m3
>> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
>> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -67,6 +67,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -74,8 +75,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
>> -      p.class := Class.cLINT
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -96,7 +98,11 @@
>>     ELSE
>>       ta := Expr.BadOperands ("\'+\'", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/DivExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 DivExpr.m3
>> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,7 +60,7 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF (ta = Int.T) AND (tb = Int.T) THEN
>>       p.type := Int.T;
>> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.type := LInt.T;
>>     ELSE
>>       p.type := Expr.BadOperands ("DIV", ta, tb);
>> Index: exprs/ModExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 ModExpr.m3
>> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,6 +60,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -67,8 +68,18 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> +
>>     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>>       p.class := Class.cLINT;
>> +
>> +    (* The result of MOD cannot be higher than either of its inputs.
>> +     * small divided by big is 0 remainder small
>> +     * big divided by small has a remainder of at most small
>> +     *)
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cINT;
>> +      resultType := Int.T;
>> +
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -78,7 +89,11 @@
>>     ELSE p.class := Class.cERR;  ta := Int.T;
>>       ta := Expr.BadOperands ("MOD", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/MultiplyExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 MultiplyExpr.m3
>> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
>> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -66,6 +66,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -73,8 +74,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>>       p.class := cINT;
>> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>>       p.class := cREAL;
>>     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
>> @@ -90,7 +92,11 @@
>>       ta := Expr.BadOperands ("\'*\'", ta, tb);
>>       p.class := cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/SubtractExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
>> retrieving revision 1.4
>> diff -u -r1.4 SubtractExpr.m3
>> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
>> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -73,6 +73,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -80,8 +81,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -113,7 +115,11 @@
>>       ta := Expr.BadOperands ("\'-\'", ta, tb);
>>       p.class := Class.cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: types/Type.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
>> retrieving revision 1.8
>> diff -u -r1.8 Type.m3
>> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
>> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
>> @@ -543,6 +543,10 @@
>>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>>       RETURN TRUE;
>>     ELSIF IsOrdinal (a) THEN
>> +      (* INTEGER is assignable to LONGINT *)
>> +      IF a = LInt.T AND b = Int.T THEN
>> +        RETURN TRUE;
>> +      END;
>>       (* ordinal types:  OK if there is a common supertype
>>          and they have at least one member in common. *)
>>       IF IsEqual (Base(a), Base(b), NIL)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/c8b64398/attachment-0001.html>

From rcolebur at SCIRES.COM  Fri Jan  8 19:20:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 13:20:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>

Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in "cm3/doc" and the language posters in "cm3/doc/src_reports".

Randy Coleburn


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Friday, January 08, 2010 1:01 PM
To: Rodney M. Bates
Cc: m3devel
Subject: Re: [M3devel] LONGINT, my original proposal

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:


Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
A proposal for Modula-3 language changes to support an integer type
larger than the native size of the target processor.

This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.

Actual statements about the language are numbered.  Comments are
indented more deeply, following a numbered item they apply to.  Some
numbered items are labeled "NO CHANGE", and merely call attention to
the lack of a change, where it is relevant or calls for comment.

Changes to the language proper:

1. There is a new builtin type named LONGINT.

We have this.


2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


     The intent is that INTEGER will remain as the native integer
     size on the implemented processor.  LONGINT might be bigger, but
     not necessarily.  Typically, on a 32-bit processor, LONGINT
     would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.


3. There are new literals of type LONGINT, denoted by following a
   nonempty sequence of digits by either 'l' or 'L'.

We have this right now.


     Having distinctly spelled literals preserves Modula-3's clean
     system of referentially transparent typing, i.e, the type of
     every expression is determined by the expression alone, without
     regard to how it is used.  The 3 floating point types already
     follow this principle.  Literals of ambiguous type, combined
     with a system of implicit conversions taken from the context
     would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!


     I believe intuitively that Id, LOCK, and LOOP are not members of
     FOLLOW(Number), but need to check this mechanically.  It would
     mean that the new literals can not undermine any existing,
     compilable code.

The current implementation illustrates that this is not a problem.


4. LONGINT # INTEGER.

We have this right now.


     This is true regardless of whether their ranges are equal.  This
     keeps the typing independent of the implementation.  Doing
     otherwise could be a portability nightmare.

Agreed.


5. LONGINT is an ordinal type.

We have this right now.


     This means the existing rules of assignability will allow
     assignment between LONGINT and its subtypes and INTEGER and its
     subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.


6. Neither LONGINT nor INTEGER is a subtype of the other.

We have this right now.


     This is true regardless of whether their ranges are equal, in
     part for the same reason the types are unequal.

     Note that, for ordinal types, assignability doesn't actually use
     the subtype relation.  In fact, the one place I can find in the
     present language where subtypes matter for ordinal types is in
     the definition of signatures of operators, etc.  In 2.6.1,
     paragraph 5, operands must have a subtype of the type specified.
     Keeping LONGINT and INTEGER subtype-unrelated keeps this
     statement unambiguous and allows easy specification of the
     operators.

Agreed.


7. Prefix operators +, -, and ABS can take an operand having a
   subtype of LONGINT, in which case, their result has type LONGINT.

We have this.


8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.
   If either is a subtype of LONGINT, the result has type LONGINT,
   otherwise INTEGER.  The result is correct (i.e., no overflow
   occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.


     With assignment between different subranges, Modula-3 takes the
     view that this is not an implied type conversion at all.
     Instead, the rules have the effect that if the value is a member
     of the LHS type, then it's OK.  I think this is a brilliant
     piece of language design.  Compare to the many pages of
     description that C++ and Java require to define implied type
     conversions in assignments, and they only have a few
     integer-like types, whereas current Modula-3 has, typically,
     ~2^31 subrange types involved.  It's also less
     implementation-oriented, because it doesn't appeal to bit
     representations, etc.

Agreed.


     I resisted allowing mixed sizes of operands, until I realized we
     can do the same thing with operators as with assignment, i.e.,
     just require result values to be in range, without calling
     anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.


     A compiler can implement this by just doing the arithmetic in
     the same size as the result type.  This means if both operands
     are subtypes of INTEGER, (which will always be the case with
     existing code,) then the native arithmetic will be used, without
     loss of efficiency.

OK.  I think I see how to implement this...


9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.

     Again, a compiler can figure out how to generate code for this,
     with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.


10. The first parameter to FLOAT can have a subtype of either INTEGER
   or LONGINT.

We already support this.


11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
   parameter, which can be either LONGINT or INTEGER, and which
   specifies the result type of the operation.  If omitted, it
   defaults to INTEGER.  The result has this type.

     The default preserves existing code.

Already supported.


12. The result type of ORD is LONGINT if the parameter is a subtype of
   LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.


     There is really not much programmer value in applying ORD to a
     subtype of either INTEGER or LONGINT, since this is just an
     identity on the value.  It would provide an explicit, widening
     type conversion, and NARROW won't accomplish this, because it is
     only defined on reference types.  However, this rule provides
     consistency, and maybe would simplify some machine-generated
     source code scheme.

     This fails to support an implementation's effort to expand the
     number of values of an enumeration type beyond the current
     implied limitation of the positive native word values.  How
     tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.


13. The first parameter to VAL can be a subtype of either INTEGER or
   LONGINT.

     Beside generalizing the existing uses of VAL, this also allows
     explicit conversions between LONGINT and INTEGER, if there is
     any need for them.

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.


14. (NO CHANGE) The safe definitions of INC and DEC do not change.

     As a consequence of the changes to +, -, ORD, and VAL, the
     existing equivalent WITH-statement definition will generalize to
     mixes of any ordinal type for the first parameter and a subtype
     of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?


16. Neither LONGINT, nor any subtype thereof, can be used as the index
   type of an array type.

This is the current implementation.


     One could think about allowing this, but it would require a lot
     of other things to be generalized, and is unlikely to be of much
     use.

Agreed.


     After the world's having had to learn twice the hard way, what a
     mess that comes from addresses that are larger than the native
     arithmetic size, we are unlikely to see it again.  So, the only
     ways a longer LONGINT index type could be of any use are: 1)
     arrays of elements no bigger than a byte, that occupy more than
     half the entire addressable memory, and you want to avoid
     negative index values, or 2) arrays of packed elements less than
     byte size that occupy at least one eighth of the memory (or some
     mixture thereof).  All these cases also can occur only when
     using close to the maximum addressable virtual memory.  Not very
     likely.

     If you really need 64-bit array subscripts, you will have to use
     an implementation whose native size is 64 bits.

     This also avoids generalizing SUBARRAY, several procedures in
     required interface TEXT, more extensive generalization of
     NUMBER, etc.

17. Neither LONGINT, nor any subtype thereof, can be used as the base
   type of a set type.

This is the current implementation.


     This is similar to the array index limitation.  Sets on base
     types of long range are very unlikely, as they would be too bit.
     The assignability rules should make subranges of INTEGER
     relatively easy to use as set base types instead of short
     subranges of LONGINT.  This also obviates generalizing IN.

Agreed.


18. The result type of NUMBER is LONGCARD if its parameter is a
   subtype of LONGINT, otherwise INTEGER, as currently.

     NUMBER has always had the messy problem that its correct value
     can lie beyond the upper limit of its result type CARDINAL.
     Fortunately, it is rare to use it in cases where this happens.
     The expanded definition still has the equivalent problem, but it
     seems even less likely to actually happen.

     One could consider making NUMBER always return a LONGCARD, which
     would fix the problem for parameters that are INTEGER, but that
     would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).


19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation.


     If you really need 64-bit sizes or typecodes, you will have to
     use an implementation whose native size is 64 bits.

Agreed.


20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.


     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


Changes to required (AKA standard) interfaces:

21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
   Word.Rotate, and the CARDINAL parameters of Word.Extract and
   Word.Insert are unchanged.

     These are bit numbers.  There is no need for a longer range.

This is the current implementation.


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?


     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.

This is the current implementation.


23. (NO CHANGE) The Base and Precision values in required interfaces
   Real, LongReal, and Extended, keep the type INTEGER.

      There is no need for increased value range here.

This is the current implementation.


24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
    and Float.ILogb, whose result type is INTEGER, do not have LONGINT
    counterparts.

      It is difficult to imagine these values needing greater range.

This is the current implementation.


25. Fmt has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


26. Lex has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


27. There is a new required interface named LongAddress.  It is UNSAFE
   and contains procedures that are equivalents for the 5 unsafe
   ADDRESS arithmetic operations, with LONGINT substituted in place
   of INTEGER in their signatures.  These are given in 2.7 and
   include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.


     It is remotely conceivable that there could be a target whose
     native address size is longer than its native integer size
     (unlike the reverse.)  In such a case, these operations might be
     needed.

Until we see the need I hesitate to implement it.


     Four of them could be accommodated by just generalizing the
     INTEGER parameter to allow either INTEGER or LONGINT.  The
     remaining operator subtracts two ADDRESS operands and returns an
     INTEGER.  This can't be generalized using Modula-3's existing
     pattern of overload resolution of builtin operations.
     Redefining it to always do LONGINT arithmetic would violate the
     existing efficiency criterion.  Two separate operations are
     needed.

     This solution avoids complexity in the language proper, while
     still accommodating a rare requirement.  It could probably be
     left unimplemented unless/until such a target actually happens.

Agreed.


Changes to useful interfaces:

28. IO has new procedures PutLongInt and GetLongInt, parallel to
   PutInt and GetInt.

I just added these.


     I have not looked systematically at all the useful interfaces
     for other places that use CARDINAL and INTEGER and might need to
     be generalized.  (Can anyone point to a tool that will grep
     files in .ps or .pdf format, or something equivalent?)

     Note that changes in nonrequired interfaces should be
     implementable just by writing new/modified library code, without
     additional help from the compiler.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/e40711ea/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 19:25:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:25:10 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <4020F84F-CF80-4C0B-8586-FD7D7AD8F052@cs.purdue.edu>

I've already made changes to cm3/doc/reference that match the current implementation (no implicit assignability).  I'm happy to adjust that to match what we eventually implement.

On 8 Jan 2010, at 13:20, Randy Coleburn wrote:

> Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in ?cm3/doc? and the language posters in ?cm3/doc/src_reports?.
>  
> Randy Coleburn
> 
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Friday, January 08, 2010 1:01 PM
> To: Rodney M. Bates
> Cc: m3devel
> Subject: Re: [M3devel] LONGINT, my original proposal
>  
> We already have much of this, but not all.  Notes below...
>  
> I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.
>  
> I am looking into making the changes to the current implementation that will bring this into being.
>  
> On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:
> 
> 
> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.
>  
> We have this.
> 
> 
> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>  
> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.
>  
> This is what we currently have.
> 
> 
> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.
>  
> We have this right now.
> 
> 
>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).
>  
> I wholeheartedly agree!
> 
> 
>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.
>  
> The current implementation illustrates that this is not a problem.
> 
> 
> 4. LONGINT # INTEGER.
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.
>  
> Agreed.
> 
> 
> 5. LONGINT is an ordinal type.
>  
> We have this right now.
> 
> 
>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.
>  
> I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.
> 
> 
> 6. Neither LONGINT nor INTEGER is a subtype of the other.  
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.
>  
> Agreed.
> 
> 
> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.
>  
> We have this.
> 
> 
> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.
>  
> I am uneasy about mixing parameter types in this way.
> I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.
> 
> 
>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.
>  
> Agreed.
> 
> 
>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.
>  
> This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.
> 
> 
>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.
>  
> OK.  I think I see how to implement this...
> 
> 
> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.
>  
> Same as above.  I think it can be implemented.
> 
> 
> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.
>  
> We already support this.
> 
> 
> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.
>  
> Already supported.
> 
> 
> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.
>  
> The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
> If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.
> 
> 
>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.
>  
> I see no problem with the maximum enumeration type values being restricted to natural integers.
> 
> 
> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.
>  
> The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
> Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.
> 
> 
> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.
>  
> [Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
> The current implementation does not allow mixing INTEGER/LONGINT operand and increments.
>  
> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.
>  
> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> 
> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.
>  
> This is the current implementation.
> 
> 
>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  
>  
> Agreed.
> 
> 
>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.
>  
> This is the current implementation.
> 
> 
>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.
>  
> Agreed.
> 
> 
> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.
>  
> The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).
> 
> 
> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.
>  
> This is the current implementation. 
>  
> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.
>  
> Agreed.
> 
> 
> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).
>  
> Agreed.
> 
> 
>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.
>  
> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
> 
> 
> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range.
>  
> This is the current implementation.
> 
> 
> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.
>  
> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> 
>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.
>  
> This is the current implementation.
> 
> 
> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here.
>  
> This is the current implementation.
> 
> 
> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.
>  
> This is the current implementation.
> 
> 
> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.
>  
> We currently do not support this.
> 
> 
>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.
>  
> Until we see the need I hesitate to implement it.
> 
> 
>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.
>  
> Agreed.
> 
> 
> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.
>  
> I just added these.
> 
> 
>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/849cd8b9/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri Jan  8 19:34:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:34:17 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <20100108183416.GC14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:53:42AM -0600, Rodney M. Bates wrote:
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>     type of a set type.
> 
>       This is similar to the array index limitation.  Sets on base
>       types of long range are very unlikely, as they would be too bit.

"too big", not "too bit"

>       The assignability rules should make subranges of INTEGER
>       relatively easy to use as set base types instead of short
>       subranges of LONGINT.  This also obviates generalizing IN.
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>     and contains procedures that are equivalents for the 5 unsafe
>     ADDRESS arithmetic operations, with LONGINT substituted in place
>     of INTEGER in their signatures.  These are given in 2.7 and
>     include a +, two overloaded meanings of -, an INC, and a DEC.
> 
>       It is remotely conceivable that there could be a target whose
>       native address size is longer than its native integer size
>       (unlike the reverse.)  In such a case, these operations might be
>       needed.

The IBM 360 had three-byte addresses, but a four-byte integer.
However, they had to be four-byte aligned, and were usually handled 
using four-byte operations.  However, OS code (in assembler) often 
stuffer various non-address flags in the extra byte, so except for 
its massive obsolescence, this would be a real consideration.  The IBM 
370 had special instructions for loading and storing the three address 
bytes of a machine word, making this a little cleaner.  I'm told a later 
version of this architecture switched to four-byte addresses, causing a 
very expensive rewrite of a huge amount of code.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 19:54:53 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:54:53 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <20100108185453.GD14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.

I could understand opposition to LONGINT if it were based on it being a 
kludge stuck in to quickly patch a problem while we spend time thinking 
about the real, elegant solution.  And having two types like INTEGER and 
LONGINT without one being a subrange of the other seems like a kludge to 
me, however necessary it also appears.

But let me ask a question.  Is there ever any need for a Modula 3 
compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
INTEGER is 32 bits?

(I might have asked "more than 12 bits" in the above question, but 
modern 23-bit machines may very well have 16-bit operations but not 
12-bit operations.)

-- hendrik

P.S.  As far as I know, I don't think the C standard ever specifies that 
arithmetic operations on its file offset type (Is it offset_t?  I 
forget.) have any relation whatsoever to actual file position?  As far 
as I know, it could be a count of the number of bytes to read to reach 
that position, or it could consist of cylinder, track, and sector 
numbers, or it could even be encrypted.  Fie on the C implementor that 
does any of these things, though.


From hendrik at topoi.pooq.com  Fri Jan  8 19:58:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:58:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
Message-ID: <20100108185841.GE14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
> 
> The question really is what should the top type be?
> 
> We don't want to have all ordinal types base themselves on LONGINT 
> because then they will all incur LONGINT operations (which may be more 
> expensive than the "natural" INTEGER operations).

Is it even necessary for a compiler to implement -128..127 as more than 
one byte?

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 20:04:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 14:04:09 -0500
Subject: [M3devel] Integers
In-Reply-To: <4B476704.8010403@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
Message-ID: <20100108190409.GF14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> 
> What's unique about Modula-3 is that such representation changes are
> left to the compiler, while the language merely views values as
> sometimes belonging to more than one type, and allows such values to be
> assigned when so.  The usual approach in other languages is to elevate
> the representation change from a machine-level matter to a language-
> level matter by treating it as an implicit type change in addition to
> a representation change.  The result is always a lot of unnecessary
> complexity in the language.
...
...
> >
> >Where in the language is it important that INTEGER and LONGINT be 
> >different base types?  In other words, what advantages does this 
> >separation convey?
> 
> One thing that is very much needed in a language (not the only thing)
> is a type that always matches the implementation's native arithmetic
> size, which is most efficient.  If you don't distinguish this type,
> it becomes either impossible or horribly convoluted to define arithmetic
> so native machine arithmetic can be usually used where possible,
> but multi-word arithmetic will be used where needed.

Yes.  You do need this type.  And you can even call it INTEGER.  But is 
there any reason it cannot be a predefined subrange type of LONGINT?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 20:32:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:32:56 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <7743770A-2B7E-4AF7-8F6C-EC44041717AE@cs.purdue.edu>

On 8 Jan 2010, at 13:54, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
>> 
>> Just my opinion of course. I don't really understand why you are so
>> drastically opposing LONGINT suddenly. Probably I haven't been able to
>> follow some of the arguments.
> 
> I could understand opposition to LONGINT if it were based on it being a 
> kludge stuck in to quickly patch a problem while we spend time thinking 
> about the real, elegant solution.  And having two types like INTEGER and 
> LONGINT without one being a subrange of the other seems like a kludge to 
> me, however necessary it also appears.

It really is kind of a kludge invented just for large files.

> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

[0..1024] has memory representation of 16 bits.  What's the point of the question?  Values of [0..1024] are INTEGER and operations on them are INTEGER typed.

> (I might have asked "more than 12 bits" in the above question, but 
> modern 23-bit machines may very well have 16-bit operations but not 
> 12-bit operations.)
> 
> -- hendrik
> 
> P.S.  As far as I know, I don't think the C standard ever specifies that 
> arithmetic operations on its file offset type (Is it offset_t?  I 
> forget.) have any relation whatsoever to actual file position?  As far 
> as I know, it could be a count of the number of bytes to read to reach 
> that position, or it could consist of cylinder, track, and sector 
> numbers, or it could even be encrypted.  Fie on the C implementor that 
> does any of these things, though.

Right, so this argues in favor of a cleaner abstraction of file offsets rather than LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 20:33:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:33:54 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185841.GE14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
	<20100108185841.GE14151@topoi.pooq.com>
Message-ID: <C5865D4D-441B-4410-B5A0-CA2A3F746C20@cs.purdue.edu>

They are stored as 1-byte values.  But the values of that type are INTEGERs and operated on as INTEGERs.

On 8 Jan 2010, at 13:58, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
>> 
>> The question really is what should the top type be?
>> 
>> We don't want to have all ordinal types base themselves on LONGINT 
>> because then they will all incur LONGINT operations (which may be more 
>> expensive than the "natural" INTEGER operations).
> 
> Is it even necessary for a compiler to implement -128..127 as more than 
> one byte?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/6b40fee7/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 20:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:36:18 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108190409.GF14151@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
Message-ID: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>

On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> 
>> What's unique about Modula-3 is that such representation changes are
>> left to the compiler, while the language merely views values as
>> sometimes belonging to more than one type, and allows such values to be
>> assigned when so.  The usual approach in other languages is to elevate
>> the representation change from a machine-level matter to a language-
>> level matter by treating it as an implicit type change in addition to
>> a representation change.  The result is always a lot of unnecessary
>> complexity in the language.
> ...
> ...
>>> 
>>> Where in the language is it important that INTEGER and LONGINT be 
>>> different base types?  In other words, what advantages does this 
>>> separation convey?
>> 
>> One thing that is very much needed in a language (not the only thing)
>> is a type that always matches the implementation's native arithmetic
>> size, which is most efficient.  If you don't distinguish this type,
>> it becomes either impossible or horribly convoluted to define arithmetic
>> so native machine arithmetic can be usually used where possible,
>> but multi-word arithmetic will be used where needed.
> 
> Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> there any reason it cannot be a predefined subrange type of LONGINT?

I sense confusion here...

INTEGER is not a subrange type.
Neither is LONGINT.



From rodney_bates at lcwb.coop  Fri Jan  8 20:25:50 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:25:50 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <4B4786BE.3000607@lcwb.coop>



Tony Hosking wrote:
> Let's have a clean language proposal before thinking about implementing it...  ;-)
> 
> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
> 
> Looking further at the assignability rules:
> 
> A type T is assignable to a type U if:
> 
> 	? T <: U, or
> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
> 	? T and U are ordinal types with at least one member in common.
> 
> This suggests that we don't really need to say that INTEGER <: LONGINT.

I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
but it has some additional other consequences that I considered undesirable.  I don't
remember what they were off the top of my head, but could no doubt reconstruct them,
if anybody cares.

> 
> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
do one of:

1) Say LONGINT is not an ordinal type.

2) Say that 10 and 10L are not only expressions of different types, but
    also distinct values as well.  The low values of LONGINT and the
    corresponding values of INTEGER would not be the same.

3) Alter the definition of assignability, for example to say in the third clause,
    that T and U must have the same base type as well as a member in common.

Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
also mean there would be no subranges of LONGINT and probably eliminate several
other things you might expect to come along with LONGINT.

Doing 2) Seems like a big contradiction to the way subranges work and the existing
Modula-3 philosophy of types sometimes having overlapping value sets.

Which leaves 3), which I think is the only reasonable way to do this.

If we leave this as is, it will follow that assignment statements and mixed arithmetic
are legal and work the same way as with different subranges of the same base type.
Given the liberal assignability rules we already have, I don't think this is
necessarily a bad idea, despite my general bias toward requiring more stuff to
be explicit in code.  There are about 8 or 9 places, as I recall, that would be
affected because they require only assignability.

The definitions of the arithmetic operators would have to be treated with some care
to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
arithmetic, something we absolutely must avoid.  This points out where the analogy
to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
implementation is to expand the operands to the base type and do the arithmetic
in that size.  Here, we don't want that to happen unless at least one operand is
LONGINT.

On a side note, I do not believe the analogy to the floating types applies here.
With INTEGER/LONGINT, there is a very obvious and natural equivalence between
the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
different native machine floating types.  The messiness of floating representation
means you can't assume the exactly representable reals are the same for two different
floating types, even within some restricted value range.



> 
> On 8 Jan 2010, at 02:44, Jay K wrote:
> 
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>  
>>   LONGINT + INTEGER => LONGINT 
>>   LONGINT - INTEGER => LONGINT 
>>   LONGINT * INTEGER => LONGINT 
>>   LONGINT DIV INTEGER => LONGINT 
>>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>>   MAX(INTEGER, LONGINT) => LONGINT  
>>   LONGINT := INTEGER 
>>  
>> Other mixes are less obvious and would require runtime checks.
>>  
>> I think the backend will just work but I haven't tried that yet.
>>  (Truth be told, I can only affectively edit files on NT...)
>>  
>> Thoughts?
>>  
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:33:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:33:37 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
Message-ID: <4B478891.8010101@lcwb.coop>

Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
specific case where this community has seen significant need.  But I have a number of times
in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
new use cases will happen.  Especially, we can expect the proliferation of embedded devices
to create then.  And I really believe it can be done without a lot of violence to the
Language..

Tony Hosking wrote:
> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
> 
> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
> 
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:42:09 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:42:09 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <4B478A91.3090609@lcwb.coop>



Mika Nystrom wrote:
> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>>
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>>
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>>
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?
> 
> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)
> 
> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree, I hate the horrible complexities of implicit type conversions
in other languages.  But this doesn't have to be done by automatic type
conversion, just another instance of Modula-3's existing superior concept of
assignability between non-disjoint types.

> 
> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.
> 
>     Mika
> 

In my original proposal, I said:
-------------------------------------------------------------------------
This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.


-------------------------------------------------------------------------

I still believe we can do these things, and also that the changes
to the language are not too drastic.  They are mostly just more
instances of existing concepts.


From hosking at cs.purdue.edu  Fri Jan  8 21:40:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:40:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B478891.8010101@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
	<4B478891.8010101@lcwb.coop>
Message-ID: <597E64CD-7805-486C-AC7B-025A117C8B4E@cs.purdue.edu>

But should we really introduce restricted range multi-word arithmetic?
Why not instead make use of a general arbitrary range type like BigInteger.T?  (see the arithmetic package)

Again, I am acting devil's advocate here...

On 8 Jan 2010, at 14:33, Rodney M. Bates wrote:

> Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
> specific case where this community has seen significant need.  But I have a number of times
> in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
> new use cases will happen.  Especially, we can expect the proliferation of embedded devices
> to create then.  And I really believe it can be done without a lot of violence to the
> Language..
> 
> Tony Hosking wrote:
>> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
>> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/eb1437c5/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan  8 21:47:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:47:56 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B4786BE.3000607@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<4B4786BE.3000607@lcwb.coop>
Message-ID: <93B01681-30DB-4D5E-9429-131DCB74E794@cs.purdue.edu>

On 8 Jan 2010, at 14:25, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> Let's have a clean language proposal before thinking about implementing it...  ;-)
>> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
>> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
>> Looking further at the assignability rules:
>> A type T is assignable to a type U if:
>> 	? T <: U, or
>> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	? T and U are ordinal types with at least one member in common.
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> 
> I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
> but it has some additional other consequences that I considered undesirable.  I don't
> remember what they were off the top of my head, but could no doubt reconstruct them,
> if anybody cares.

Right, I much prefer assignability rule 3, rather than a subtype relationship.

>> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.
> 
> Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
> do one of:
> 
> 1) Say LONGINT is not an ordinal type.

Not necessarily.  See my definition of ORD/VAL in the update language spec.

> 2) Say that 10 and 10L are not only expressions of different types, but
>   also distinct values as well.  The low values of LONGINT and the
>   corresponding values of INTEGER would not be the same.

I don't think we need to say they are different values (in fact, they can be converted).  VAL(10, LONGINT) = 10L.

> 3) Alter the definition of assignability, for example to say in the third clause,
>   that T and U must have the same base type as well as a member in common.

In my definition both INTEGER and LONGINT *are* ordinal types so no need to change.

> Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
> also mean there would be no subranges of LONGINT and probably eliminate several
> other things you might expect to come along with LONGINT.

Agreed.

> Doing 2) Seems like a big contradiction to the way subranges work and the existing
> Modula-3 philosophy of types sometimes having overlapping value sets.

Agreed.

> Which leaves 3), which I think is the only reasonable way to do this.

I don't see the need if both are ordinal types.  They have some values in common.  So they are assignable.

> If we leave this as is, it will follow that assignment statements and mixed arithmetic
> are legal and work the same way as with different subranges of the same base type.
> Given the liberal assignability rules we already have, I don't think this is
> necessarily a bad idea, despite my general bias toward requiring more stuff to
> be explicit in code.  There are about 8 or 9 places, as I recall, that would be
> affected because they require only assignability.

So, in the current implementation we just don't have assignability and mixed arithmetic.

> The definitions of the arithmetic operators would have to be treated with some care
> to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
> arithmetic, something we absolutely must avoid.

Correct.

> This points out where the analogy
> to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
> implementation is to expand the operands to the base type and do the arithmetic
> in that size.

But that is exactly how the current implementation works.

> Here, we don't want that to happen unless at least one operand is
> LONGINT.

So, the base type yields the correct behavior.

> On a side note, I do not believe the analogy to the floating types applies here.
> With INTEGER/LONGINT, there is a very obvious and natural equivalence between
> the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
> different native machine floating types.  The messiness of floating representation
> means you can't assume the exactly representable reals are the same for two different
> floating types, even within some restricted value range.

Yes, that is why I am leaning in your direction: assignability plus mixed arithmetic.

> 
> 
> 
>> On 8 Jan 2010, at 02:44, Jay K wrote:
>>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>>   LONGINT + INTEGER => LONGINT   LONGINT - INTEGER => LONGINT   LONGINT * INTEGER => LONGINT   LONGINT DIV INTEGER => LONGINT   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)    LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)    MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)    MAX(INTEGER, LONGINT) => LONGINT    LONGINT := INTEGER  Other mixes are less obvious and would require runtime checks.
>>> I think the backend will just work but I haven't tried that yet.
>>> (Truth be told, I can only affectively edit files on NT...)
>>> Thoughts?
>>> 
>> 



From hosking at cs.purdue.edu  Fri Jan  8 21:51:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:51:13 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B478A91.3090609@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
	<4B478A91.3090609@lcwb.coop>
Message-ID: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>

Once more summarising the discussion so far.

*If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).

The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?

On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:

> 
> 
> Mika Nystrom wrote:
>> Tony Hosking writes:
>> ...
>>> A type T is assignable to a type U if:
>>> 
>>> 	=95 T <: U, or
>>> 	=95 U <: T and T is an array or a reference type other than =
>>> ADDRESS (This restriction is lifted in unsafe modules.), or
>>> 	=95 T and U are ordinal types with at least one member in =
>>> common.
>>> 
>>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>> 
>>> We can simply rely on the third clause regarding their both being =
>>> ordinal types with at least one member in common.  Then assignment =
>>> simply needs to test that the values are in range.
>>> 
>> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
>> the same "member"?
>> By a similar argument, you could make REAL and LONGREAL assignable.
>> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
>> the same bit patterns, same as 0 and 0L for that matter, and I can add
>> that the way you do single-precision floating point on Alpha is by zeroing
>> a big chunk in the middle of your double-precision fp registers...)
>> I think I am with you on removing LONGINT from the language.  The proper
>> way of handling file sizes (or anything else that might be a bigger number
>> than a machine word) is through abstraction.  I have a suspicion that it's
>> probably a severe micro-optimization to worry about the efficiency of
>> operations on file sizes.  The thought that someone is adding automatic
>> type conversion to Modula-3, a la C, makes me feel slightly sick to
>> my stomach...
> 
> I agree, I hate the horrible complexities of implicit type conversions
> in other languages.  But this doesn't have to be done by automatic type
> conversion, just another instance of Modula-3's existing superior concept of
> assignability between non-disjoint types.
> 
>> I confess that my position is influenced by the fact that I have written
>> many programs that generate Modula-3 code as an "intermediate language".
>> I really really really need M3 to be easy to understand to get this to
>> work well.  Also being able to parse interfaces and know precisely what
>> they mean is important to me.  If the rules start getting sloppy.. that
>> would really upset me.  On the other hand this means that if I'm faced
>> with a problem that doesn't really fit into M3 well, say, working in
>> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
>> to the language definition but to write a code generator that takes
>> appropriate infix (or maybe more likely prefix) code and turns it into
>> the appropriate calls through the Word interface.  It's a pain, yes, but in the long run that's the right way, because you can do so much
>> more with that approach than just unsigned integers.
>>    Mika
> 
> In my original proposal, I said:
> -------------------------------------------------------------------------
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> 
> -------------------------------------------------------------------------
> 
> I still believe we can do these things, and also that the changes
> to the language are not too drastic.  They are mostly just more
> instances of existing concepts.



From hendrik at topoi.pooq.com  Fri Jan  8 22:39:23 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:39:23 -0500
Subject: [M3devel] Integers
In-Reply-To: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
Message-ID: <20100108213923.GA9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> >> 
> >> What's unique about Modula-3 is that such representation changes are
> >> left to the compiler, while the language merely views values as
> >> sometimes belonging to more than one type, and allows such values to be
> >> assigned when so.  The usual approach in other languages is to elevate
> >> the representation change from a machine-level matter to a language-
> >> level matter by treating it as an implicit type change in addition to
> >> a representation change.  The result is always a lot of unnecessary
> >> complexity in the language.
> > ...
> > ...
> >>> 
> >>> Where in the language is it important that INTEGER and LONGINT be 
> >>> different base types?  In other words, what advantages does this 
> >>> separation convey?
> >> 
> >> One thing that is very much needed in a language (not the only thing)
> >> is a type that always matches the implementation's native arithmetic
> >> size, which is most efficient.  If you don't distinguish this type,
> >> it becomes either impossible or horribly convoluted to define arithmetic
> >> so native machine arithmetic can be usually used where possible,
> >> but multi-word arithmetic will be used where needed.
> > 
> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> > there any reason it cannot be a predefined subrange type of LONGINT?
> 
> I sense confusion here...
> 
> INTEGER is not a subrange type.

The question is not whether it is a subrange type.  It isn't.
The question is whether it could be.

> Neither is LONGINT.
> 

-- hendrik



From hosking at cs.purdue.edu  Fri Jan  8 22:47:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:47:00 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>

On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
> 
> The question is not whether it is a subrange type.  It isn't.
> The question is whether it could be.

I think that would result in major contradictions in the type system.



From mika at async.async.caltech.edu  Fri Jan  8 22:50:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 13:50:28 -0800
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com> 
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <20100108215028.40A651A207A@async.async.caltech.edu>


Hendrik, do you mean:

"INTEGER is that subrange of LONGINT that happens to be efficiently 
implementable on the target architecture"?

Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
choose it as I please when I configure/compile the compiler?

    Mika

hendrik at topoi.pooq.com writes:
>On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
>> 
>> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> >> 
>> >> What's unique about Modula-3 is that such representation changes are
>> >> left to the compiler, while the language merely views values as
>> >> sometimes belonging to more than one type, and allows such values to be
>> >> assigned when so.  The usual approach in other languages is to elevate
>> >> the representation change from a machine-level matter to a language-
>> >> level matter by treating it as an implicit type change in addition to
>> >> a representation change.  The result is always a lot of unnecessary
>> >> complexity in the language.
>> > ...
>> > ...
>> >>> 
>> >>> Where in the language is it important that INTEGER and LONGINT be 
>> >>> different base types?  In other words, what advantages does this 
>> >>> separation convey?
>> >> 
>> >> One thing that is very much needed in a language (not the only thing)
>> >> is a type that always matches the implementation's native arithmetic
>> >> size, which is most efficient.  If you don't distinguish this type,
>> >> it becomes either impossible or horribly convoluted to define arithmetic
>> >> so native machine arithmetic can be usually used where possible,
>> >> but multi-word arithmetic will be used where needed.
>> > 
>> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
>> > there any reason it cannot be a predefined subrange type of LONGINT?
>> 
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
>
>The question is not whether it is a subrange type.  It isn't.
>The question is whether it could be.
>
>> Neither is LONGINT.
>> 
>
>-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 22:50:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:50:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
Message-ID: <20100108215033.GB9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
> >> I sense confusion here...
> >> 
> >> INTEGER is not a subrange type.
> > 
> > The question is not whether it is a subrange type.  It isn't.
> > The question is whether it could be.
> 
> I think that would result in major contradictions in the type system.

Just what would the malign consequences be?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 22:53:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:53:29 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108215033.GB9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
Message-ID: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>

Then the base type of INTEGER would be LONGINT.

Thus, INTEGER operations would incur the expense of unnatural LONGINT operations.

That is unacceptable.

On 8 Jan 2010, at 16:50, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>>>> I sense confusion here...
>>>> 
>>>> INTEGER is not a subrange type.
>>> 
>>> The question is not whether it is a subrange type.  It isn't.
>>> The question is whether it could be.
>> 
>> I think that would result in major contradictions in the type system.
> 
> Just what would the malign consequences be?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/3e3aa509/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan  8 23:30:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 22:30:57 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>,
	<20100108173412.8531F1A207A@async.async.caltech.edu>,
	<4B478A91.3090609@lcwb.coop>,
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
Message-ID: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>


 > The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?


Two of us addressed this.

The answer is not technically/scientifically pleasing.
The answer is simply that in-fix operators are more convenient and libraries are not.

Obviously the general clean answer is either:

   operator overloading on user defined types, making the library convenient 

   or maybe a language feature for fixed but arbitrary precision integers

    e.g. 

     int1024 = BITS 1024 for INTEGER

     or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]

     or uint1024 = [0..Word.LShift(1, 1024)]

 

 

and the compiler would be compelled to generate code for any precision.

 

 

These are both more work.

LONGINT is indeed a special case.

C compilers all provide it "long long" or "__int64".

File sizes are indeed probably the typical use case for C?

But also things like InterlockedCompareExchange64 of some "packed" format.

 

Personally I would gladly accept

 FileSize = [0..Word.LShift(1, 63 or 64)];

 

 

even so...the compiler/language feature could (initially) limit the "bits" to 64, but

still implement via this more general syntax and not some new special type/keyword.

 

 

This is the question floating around: maybe there are just integers of varying size/range.

 

 

Maybe the compiler can notice if the size is <= or > a natural size?

 

Mixed arithmetic would be possible among arbitrary pairs of sizes and have a simple

formula for the result. Assuming "silent wraparound", addition would just pick the larger of the two.

But then, what if I assign to an even larger type? Hm.

Then you want addition of n and m to produce max(n, m) + 1, and such.

Perhaps there is some rule..you know..checked narrowing..?

And the checks can be omitted if the assignment is to a larger type?

e.g.

LONGINT := INTEGER + INTEGER => no overflow check

LONGINT := LONGINT + LONGINT => overflow check

int1024 := LONGINT + LONGINT => no overflow check

?

 

 

In reality I think no code would use the wider := narrow + narrow.

But it seems technically reasonable.

 

 

In reality code either wants the overflow check, or a type that expands its precision as needed.

("bignum", etc.)

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 15:51:13 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] mixing INTEGER and LONGINT?
> 
> Once more summarising the discussion so far.
> 
> *If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).
> 
> The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?
> 
> On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:
> 
> > 
> > 
> > Mika Nystrom wrote:
> >> Tony Hosking writes:
> >> ...
> >>> A type T is assignable to a type U if:
> >>> 
> >>> =95 T <: U, or
> >>> =95 U <: T and T is an array or a reference type other than =
> >>> ADDRESS (This restriction is lifted in unsafe modules.), or
> >>> =95 T and U are ordinal types with at least one member in =
> >>> common.
> >>> 
> >>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> >>> 
> >>> We can simply rely on the third clause regarding their both being =
> >>> ordinal types with at least one member in common. Then assignment =
> >>> simply needs to test that the values are in range.
> >>> 
> >> Are you sure about this for INTEGER and LONGINT? I.e., are 0 and 0L
> >> the same "member"?
> >> By a similar argument, you could make REAL and LONGREAL assignable.
> >> Are 0.0d0 and 0.0e0 the same "thing"? (On almost all machines they have
> >> the same bit patterns, same as 0 and 0L for that matter, and I can add
> >> that the way you do single-precision floating point on Alpha is by zeroing
> >> a big chunk in the middle of your double-precision fp registers...)
> >> I think I am with you on removing LONGINT from the language. The proper
> >> way of handling file sizes (or anything else that might be a bigger number
> >> than a machine word) is through abstraction. I have a suspicion that it's
> >> probably a severe micro-optimization to worry about the efficiency of
> >> operations on file sizes. The thought that someone is adding automatic
> >> type conversion to Modula-3, a la C, makes me feel slightly sick to
> >> my stomach...
> > 
> > I agree, I hate the horrible complexities of implicit type conversions
> > in other languages. But this doesn't have to be done by automatic type
> > conversion, just another instance of Modula-3's existing superior concept of
> > assignability between non-disjoint types.
> > 
> >> I confess that my position is influenced by the fact that I have written
> >> many programs that generate Modula-3 code as an "intermediate language".
> >> I really really really need M3 to be easy to understand to get this to
> >> work well. Also being able to parse interfaces and know precisely what
> >> they mean is important to me. If the rules start getting sloppy.. that
> >> would really upset me. On the other hand this means that if I'm faced
> >> with a problem that doesn't really fit into M3 well, say, working in
> >> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> >> to the language definition but to write a code generator that takes
> >> appropriate infix (or maybe more likely prefix) code and turns it into
> >> the appropriate calls through the Word interface. It's a pain, yes, but in the long run that's the right way, because you can do so much
> >> more with that approach than just unsigned integers.
> >> Mika
> > 
> > In my original proposal, I said:
> > -------------------------------------------------------------------------
> > This proposal satisfies (I believe) the following principles:
> > 
> > The static correctness and type analysis of existing code written to
> > the current language definition will not change with the new
> > definition. This also implies that the new language definition will
> > not introduce new type mismatches that would make existing pickles
> > unreadable.
> > 
> > The runtime semantics and time and space efficiency of existing code
> > written to the current language definition will also not change with
> > the new definition, if the native word size of the implementation does
> > not change. Of course, porting existing code to an implementation
> > with different native word size can change the runtime semantics by
> > changing the supported value range, with or without language change.
> > 
> > The static type analysis of programs written to the modified language
> > definition will be independent of the implementation, particularly, of
> > the native word size. This prevents inadvertently writing code that
> > is highly nonportable among different native word sizes.
> > 
> > The new, not-necessarily-native integer type does not extend to
> > certain existing uses of INTEGER and CARDINAL that are of unlikely
> > utility and would add complexity.
> > 
> > 
> > -------------------------------------------------------------------------
> > 
> > I still believe we can do these things, and also that the changes
> > to the language are not too drastic. They are mostly just more
> > instances of existing concepts.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0ec29705/attachment-0001.html>

From hendrik at topoi.pooq.com  Sat Jan  9 00:05:05 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:05:05 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108215028.40A651A207A@async.async.caltech.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
Message-ID: <20100108230505.GC9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
> 
> Hendrik, do you mean:
> 
> "INTEGER is that subrange of LONGINT that happens to be efficiently 
> implementable on the target architecture"?
> 
> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
> choose it as I please when I configure/compile the compiler?
> 
>     Mika

I've just been thinking of that.  Why even have a size for LONGINT?  Why 
not allow the programmer to use only subranges of LONGINT?  The 
arithmetic operations all have the property that you can compute 
subranges for the reults given subranges for the operands.  So 
intermediate results are all bounded in size, you can compute without 
overflow happening ... until you get to narrow the final result for 
assignment to whatever variable you want to 
assign it to.

I suspect there are compiler optimisations (well, let's ne honest, 
call them ameliorations) that could be performed to move the final 
range-truncate-check backward through the series of operations and limit 
the number of unnecessary bits that have been computed.  These 
ameliorations are likely to be more effective if no range check need be 
performed on final assignment (but there's always a conflict between 
amelioration and run-time checks, isn't there?)

We could do this for LONGINT completely independent of whatever we do 
with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
INTEGER is what you use when you particularly want to use 
machine-efficient data and operations.  LONGINT is what you use when 
that's not enough, and you want to statically specify the size of 
integer you need, and pay the price.  What with machines having carry 
and overflow flags, add-with-carry instructions, it chould be possible 
to generate reasonably efficient code anyway, without the full overhead 
of run-time-determined number sizes.

Most machines already have integer multiply instructions that return a 
double-length product.  It's such a pity to waste them.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 00:11:54 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:11:54 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
	<COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
Message-ID: <20100108231154.GD9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:30:57PM +0000, Jay K wrote:
> 
>  > The question remains: is LONGINT necessary or simply a kludge 
>  > better satisfied by arbitrary precision arithmetic like 
>  > BigInteger.T?
> 
> 
> Two of us addressed this.
> 
> The answer is not technically/scientifically pleasing.
> The answer is simply that in-fix operators are more convenient and 
> libraries are not.
> 
> Obviously the general clean answer is either:
> 
>    operator overloading on user defined types, making the library convenient 
> 
>    or maybe a language feature for fixed but arbitrary precision integers

Why not make LONGINT the base type for all these fixed but arbitrary 
precision integers.  But don't allow anyone to declare a variable of 
type LONGINT, so we never have to specify a size for it, and its 
subranges can be as large as anyone pleases.

>     e.g. 
      e.g. 
> 
> 
>      int1024 = BITS 1024 for INTEGER
       int1024 = BITS 1024 for LONGINT
 
>      or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]
       or uint1024 = BITS 1024 for [0..Word.LShift(1L, 1024)]
> 
>      or uint1024 = [0..Word.LShift(1, 1024)]
       or uint1024 = [0..Word.LShift(1L, 1024)]
> 
> and the compiler would be compelled to generate code for any precision.
> 
> These are both more work.
> 
> LONGINT is indeed a special case.

But if we let it be finite but unbounded it's a rather different special 
case.

-- hendrik


From hosking at cs.purdue.edu  Sat Jan  9 01:53:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 19:53:07 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108230505.GC9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
Message-ID: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>

I think what you are advocating is Rodney's proposal + assignability of INTEGER and LONGINT + mixed arithmetic.

On 8 Jan 2010, at 18:05, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
>> 
>> Hendrik, do you mean:
>> 
>> "INTEGER is that subrange of LONGINT that happens to be efficiently 
>> implementable on the target architecture"?
>> 
>> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
>> choose it as I please when I configure/compile the compiler?
>> 
>>    Mika
> 
> I've just been thinking of that.  Why even have a size for LONGINT?  Why 
> not allow the programmer to use only subranges of LONGINT?  The 
> arithmetic operations all have the property that you can compute 
> subranges for the reults given subranges for the operands.  So 
> intermediate results are all bounded in size, you can compute without 
> overflow happening ... until you get to narrow the final result for 
> assignment to whatever variable you want to 
> assign it to.
> 
> I suspect there are compiler optimisations (well, let's ne honest, 
> call them ameliorations) that could be performed to move the final 
> range-truncate-check backward through the series of operations and limit 
> the number of unnecessary bits that have been computed.  These 
> ameliorations are likely to be more effective if no range check need be 
> performed on final assignment (but there's always a conflict between 
> amelioration and run-time checks, isn't there?)
> 
> We could do this for LONGINT completely independent of whatever we do 
> with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
> INTEGER is what you use when you particularly want to use 
> machine-efficient data and operations.  LONGINT is what you use when 
> that's not enough, and you want to statically specify the size of 
> integer you need, and pay the price.  What with machines having carry 
> and overflow flags, add-with-carry instructions, it chould be possible 
> to generate reasonably efficient code anyway, without the full overhead 
> of run-time-determined number sizes.
> 
> Most machines already have integer multiply instructions that return a 
> double-length product.  It's such a pity to waste them.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/7661b06f/attachment-0001.html>

From hendrik at topoi.pooq.com  Sat Jan  9 02:33:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:33:42 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
Message-ID: <20100109013342.GA23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> I think what you are advocating is Rodney's proposal + assignability 
> of INTEGER and LONGINT + mixed arithmetic.

I thought Rodney's propsal still had the compiler impose a bound on the 
size of LONGINT.  Or did I miss something?

I'm proposing to let the programmer use subranges of LONGINT that are as 
long as he wishes.  And if the computer runs out of virtual memory to 
store one of the programmer's long integers, well, that's the computer 
imposing the limit, not the language.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 02:40:31 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:40:31 -0500
Subject: [M3devel] Integers
In-Reply-To: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
	<7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
Message-ID: <20100109014030.GB23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:53:29PM -0500, Tony Hosking wrote:
> Then the base type of INTEGER would be LONGINT.
> 
> Thus, INTEGER operations would incur the expense of unnatural LONGINT 
> operations.

I get it.  It's not a matter of the size of the INTEGERs; it's a matter 
of the operations on them -- that operations on INTEGERs are limited to 
whatever size the computer processes efficiently, and that this limit is 
*checked* (at least in principle) for reliability.

-- hendrik

> 
> That is unacceptable.


From hendrik at topoi.pooq.com  Sat Jan  9 02:44:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:44:37 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <20100109014437.GC23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > I think what you are advocating is Rodney's proposal + assignability 
> > of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).

-- hendrik
> 
> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.


From jay.krell at cornell.edu  Sat Jan  9 03:09:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:09:13 +0000
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>,
	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>, <20100108190409.GF14151@topoi.pooq.com>,
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>,
	<20100108213923.GA9749@topoi.pooq.com>,
	<20100108215028.40A651A207A@async.async.caltech.edu>,
	<20100108230505.GC9749@topoi.pooq.com>,
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>,
	<20100109013342.GA23519@topoi.pooq.com>,
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <COL101-W8A809232A5F6A9D4948D2E66F0@phx.gbl>


I hear Hendrik proposing that "LONGINT" is the name for fixed arbitrary precision integers.

That it might even have a name. Or the user has to mention it in order to acknowledge

he is using something potentially inefficient.

 

 

 FileSize = BITS 64 FOR LONGINT;

 FileSize = [1..LongInt.LShift(1, 63)];

 FileSize = LONGINT[64];

 or such 

 

This is not a bad idea.

 

I think the "real" problem here is a multitude of options/scenarios and

a lack of vocabulary.

As I said, there is a time/place for "silent wraparound", for trapping overflow,

for extending precision to fit.

 

Also I'm surprised you can't mix REAL and LONGREAL.

 

Also I don't think INTEGER + LONGINT is all that confusing or, as I said, subtle.

It isn't /immediately/ obvious how to deal with MIN, MAX, MOD, DIV, but

it is still not that tricky.

 

MIN(INTEGER, LONGINT) is INTEGER. Not that difficult to figure out why.

 At least one of the inputs fits in an integer and the result is the smaller input.

 

MAX(INTEGER, LONGINT) is LONGINT, ditto.

  One of the inputs might not fit in an INTEGER and the result is the larger input.

 

INTEGER DIV LONGINT is INTEGER

BIG DIV SMALL1 is SMALL2

SMALL DIV BIG is 0 remainder SMALL.

 

LONGINT DIV INTEGER is LONGINT

Prove with one simple case:

BIG1 DIV 2 is BIG2.

Easier BIG1 DIV 1 is BIG1.

 

Consider: LONGINT MOD INTEGER and INTEGER MOD LONGINT

SMALL divided by BIG is, again, 0 remainder SMALL, INTEGER

BIG divided by SMALL1 is SMALL2, remainder [0..SMALL1 - 1] which is INTEGER.

 

That is, division either gives you 0 and remainder = first number.

Or it gives you non-zero and remainder is less than the second number.

  50 divided by 100 is 0 remainder 50.

  109 divided by 10 is 10 remainder 9

 

FOR loops also should allow mixing.

 

 - Jay

 
> Date: Fri, 8 Jan 2010 20:44:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT (was: Re: Integers
> 
> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > > I think what you are advocating is Rodney's proposal + assignability 
> > > of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT. Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
> > 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes. And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/49c07b7c/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 03:16:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:16:57 +0000
Subject: [M3devel] still need a branch for longint changes?
Message-ID: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>


Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/cbc21635/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 03:23:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:23:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
Message-ID: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>

Please hold off on mainline changes.  I don't think we have reached consensus yet...

The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.

On 8 Jan 2010, at 21:16, Jay K wrote:

> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/902c8d90/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 03:28:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:28:59 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <7A1B4E83-A69C-43CA-9932-38B974B22B60@cs.purdue.edu>

I'm not sure how this would all work exactly...  It would make LONGINT a very strange beast indeed, compared to the other ordinal types.

On 8 Jan 2010, at 20:44, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability 
>>> of INTEGER and LONGINT + mixed arithmetic.
>> 
>> I thought Rodney's propsal still had the compiler impose a bound on the 
>> size of LONGINT.  Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
>> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as 
>> long as he wishes.  And if the computer runs out of virtual memory to 
>> store one of the programmer's long integers, well, that's the computer 
>> imposing the limit, not the language.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/a6c32d22/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 03:32:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:32:47 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>

On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>> I think what you are advocating is Rodney's proposal + assignability 
>> of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

Yes, it would.

> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.

But there is still the question as to what *representation* is used to decide the particular operation to apply.

I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.

Just for fun, I suggest you take some time to watch the talk Growing a Language, by Guy Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/f9495a09/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 03:36:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:36:54 +0000
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>


I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.

And mixed arithmetic is available, and assignability INTEGER to LONGINT.

I have that implemented. It is a little onerous for Rd/Wr uses, but ok.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 8 Jan 2010 21:23:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] still need a branch for longint changes?


Please hold off on mainline changes.  I don't think we have reached consensus yet...


The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.



On 8 Jan 2010, at 21:16, Jay K wrote:

Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/0d2b4846/attachment-0001.html>

From hendrik at topoi.pooq.com  Sat Jan  9 04:00:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:00:41 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <20100109030040.GA28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:32:47PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >> I think what you are advocating is Rodney's proposal + assignability 
> >> of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes.  And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine 
> representation based on the range of values in the subrange (much as 
> it does currently).

That's exactly what I propose.

> But if you really want to have an arbitrary range type I would argue 
> it is much better to implement it as a library than as a primitive 
> type.

That's fine if I have no static limit on the size of the integers.  Like 
if I want to have an open array.  Or even an array that I can resize 
dynamically.  But for the common case where I know exactly what the 
limits are, static is better.

(and that's the case with file offsets, for example)

What's easier for the compiler writer is another matter, of course.

> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele

I'll try and find it.  I seem to remember seeing the text somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 04:03:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:03:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <20100109030314.GB28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:23:15PM -0500, Tony Hosking wrote:
> Please hold off on mainline changes.  I don't think we have reached 
> consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  
> I'm leaning towards allowing it, but want to hear from others.

Not to mention the question whether the conpiler should impose a static 
bound on LONGINT.

-- hendrik


From jay.krell at cornell.edu  Sat Jan  9 04:54:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 03:54:31 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108142811.GA14151@topoi.pooq.com>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>,
	<20100108142811.GA14151@topoi.pooq.com>
Message-ID: <COL101-W1340FFFD0FCE25D04F7C2EE66F0@phx.gbl>


Oops, of course, thank you.
I'll update my changes...maybe check them into a branch..

 - Jay

> From: hendrik

>     MIN( 5, -1000000000000000L) = -1000000000000000L
>     So the result really needs to be LONGINT.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/a0666723/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 06:06:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:06:07 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
	<COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
Message-ID: <77A73750-12DF-4BB2-B6AF-6919FC2687FE@cs.purdue.edu>

So, thinking about things some more I am very much less inclined to believe that mixed operand arithmetic makes any sense, though assignability with run-time range checks seems fine.

With mixed operand arithmetic we get to some very strange places:

LAST(INTEGER) + 1 = FIRST(INTEGER)

is true because of overflow under the standard Modula-3 implementation.

But,

LAST(INTEGER) + 1L = FIRST(INTEGER)

is false because the arithmetic will be performed as LONGINT.

The trivial presence of "1L" instead of "1" has a huge impact on the semantics.  That seems really dangerous.

Much better (if wordier) to require explicit conversion (as currently implemented) to preserve sanity.

Thus,

VAL(LAST(INTEGER), LONGINT) + 1L = VAL(FIRST(INTEGER), LONGINT)

is false, as the programmer rightly expects, because he/she will be explicitly (because of the conversions) aware that LONGINT arithmetic is taking place.

On 8 Jan 2010, at 21:36, Jay K wrote:

> I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.
> And mixed arithmetic is available, and assignability INTEGER to LONGINT.
> I have that implemented. It is a little onerous for Rd/Wr uses, but ok.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 21:23:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] still need a branch for longint changes?
> 
> Please hold off on mainline changes.  I don't think we have reached consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.
> 
> On 8 Jan 2010, at 21:16, Jay K wrote:
> 
> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 
> 
> 



From hosking at cs.purdue.edu  Sat Jan  9 06:37:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:37:42 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>

Looking at your code, I think the assignability test for ordinals should be more like:

      IF (IsEqual (Base(a), Base(b), NIL)
          OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
          OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

That way CARDINAL and other subranges fall right out.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 8 Jan 2010, at 06:13, Jay K wrote:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>  
>  
> The compiler change is newer than earlier.
> For example you can now assign CARDINAL to LONGINT.
> I didn't do it, but you should also be able to add/subtract/etc.
> mixing CARDINAL and LONGINT.
>  
> 
> FOR statements also don't allow the level of mixing
> that they should.
> 
>  
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..
>  
> 
>  - Jay
> <dif8.txt>



From jay.krell at cornell.edu  Sat Jan  9 06:50:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 05:50:06 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
Message-ID: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>


I don't know the precedence but agreed:


>           OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>           OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Also, I really think mixed arithmetic is ok.

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
>       IF (IsEqual (Base(a), Base(b), NIL)
>           OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>           OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> >  
> >  
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> >  
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> >  
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> >  
> > 
> >  - Jay
> > <dif8.txt>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/f180057b/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 07:03:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 01:03:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
Message-ID: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>

On 9 Jan 2010, at 00:50, Jay K wrote:

> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.

> Also, I really think mixed arithmetic is ok.

But are you ok with:

(LAST(INTEGER) + 1) = FIRST(INTEGER)

while

(LAST(INTEGER) + 1L) # FIRST(INTEGER)

?

I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/c19ddba8/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 07:59:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 06:59:52 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>


I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/71f3af0e/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 08:01:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:01:47 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>


 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ca682d11/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 08:52:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:52:29 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	, , <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W589E03B28FAE7C3BAF1521E66F0@phx.gbl>


ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];

VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs








 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/bd443b6b/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 10:04:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:04:03 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W177E347253C078605A975CE66F0@phx.gbl>


Uh, maybe all ordinal types that overlap in any values are assignable?

 

 

PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if they have at least one member in common. *)
      IF GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;
    ELSIF IsSubtype (a, b) THEN
      (* may be ok, but must narrow rhs before doing the assignment *)
      RETURN IsSubtype (b, Reff.T)
          OR ArrayType.Split (b, i, e)
          OR (IsSubtype (b, Addr.T)
              AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
    ELSE
      RETURN FALSE;
    END;
  END IsAssignable;


 

?

I'll try it out.

 

 

What is an ordinal type?, I wonder, the compiler implementation:

 

 

PROCEDURE IsOrdinal (t: T): BOOLEAN =
  VAR u := Check (t);  c := u.info.class;
  BEGIN
    RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
           OR (c = Class.Enum) OR (c = Class.Error)
           OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
  END IsOrdinal;


 

 - Jay





 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 07:52:29 +0000



ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];
VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




 > (LAST(INTEGER) + 1) = FIRST(INTEGER)

ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000



I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




On 9 Jan 2010, at 00:50, Jay K wrote:


I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.



Yes, that would be why.


Also, I really think mixed arithmetic is ok.



But are you ok with:


(LAST(INTEGER) + 1) = FIRST(INTEGER)


while


(LAST(INTEGER) + 1L) # FIRST(INTEGER)


?


I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!



 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3191062e/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 10:34:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:34:06 +0000
Subject: [M3devel] index array by longint?
Message-ID: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>


Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

  Or really, with runtime bounds check against the array size.

 

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

 

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/7d9b10b0/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 11:22:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 10:22:21 +0000
Subject: [M3devel] another longint variant
Message-ID: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>


[attached]

In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.

 


Specifically:

  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)

 


  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length

   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then

 


  no VAL or ORD needed


 

  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"

 


  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment-0001.txt>

From hosking at cs.purdue.edu  Sat Jan  9 19:24:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:24:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <0D79BD22-2EB9-4EC8-A453-CC2E0A66AA8C@cs.purdue.edu>

The patch I sent to you yesterday will achieve checked assignment of LONGINT to/from INTEGER.

On 9 Jan 2010, at 04:04, Jay K wrote:

> Uh, maybe all ordinal types that overlap in any values are assignable?
>  
>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127 
> 
> either:
>   is true
>   or false 
>   or raises an exception 
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127 
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;   
>   INTEGER first := 16_80; 
>   INTEGER p1 := max + 1; 
>   LONGINT p1L := max + 1L; 
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.
> 
> Yes, that would be why.
> 
> Also, I really think mixed arithmetic is ok.
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!
> 
> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/f559ce4c/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 19:25:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:25:23 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <CC8493F7-82F9-4004-8B0F-D470B1FFDCC1@cs.purdue.edu>

I think having assignability let's you do what you need.  The range check on assignment will then allow you to index...

On 9 Jan 2010, at 04:34, Jay K wrote:

> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/a6af6f03/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 19:30:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:30:55 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
Message-ID: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...

On 9 Jan 2010, at 05:22, Jay K wrote:

> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/59f2afbb/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 20:33:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 19:33:45 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
Message-ID: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>


I don't believe that suffices but I can check again.

 

 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/992ac302/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 20:52:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 14:52:19 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
Message-ID: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>

It should suffice for assignability...

On 9 Jan 2010, at 14:33, Jay K wrote:

> I don't believe that suffices but I can check again.
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ac197d50/attachment-0001.html>

From rodney_bates at lcwb.coop  Sat Jan  9 20:50:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 13:50:25 -0600
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <4B48DE01.8040303@lcwb.coop>



Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> <mailto:hendrik at topoi.pooq.com> wrote:
> 
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability
>>> of INTEGER and LONGINT + mixed arithmetic.
>>
>> I thought Rodney's propsal still had the compiler impose a bound on the
>> size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as
>> long as he wishes.  And if the computer runs out of virtual memory to
>> store one of the programmer's long integers, well, that's the computer
>> imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to 
> decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine representation 
> based on the range of values in the subrange (much as it does currently).
> But if you really want to have an arbitrary range type I would argue it 
> is much better to implement it as a library than as a primitive type.

This I agree with wholeheartedly.  Don't we already have some math libraries
for things like this, or maybe rational arithmetic, etc?


> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele 
> <http://video.google.com/videoplay?docid=-8860158196198824415>


From jay.krell at cornell.edu  Sat Jan  9 21:17:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:17:32 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
Message-ID: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>


[replacing periods with semicolons to avoid truncation..]

 

 

Right..I was going to say..as an overall change, like if we

want mixed operations, it really doesn't suffice;

Many of my m3front changes were in direct response

to compilation errors and fixed them;

 

 

I'm sure as well that just allowing assignability doesn't make the rd/wr

change particuarly small/smooth. You need mixed operations,

indexing, new, or else sprinkle ORD around;

 

 

There's a particular characteristic I should point out in the rd/wr code;

Maybe rd/wr should be modified..but it probably can't;

In particular, my understanding of rd/wr is that the maintain two

"numbers" (integer or longint, depending on how everything is resolved);

These numbers indicate the file offset that is at the start of the buffer

and at the end of the buffer. In a new world they need to be LONGINT;

However their "span", their difference, describes an

in-memory buffer size. Therefore their difference is always INTEGER

or CARDINAL, not LONGINT. It'd be super cool, but probably not

possible, if the language let you declare this somehow.

THEN mixed operations and such wouldn't be needed,

if the compiler new that subtracting these two integers

yielded an INTEGER, and possibly inserted checks of that;

But this is probably just a lazy user view and not realistic

for the language.

 

 

For assignability I think your change does work but mine was less wordy

and maybe more general;

The preexisting code allowed I believe any non-LONGINT ordinal

type to be assigned to any non-LONGINT ordinal type if there

are any overlapping values. Specifically really,

non-ordinal types with same base type and anyoverlap.

I removed the base type check;

This makes enums <=> longint, integer subranges <=> longint, etc;

 

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 14:52:19 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant




It should suffice for assignability...


On 9 Jan 2010, at 14:33, Jay K wrote:

I don't believe that suffices but I can check again.
 
 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/067315ea/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan  9 21:20:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:20:32 +0000
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>,<4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>,
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>,
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <COL101-W417229BE8A4B934A7D89EBE66F0@phx.gbl>


Yes we have some such libraries;

The "problem" is that libraries are inconvenient and in-fix operatores are convenient;

You either need to:

   accept that and use what works

   or make the language amenable to more convenient libraries

    (i.e. provide for operator overloading in the language)

   or make more stuff "built in" / "special"

 

 

We will probably just do the first.

LONGINT will probably just always be exactly 64bits, no more, no less,

and have the same overflow features as INTEGER;

 

It'd be nifty for me if the frontend learned to do arbitrary precision

integer arithmetic, because then NT386 would get a working LONGINT that way;

But that's not a valid reason. :)

 

 - Jay


 
> Date: Sat, 9 Jan 2010 13:50:25 -0600
> From: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT
> 
> 
> 
> Tony Hosking wrote:
> > On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> > <mailto:hendrik at topoi.pooq.com> wrote:
> > 
> >> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >>> I think what you are advocating is Rodney's proposal + assignability
> >>> of INTEGER and LONGINT + mixed arithmetic.
> >>
> >> I thought Rodney's propsal still had the compiler impose a bound on the
> >> size of LONGINT. Or did I miss something?
> > 
> > Yes, it would.
> > 
> >> I'm proposing to let the programmer use subranges of LONGINT that are as
> >> long as he wishes. And if the computer runs out of virtual memory to
> >> store one of the programmer's long integers, well, that's the computer
> >> imposing the limit, not the language.
> > 
> > But there is still the question as to what *representation* is used to 
> > decide the particular operation to apply.
> > 
> > I suppose the compiler could choose a particular machine representation 
> > based on the range of values in the subrange (much as it does currently).
> > But if you really want to have an arbitrary range type I would argue it 
> > is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly. Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?
> 
> 
> > 
> > Just for fun, I suggest you take some time to watch the talk Growing a 
> > Language, by Guy Steele 
> > <http://video.google.com/videoplay?docid=-8860158196198824415>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3432e1d0/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 21:21:43 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:21:43 -0500
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <B79AEE7D-4178-44E1-AD26-29488EC8FC40@cs.purdue.edu>

On 9 Jan 2010, at 14:50, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com <mailto:hendrik at topoi.pooq.com> wrote:
>>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>>> I think what you are advocating is Rodney's proposal + assignability
>>>> of INTEGER and LONGINT + mixed arithmetic.
>>> 
>>> I thought Rodney's propsal still had the compiler impose a bound on the
>>> size of LONGINT.  Or did I miss something?
>> Yes, it would.
>>> I'm proposing to let the programmer use subranges of LONGINT that are as
>>> long as he wishes.  And if the computer runs out of virtual memory to
>>> store one of the programmer's long integers, well, that's the computer
>>> imposing the limit, not the language.
>> But there is still the question as to what *representation* is used to decide the particular operation to apply.
>> I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
>> But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly.  Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?

Yes, the arithmetic package (m3-libs/arithmetic).

From hosking at cs.purdue.edu  Sat Jan  9 21:54:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:54:22 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>

On 9 Jan 2010, at 15:17, Jay K wrote:

> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;

I'd like precise examples.

>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.

>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.

That would be tricky...

>  For assignability I think your change does work but mine was less wordy
> and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.

> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;

That's what broke it.

> This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?

I really want to see the impact of not allowing mixed arithmetic while having assignability.

> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/19f37b03/attachment-0001.html>

From rodney_bates at lcwb.coop  Sat Jan  9 23:15:16 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 16:15:16 -0600
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <4B48FFF4.8050307@lcwb.coop>



Tony Hosking wrote: (excerpted)
>........................................
>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
> 
> Currently, direct comparison between LONGINT and INTEGER is not 
> permitted.  If it were then this would be true.
> 


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

> 
>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>    like" (but is not equal to) [0..LAST(LONGINT)].
>>
>>      The current CARDINAL has an interesting history.  Originally, it
>>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>>      was later changed to be "just like" the subrange, i.e., the two
>>      are not the same type, but have the same properties in every
>>      other respect.  The only reason for the change had to do with
>>      reading pickles, which are completely defined and implemented as
>>      library code.  The change did affect the type analysis of the
>>      language, nevertheless.
>>
>>      We should preserve this property for LONGCARD too.
> 
> Currently there is no implementation of LONGCARD.  I argue that we don't 
> need LONGCARD (since, as discussed below, NUMBER should stay typed as 
> CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

>> 20. The statement that the upperbound of a FOR loop should not be
>>    LAST(INTEGER) also applies to LAST(LONGINT).
> 
> Agreed.
> 
>>      Note that the existing definition of FOR otherwise generalizes
>>      to LONGINT without change.
> 
> The current implementation does not permit the range values to be 
> different types (both must be INTEGER or LONGINT), and the step value 
> must also match.  Will we permit any mixing of values?  If so, I assume 
> that we use the maximal type of the expressions (LONGINT if any one is 
> LONGINT, INTEGER otherwise).
>

I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


>> 22. There is a new required interface LongWord.  It almost exactly
>>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>    new functions ToWord and FromWord, that conversion between the two
>>    types, using unsigned interpretations of the values.  ToInt may
>>    produce a checked runtime error, if the result value is not in the
>>    range of an unsigned interpretation of INTEGER.
> 
> This is the current implementation, but we do not support ToWord and 
> FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

> 
>>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>      consistency.  This means simple assignability tests and
>>      assignments between the types will use signed interpretations.
>>      So different functions are needed to do size changes with
>>      unsigned interpretation.
> 
> This is the current implementation.
> 
>


From hosking at cs.purdue.edu  Sat Jan  9 23:45:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:45:09 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B48FFF4.8050307@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
Message-ID: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>

Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote: (excerpted)
>> ........................................
>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
> I remember there was some vexing problem about what the result type
> should be for FIRST and LAST, but not the details.  It seems to
> me now that the only thing that makes any sense is to preserve the
> existing rule that it is the base type of the argument type.
> This is really necessary to preserve existing semantics of the
> language and of existing code.
> 
> This original proposal seems to be silent on the matter, which I suppose
> means I intended it as a NO CHANGE.  I guess, if
> mixed relations are allowed, then I can't think of a problem
> with this.  Even if mixed relations are disallowed, this range
> constraint could be expressed with explicit conversions, I suppose.
> 
> .......................................................................
> 
>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>> 
>>>     The current CARDINAL has an interesting history.  Originally, it
>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>     was later changed to be "just like" the subrange, i.e., the two
>>>     are not the same type, but have the same properties in every
>>>     other respect.  The only reason for the change had to do with
>>>     reading pickles, which are completely defined and implemented as
>>>     library code.  The change did affect the type analysis of the
>>>     language, nevertheless.
>>> 
>>>     We should preserve this property for LONGCARD too.
>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> LONGCARD is needed for pickles (and for no other reason, that I can
> think of).  The problem is that if a record or object has a field of
> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
> the type to be different on different target machines, making a pickle
> written on, say a 32-bit machine unreadable on a 64-bit machine.
> LONGCARD can be treated as the same type regardless of word size,
> allowing the automatic size changes pickles already does for INTEGER,
> CARDINAL, and LONGINT to extend to this subrange too.
> 
> (Note: If you try to extend this size-changing by pickles to arbitrary
> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
> are jumping head first into a tar pit.  I've thought about it just enough
> to conclude I wanted to step back.)
> 
> .......................................................................
> 
>>> 20. The statement that the upperbound of a FOR loop should not be
>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>> Agreed.
>>>     Note that the existing definition of FOR otherwise generalizes
>>>     to LONGINT without change.
>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>> 
> 
> I think allowing mixtures here is going too far.  Moreover, the existing
> rule for FOR already requires the same base type for the two bounds, unlike
> the assignability rule for operators, so unless we change an existing
> language rule here, this form of mixing is not allowed.
> 
> Note that the step value is "integer-valued" unconditionally, i.e.,
> even if the bounds have, say, an enumeration type.  Taken literally, I
> would say this would allow its type to be INTEGER, LONGINT, or any subrange
> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
> a use.
> 
> ......................................................................
> 
> 
>>> 22. There is a new required interface LongWord.  It almost exactly
>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>   new functions ToWord and FromWord, that conversion between the two
>>>   types, using unsigned interpretations of the values.  ToInt may
>>>   produce a checked runtime error, if the result value is not in the
>>>   range of an unsigned interpretation of INTEGER.
>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> All the operations in Word apply an unsigned interpretation to the bits
> of the word, whereas the operators and functions in the language apply
> signed.  Unsigned expansion is different(zero extend) from signed (sign
> extend).  FromWord would do the unsigned, while VAL would do the signed.
> 
> Similarly, for contracting, the value range check is different.  Signed
> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
> 32 are all zero.
> 
>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>     consistency.  This means simple assignability tests and
>>>     assignments between the types will use signed interpretations.
>>>     So different functions are needed to do size changes with
>>>     unsigned interpretation.
>> This is the current implementation.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/179319ae/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan  9 23:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:48:05 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <337A4383-95A2-4767-8A9E-4C8EEE88B5AC@cs.purdue.edu>

Actually, that doesn't make sense -- it is an empty subrange.

On 9 Jan 2010, at 17:45, Tony Hosking wrote:

> Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:
> 
>> 
>> 
>> Tony Hosking wrote: (excerpted)
>>> ........................................
>>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
>> 
>> 
>> I remember there was some vexing problem about what the result type
>> should be for FIRST and LAST, but not the details.  It seems to
>> me now that the only thing that makes any sense is to preserve the
>> existing rule that it is the base type of the argument type.
>> This is really necessary to preserve existing semantics of the
>> language and of existing code.
>> 
>> This original proposal seems to be silent on the matter, which I suppose
>> means I intended it as a NO CHANGE.  I guess, if
>> mixed relations are allowed, then I can't think of a problem
>> with this.  Even if mixed relations are disallowed, this range
>> constraint could be expressed with explicit conversions, I suppose.
>> 
>> .......................................................................
>> 
>>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>>> 
>>>>     The current CARDINAL has an interesting history.  Originally, it
>>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>>     was later changed to be "just like" the subrange, i.e., the two
>>>>     are not the same type, but have the same properties in every
>>>>     other respect.  The only reason for the change had to do with
>>>>     reading pickles, which are completely defined and implemented as
>>>>     library code.  The change did affect the type analysis of the
>>>>     language, nevertheless.
>>>> 
>>>>     We should preserve this property for LONGCARD too.
>>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
>> 
>> LONGCARD is needed for pickles (and for no other reason, that I can
>> think of).  The problem is that if a record or object has a field of
>> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
>> the type to be different on different target machines, making a pickle
>> written on, say a 32-bit machine unreadable on a 64-bit machine.
>> LONGCARD can be treated as the same type regardless of word size,
>> allowing the automatic size changes pickles already does for INTEGER,
>> CARDINAL, and LONGINT to extend to this subrange too.
>> 
>> (Note: If you try to extend this size-changing by pickles to arbitrary
>> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
>> are jumping head first into a tar pit.  I've thought about it just enough
>> to conclude I wanted to step back.)
>> 
>> .......................................................................
>> 
>>>> 20. The statement that the upperbound of a FOR loop should not be
>>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>>> Agreed.
>>>>     Note that the existing definition of FOR otherwise generalizes
>>>>     to LONGINT without change.
>>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>>> 
>> 
>> I think allowing mixtures here is going too far.  Moreover, the existing
>> rule for FOR already requires the same base type for the two bounds, unlike
>> the assignability rule for operators, so unless we change an existing
>> language rule here, this form of mixing is not allowed.
>> 
>> Note that the step value is "integer-valued" unconditionally, i.e.,
>> even if the bounds have, say, an enumeration type.  Taken literally, I
>> would say this would allow its type to be INTEGER, LONGINT, or any subrange
>> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
>> a use.
>> 
>> ......................................................................
>> 
>> 
>>>> 22. There is a new required interface LongWord.  It almost exactly
>>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>>   new functions ToWord and FromWord, that conversion between the two
>>>>   types, using unsigned interpretations of the values.  ToInt may
>>>>   produce a checked runtime error, if the result value is not in the
>>>>   range of an unsigned interpretation of INTEGER.
>>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
>> 
>> All the operations in Word apply an unsigned interpretation to the bits
>> of the word, whereas the operators and functions in the language apply
>> signed.  Unsigned expansion is different(zero extend) from signed (sign
>> extend).  FromWord would do the unsigned, while VAL would do the signed.
>> 
>> Similarly, for contracting, the value range check is different.  Signed
>> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
>> 32 are all zero.
>> 
>>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>>     consistency.  This means simple assignability tests and
>>>>     assignments between the types will use signed interpretations.
>>>>     So different functions are needed to do size changes with
>>>>     unsigned interpretation.
>>> This is the current implementation.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/de7fd697/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 00:47:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:47:16 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W503E27DAB92E218864CB0BE66F0@phx.gbl>


On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ab3d2815/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 00:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:48:41 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W345C207A34D36A982DD968E66F0@phx.gbl>


Sorry, right, I read 16_FFFFFFFF as 16_7FFFFFFFF.
Is this "not full range" thing we've been vaguly mentioning.
Guessing, I think it is easier to define with the "half range".
"All cardinals fit in integers" ?
Something like that?
No range check needed moving between them?

 - Jay






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] LONGINT, my original proposal
Date: Sat, 9 Jan 2010 23:47:16 +0000








On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ef7bfcdb/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 01:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:05:23 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
Message-ID: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>


Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:12:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:12:06 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	, , <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>


 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:15:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:15:33 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>


Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000








 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From hosking at cs.purdue.edu  Sun Jan 10 01:21:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 19:21:38 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
Message-ID: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>

On 9 Jan 2010, at 19:15, Jay K wrote:

> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.

I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/2db04789/attachment-0001.html>

From mika at async.async.caltech.edu  Sun Jan 10 01:25:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 09 Jan 2010 16:25:52 -0800
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl> 
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
Message-ID: <20100110002552.683AA1A2078@async.async.caltech.edu>

Jay K writes:
>--_953e6126-a89e-4966-8f22-5ccff92e7117_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
> > I believe Rodney said something like "mixed operations follow from assig=
>nability"=3B
> > and from a language point of view=2C that may be true=2C just not from t=
>he point of view=3B
>
>I meant to say=2C not from the language implementation point of view.
>
>Again=2C if I can assign and then add=2C might as well just allow add?
>Ditto assign and index=2C assign and multiply=2C etc.
>

The problem is that it's sometimes ambiguous what the result type is.

If you want to get into this kind of mess, why don't you just program in C...

I think this area is probably one of the reasons some people *like* Modula-3.
We don't want to have to guess what an expression means... it should be obvious.
If there are "promotion rules" it's just not that obvious.  I'm reminded of one
time when I was missing a prototype in a C program.............. ok that story
could go on and on.

    Mika



From jay.krell at cornell.edu  Sun Jan 10 01:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:31:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	,,<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	,,<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	,,<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	, , <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>


I noticed unary plus doesn't seem to be valid for LONGINT.
That is fixed among my other diffs.

I understand it matters little to take this "algorithmic" approach to determining
if an AddExpr is valid. We haven't yet agreed it will even change from current,
though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
and then add it, or vice versa, why not just allow the direct addition?
Force the programmer through hoops so the code is much clearer?
Or too verbose?

 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 19:21:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 19:15, Jay K wrote:Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000

 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>



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

From rodney_bates at lcwb.coop  Sun Jan 10 02:29:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 19:29:32 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
	<COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
Message-ID: <4B492D7C.9070800@lcwb.coop>



Jay K wrote:
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?

Whether mixed comparison is allowed or an explicit conversion is coded
before comparing, the representation conversion of the value of p1 to
LONGINT will do a sign extension, because INTEGER and LONGINT are
both signed.  Or rather, all the builtin operations apply signed
interpretation.

If instead, you converted p1 to LONGINT via the Long.FromWord I proposed,
then it would be a zero extension.  This can only be done explicitly.

The comparison would always be done in 16 bits, unless you explicitly
converted the LONGINT operand.down to 8 first.

> 
> 
> And heck, shouldn't max + 1 already throw an exception?

This is a separate issue.  I have always been very skeptical about silently
ignoring overflow.  But all the questions about INTEGER and LONGINT really
hinge only on the question of when does an overflow occur, not what happens
when it does.

> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From jay.krell at cornell.edu  Sun Jan 10 03:05:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 02:05:24 +0000
Subject: [M3devel] IsAssignable
Message-ID: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>


Current:


PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if there is a common supertype
         and they have at least one member in common. *)
      IF IsEqual (Base(a), Base(b), NIL)
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

my proposed:




PROCEDURE IsAssignable (a, b: T): BOOLEAN =

  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;

  BEGIN

    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN

      RETURN TRUE;

    ELSIF IsOrdinal (a) THEN

      (* ordinal types:  OK if they have at least one member in common. *)

      IF GetBounds (a, min_a, max_a)

         AND GetBounds (b, min_b, max_b) THEN

        (* check for a non-empty intersection *)

        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;

        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;

        RETURN TInt.LE (min, max);

      ELSE

        RETURN FALSE;

      END;



Your proposed:

> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN

What's the point of checking the types? Given that they are both ordinal?
To restrict certain assignments?
Aren't the base types of any ordinal type either Int.T or LInt.T?
 So the check will always be true?
I have to check.


 - Jay

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

From rodney_bates at lcwb.coop  Sun Jan 10 03:34:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:34:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <4B493CBF.4080302@lcwb.coop>



hendrik at topoi.pooq.com wrote:
>> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

And:

 > Is it even necessary for a compiler to implement -128..127 as more than
 > one byte?


And:

 >> One thing that is very much needed in a language (not the only thing)
 >> is a type that always matches the implementation's native arithmetic
 >> size, which is most efficient.  If you don't distinguish this type,
 >> it becomes either impossible or horribly convoluted to define arithmetic
 >> so native machine arithmetic can be usually used where possible,
 >> but multi-word arithmetic will be used where needed.
 >
 > Yes.  You do need this type.  And you can even call it INTEGER.  But is
 > there any reason it cannot be a predefined subrange type of LONGINT?

When storing a value in a variable, the compiler can store subranges in fields
just big enough to hold the value range, or somewhere between that size and
the size of the base type.  Sometimes, like -128..127, it probably should store
it in a byte, and if the type is BITS 10 FOR 0..1023 and it's a field or array
element, it must store in exactly 10 bits.

But the question that creates trouble is not how many bits to store variables
in, but how many bits to do arithmetic in.  This affects when/whether overflows
can occur.  I define an overflow as a case where the mathematically correct
value is, for whatever reason, not what you get.  By "mathematically
correct", I mean in the system of (unbounded) integers, not a modular arithmetic.
The usual reason you don't get the correct value is that it won't fit in the
field you are doing arithmetic in.

What happens then is an orthogonal question.  Is there an exception?  Do we
have a code like a NaN?  Does it wrap modulo the word size? random bits?
But our problems with INTEGER and LONGINT have only to do with when does an
overflow happen.

In Modula-3 and with only INTEGER and its subranges, the arithmetic is always
done in the full range of INTEGER, even if the operands have subrange types.
This follows from the facts that:

1) The language defines (for the + example) only + (x,y: INTEGER) : INTEGER,
    but not any + operations on any subrange(s) of INTEGER.

2) The operands of + have no parameter mode specified, which means the mode
    is VALUE.

3) The rule for VALUE mode is that the actual parameter need only be assignable
    to the formal, not necessarily of the same type.

So if we have VAR a: [0..10];  VAR b: [20..30];, then the expression a+b
is evaluated by effectively doing the assignments x:=a, y:=b to the formals
x and y of +, before evaluating the +.  At the machine level, the compiler will
have to do a representation conversion of each subrange by expanding it to
a full integer, then do the add on these, with an INTEGER result.  And the
range of INTEGER then determines when overflows occur.  Moreover, a reasonable
implementation will choose the range of INTEGER to match the native machine
arithmetic of the target machine, which is the most efficient arithmetic
available.

This is about as near to tidy a way as possible to cope with the very untidy
fact that computer arithmetic on what we call "integers" is different from the
integers of mathematics.

Now suppose we need a larger-than-native range arithmetic for selected purposes.
If we try to do it by just having one integer type that is as large as anybody
could want and then let programmers choose a subrange othat happens
to match the target's native arithmetic, whenever that is enough range,
it gets a lot uglier.  Storing variables of this subrange in native words
will work fine.

But the size arithmetic is done in is the problem.  The only way to preserve
the relative tidiness  of the system of subranges would be to have every
subrange value's representation expanded to the largest size, then do
the arithmetic in that size.  But this loses the efficiency of native
arithmetic on _every_ operation, something we just can't afford.

So INTEGER has to have some special properties that arbitrary subranges
do not, namely that it is a size arithmetic is done in, if neither operand
has a larger range.  Having two distinct base types is a lot cleaner
and less misleading than trying to pretend that INTEGER is just a particular
case of a subrange.

This is messy.  But it's about the best we can do, given the difference
between efficient hardware "integer" arithmetic and the integer arithmetic
of mathematics.

Note that you can't fix this by trying to use the value range of where the
final expression result is to be assigned/passed/whatever.  Then the rules
just get a whole lot more complicated (for programmer and compiler alike),
and the cases where overflow can occur get a lot harder to anticipate.  And the
likelihood they are what is wanted is not good either.  You might have a
distant chance at this if an expression could have at most one operator,
but multiple operators and intermediate results make it a tar pit.




From hendrik at topoi.pooq.com  Sun Jan 10 03:57:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 21:57:56 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <20100110025755.GA17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
> Do you recall why CARDINAL is defined to behave like 
> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?

It's so that all CARDINALs are INTEGERs, presumably back when it was 
thought important to have only one base type on top of the type 
hierarchy.  I've always thought that was a mistake.

The simplest way to avoid that with LONGINT is to let programmers use 
only subranges of LONGINT, and to impose no limit on those subranges 
except for mamory capacity.

This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
either.

-- hendrik


From rodney_bates at lcwb.coop  Sun Jan 10 03:44:26 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:44:26 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <4B493F0A.7030500@lcwb.coop>



Jay K wrote:
> Uh, maybe all ordinal types that overlap in any values are assignable?
>  

Yes, exactly.  From 2.3.1:

   "A type T is _assignable_ to a type U if:
   .. <two other cases,> ..
   or T and U are ordinal types with at least one member in common."

For an _expression_ to be assignable to T, some additional things must
be checked, some of them at runtime.

>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = 
> Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127
> 
> either:
>   is true
>   or false
>   or raises an exception
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the 
> comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently 
> implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:04:13 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:04:13 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <20100110030412.GB17629@topoi.pooq.com>

On Sun, Jan 10, 2010 at 12:05:23AM +0000, Jay K wrote:
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?

Let's add -16_080000003L to +16_7ffffffff.
The sum should be 4.
What you propose will give overflow when assigning LONGINT to INTEGER.
You have to do the addition as LONGINT and then assign the sum to 
INTEGER.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 10 04:07:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:07:25 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <20100110030725.GC17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 07:21:38PM -0500, Tony Hosking wrote:
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> > Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> > However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> > FooExpr.m3 file, not just delegate to IsAssignable;
> > Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> > the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get 
> carried away thinking there'll be more.

There will be more, sooner or later.  Let's design for more, even if we 
don't implement it all right away.

-- hendrik



From rodney_bates at lcwb.coop  Sun Jan 10 03:54:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:54:51 -0600
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <4B49417B.7060806@lcwb.coop>

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
     denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
     designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
     to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a 
> common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:28:28 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:28:28 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B493CBF.4080302@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
	<4B493CBF.4080302@lcwb.coop>
Message-ID: <20100110032828.GD17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 08:34:39PM -0600, Rodney M. Bates wrote:
> 
> 
> But the question that creates trouble is not how many bits to store 
> variables
> in, but how many bits to do arithmetic in.  This affects when/whether 
> overflows
> can occur.  I define an overflow as a case where the mathematically correct
> value is, for whatever reason, not what you get.  By "mathematically
> correct", I mean in the system of (unbounded) integers, not a modular 
> arithmetic.
> The usual reason you don't get the correct value is that it won't fit in the
> field you are doing arithmetic in.
> 
> In Modula-3 and with only INTEGER and its subranges, the arithmetic is 
> always
> done in the full range of INTEGER, even if the operands have subrange types.
...
...
> 
> But the size arithmetic is done in is the problem.  The only way to preserve
> the relative tidiness  of the system of subranges would be to have every
> subrange value's representation expanded to the largest size, then do
> the arithmetic in that size.  But this loses the efficiency of native
> arithmetic on _every_ operation, something we just can't afford.
> 
> So INTEGER has to have some special properties that arbitrary subranges
> do not, namely that it is a size arithmetic is done in, if neither operand
> has a larger range.  Having two distinct base types is a lot cleaner
> and less misleading than trying to pretend that INTEGER is just a particular
> case of a subrange.
> 
> This is messy.  But it's about the best we can do, given the difference
> between efficient hardware "integer" arithmetic and the integer arithmetic
> of mathematics.
> 
> Note that you can't fix this by trying to use the value range of where the
> final expression result is to be assigned/passed/whatever.  Then the rules
> just get a whole lot more complicated (for programmer and compiler alike),
> and the cases where overflow can occur get a lot harder to anticipate.  And 
> the
> likelihood they are what is wanted is not good either.  You might have a
> distant chance at this if an expression could have at most one operator,
> but multiple operators and intermediate results make it a tar pit.
> 
> 

GOt that.  INTEGER is not a subrange of LONGINT because its arithmetic 
is different.

And the reason INTEGER has all its restrictions is simply to be 
able to use efficient machine arithmetic, and to make it clear that 
efficient machine arithmetic will be used.  This is why we don't 
expand "every subrange value's representation ... to the largest size, 
then do the arithmetic in that size."

But it is quite possible to performs operation on LONGINT subranges to 
produce results that are as long as necessary to be mathematically 
exact, because the whole point of LONGINT is to use it for numbers that 
do not fit the word size for the most efficient machine arithmetic.  
We're want to use subranges of LONGINT that match the requirements of 
an application, whether those subranges fit the most desirable machine 
word size or not.

-- hendrik



From hosking at cs.purdue.edu  Sun Jan 10 05:12:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:12:22 -0500
Subject: [M3devel] IsAssignable
In-Reply-To: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
References: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
Message-ID: <B816E60E-8AEB-4CD5-97C7-54FA0B235ED3@cs.purdue.edu>

Base type of an enumeration is itself!

On 9 Jan 2010, at 21:05, Jay K wrote:

> Current:
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if there is a common supertype
>          and they have at least one member in common. *)
>       IF IsEqual (Base(a), Base(b), NIL)
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> my proposed:
> 
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> 
> Your proposed:
> 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> 
> What's the point of checking the types? Given that they are both ordinal?
> To restrict certain assignments?
> Aren't the base types of any ordinal type either Int.T or LInt.T?
>  So the check will always be true?
> I have to check.
> 
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/42598f72/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:13:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:13:13 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <20100110025755.GA17629@topoi.pooq.com>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
	<20100110025755.GA17629@topoi.pooq.com>
Message-ID: <9CFA3CF7-98EE-430E-B0C3-8575FBF1A732@cs.purdue.edu>

That is a drastic (and I think fatal) departure from the spirit of the language.

On 9 Jan 2010, at 21:57, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
>> Do you recall why CARDINAL is defined to behave like 
>> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> It's so that all CARDINALs are INTEGERs, presumably back when it was 
> thought important to have only one base type on top of the type 
> hierarchy.  I've always thought that was a mistake.
> 
> The simplest way to avoid that with LONGINT is to let programmers use 
> only subranges of LONGINT, and to impose no limit on those subranges 
> except for mamory capacity.
> 
> This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
> either.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ddf9aa65/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:14:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:14:57 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, , ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, , ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
	<COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
Message-ID: <4440BF94-9372-4A3E-B0BF-03A5DFEA7E45@cs.purdue.edu>

On 9 Jan 2010, at 19:31, Jay K wrote:

> I noticed unary plus doesn't seem to be valid for LONGINT.
> That is fixed among my other diffs.
> 
> I understand it matters little to take this "algorithmic" approach to determining
> if an AddExpr is valid. We haven't yet agreed it will even change from current,
> though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
> and then add it, or vice versa, why not just allow the direct addition?
> Force the programmer through hoops so the code is much clearer?

Yes, clarity is important.

> Or too verbose?

Verbosity is sometimes valuable.  It spells things out.

> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 19:21:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
> 
> I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/5f1ae41d/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:16:37 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:16:37 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <CD3E8BA5-E655-4253-A4CE-52A3FECBE3C2@cs.purdue.edu>

Hear, hear!

On 9 Jan 2010, at 19:25, Mika Nystrom wrote:

> Jay K writes:
>> --_953e6126-a89e-4966-8f22-5ccff92e7117_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>>> I believe Rodney said something like "mixed operations follow from assig=
>> nability"=3B
>>> and from a language point of view=2C that may be true=2C just not from t=
>> he point of view=3B
>> 
>> I meant to say=2C not from the language implementation point of view.
>> 
>> Again=2C if I can assign and then add=2C might as well just allow add?
>> Ditto assign and index=2C assign and multiply=2C etc.
>> 
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious.  I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
>    Mika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/1f6e1958/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:22:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:22:44 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <4B49417B.7060806@lcwb.coop>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
	<4B49417B.7060806@lcwb.coop>
Message-ID: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>

That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.

For example:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

did not result in a run-time error.  I think I have fixed that now (commit to come).

But, even worse:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;

also does not give a run-time error.

The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!

On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
>> Index array by longint?
>> With runtime check that it is <= LAST(INTEGER)?
>>  Or really, with runtime bounds check against the array size.
>> Seems reasonable?
>> Aids the rd/wr change.
>> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>>   - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/ce43d885/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:33:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:33:57 -0500
Subject: [M3devel] Integer overflow
Message-ID: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>

So, in my experiments with range checking on integers, I have been playing with the overflow case:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

Should this fail at runtime with a range check error?

The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).

If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/aa4fb6ca/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 05:38:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:38:42 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <B808326A-8BD2-416B-8F7D-032FCA29E05E@cs.purdue.edu>

One take on this is that it certainly lets you check for overflow explicitly! ;-)

On the other hand, it seems unreasonable that you could end up with a CARDINAL holding a negative value!

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/abfc41b9/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 05:42:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 04:42:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
Message-ID: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>


There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?



That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
    designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
    to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
  Or really, with runtime bounds check against the array size.
 Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
   - Jay

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

From hosking at cs.purdue.edu  Sun Jan 10 05:45:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:45:29 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>

Even under the interpretation for INC that yields:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;

the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.

In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 



From hosking at cs.purdue.edu  Sun Jan 10 05:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:46:39 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
Message-ID: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>

I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.

On 9 Jan 2010, at 23:42, Jay K wrote:

> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/c1e26ed4/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 07:11:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 06:11:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
Message-ID: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;
c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay



Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu



I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
On 9 Jan 2010, at 23:42, Jay K wrote:There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?

That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
 Or really, with runtime bounds check against the array size.
Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
  - Jay


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

From hosking at cs.purdue.edu  Sun Jan 10 08:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 02:37:45 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
Message-ID: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>

Try to frame this in terms of assignability...

If the operators themselves were typed then there would be no problem.

But when they aren't we get into a real mess trying to remember what the promotion rules are.

On 10 Jan 2010, at 01:11, Jay K wrote:

> I don't think there is madness here.
> I believe the half range of CARDINAL helps avoid it.
> A confusing point in C is comparison that includes conversion
> is magnitude or sign preserving -- comparing int and unsigned.
> 
> Back to Modula-3:
> 
> a := b;
> c := a + d;
> 
> vs.
> 
> c := b + d;
> 
> 
> are different?
> Isn't that strange?
> 
> 
> Compare with
> a : = b;
> c := d[a];
> 
> and
> 
> c := d[b];
> 
> we have decided they are the same, among others.
> 
> 
> There's something about "kinda sorta transitive" here.
> Or, like, "why should I have to move values through temporaries in some
> cases but not others?"
> 
>  - Jay
> 
> 
> 
> Subject: Re: [M3devel] index array by longint?
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:46:39 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
> 
> On 9 Jan 2010, at 23:42, Jay K wrote:
> 
> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 08:58:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 07:58:56 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>, ,
	<4B49417B.7060806@lcwb.coop>, ,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>,
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>, ,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>,
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>,
	<3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
Message-ID: <COL101-W39FE16CBEE45212C4E6979E66E0@phx.gbl>


It is easy to frame in terms of assignability?

  a + b is legal if a is assignable to b, or b is assignable to a  

 

If you don't allow INTEGER := LONGINT,

then you can say, like:

 

a + b is legal if a is assignable to b or b is assignable a (or both);

if a and b are of different type, and only one is assignable to the

other, then the result type is that of the assignable-to type.

 

If INTEGER := LONGINT, then I'm not sure how to formally

define the result. Something informal:

a + b is legal if a or b is assignable to the other

the result type is the "larger" or "wider" type -- whatever that means;

However, I think there is an easy enough to define set of rules.

It varies for each operator though.

 

Basically, first, the notion of "larger" or "wider" isn't

all that unscientific. It needs a little honing though;

 

 

a + b is legal if a is assignable to b or b is assignable to a (or both).

If a and b are of the same type, that is the result type.

If a and b are of different types, but one of their types can

  represent without loss all the values of the other type,

  then that is the result type.

If a and b are of different types, and neither type can represent

  all of the values of the other type, then the result type is

   INTEGER if it can represent all the members of the types of a and b,

   else LONGINT.

 

 

The result type is stated in terms of the input types.

Not in terms of the output range.

This is a general fact of life with addition anyway.

The result of adding two integers is an integer, even though integer

cannot hold the output range.

 

 

I have a strong suspicion that we would be more satisified

with our rules if overflow checking was present.

 

 

Heck, maybe we'd have something wierd where INTEGER + INTEGER

actually yielded LONGINT, but then LONGINT is assignable to INTEGER?

The overflow check would actually be at the assignment/narrowing?

Heck, it's not like double precision arithmetic is even so expensive?

 

 

What do you mean by, reworded, "the operators aren't typed"

 

 

- Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 02:37:45 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




Try to frame this in terms of assignability...


If the operators themselves were typed then there would be no problem.


But when they aren't we get into a real mess trying to remember what the promotion rules are.


On 10 Jan 2010, at 01:11, Jay K wrote:


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;

c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay





Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu


I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.





On 9 Jan 2010, at 23:42, Jay K wrote:

There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.


For example:


VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;


did not result in a run-time error.  I think I have fixed that now (commit to come).


But, even worse:


VAR s: CARDINAL := LAST(INTEGER);

BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;


also does not give a run-time error.


The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!



On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:

Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

 Or really, with runtime bounds check against the array size.

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

  - Jay



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

From jay.krell at cornell.edu  Sun Jan 10 09:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 08:55:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>,
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63918AA105D02C46D86E5AE66E0@phx.gbl>


> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.


You were using a bad compiler or at least bad switches:

C:\>type t.c


void F1()
{
 F2();
}

C:\>cl -c -W4 -WX t.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
t.c(5) : error C2220: warning treated as error - no 'object' file generated
t.c(5) : warning C4013: 'F2' undefined; assuming extern returning int

 

and C++ always errors.


 - Jay

 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant 
> Date: Sat, 9 Jan 2010 16:25:52 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >--_953e6126-a89e-4966-8f22-5ccff92e7117_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> > > I believe Rodney said something like "mixed operations follow from assig=
> >nability"=3B
> > > and from a language point of view=2C that may be true=2C just not from t=
> >he point of view=3B
> >
> >I meant to say=2C not from the language implementation point of view.
> >
> >Again=2C if I can assign and then add=2C might as well just allow add?
> >Ditto assign and index=2C assign and multiply=2C etc.
> >
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
> Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5f4fff7d/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 10:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>


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/d57d8efd/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 10:52:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:52:32 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <COL101-W1505A74E8F75378C40431DE66E0@phx.gbl>


Well, I have to take that back.

I'm reading Rodney's proposal.

  https://mail.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.txt 

 

Notable so far:

  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.

  He defines ORD as possibly returning LONGINT. Which breaks my assertion below.

  But he doesn't allow indexing an array by LONGINT.

  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?

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?



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/e9197775/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 11:26:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken
Message-ID: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>


Tony, with the recent changes:

 

1)

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...


 

2) If I fix that by removing cas/casp more completely:


 

C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3

(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>

 

looks like maybe an off by one problem?

Since the pointer is near valid memory?

Any ideas?

I'll poke around.

 

 

Going back to the release branch versions fixes this.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/99d33760/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 11:38:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:38:52 +0000
Subject: [M3devel] m3front broken
In-Reply-To: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
References: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
Message-ID: <COL101-W56F490C4603C9ADBA56B01E66E0@phx.gbl>


nevermind, I see the problem, fix shortly

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken



Tony, with the recent changes:
 
1)
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...

 
2) If I fix that by removing cas/casp more completely:

 
C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3
(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>
 
looks like maybe an off by one problem?
Since the pointer is near valid memory?
Any ideas?
I'll poke around.
 
 
Going back to the release branch versions fixes this.
 
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/82998d8b/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 12:29:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 11:29:21 +0000
Subject: [M3devel] yet another longint rendition -- just mutual
 assignability, result is very tedious
Message-ID: <COL101-W345041876AF820EABD01D9E66E0@phx.gbl>


These diffs show what you can do if you merely allow assignability between

integer and longint, both ways.

  The compiler diff is included.

This is just what it takes to get libm3 to compile, having

changed a few integer to longint.

It's pretty awful in my opinion.

No changed made outside m3front and libm3, and there

  would surely be "many" needed, like the first set of diffs I sent.

  (I think those were written with no compiler change at all.)

 

I believe people wanted to see what this looks like.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment-0001.txt>

From hosking at cs.purdue.edu  Sun Jan 10 15:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 09:30:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>

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 | Mobile +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/280301a9/attachment-0001.html>

From rcolebur at SCIRES.COM  Sun Jan 10 21:00:58 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Sun, 10 Jan 2010 15:00:58 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100110051218.2F3C42474001@birch.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>

I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


From hosking at cs.purdue.edu  Sun Jan 10 21:23:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:23:28 -0500
Subject: [M3devel] Integer literals
Message-ID: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>

One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).

It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)

Here's how things would work with subrange types.

A subrange written as currently

[lo .. hi]

would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.

A subrange with base type LONGINT would be written explicitly:

[lo .. hi] OF LONGINT

The constants lo/hi must both be in range for LONGINT.

We could also support the form:

[lo .. hi] OF INTEGER

just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.

Here we are allowing the programmer to state explicitly what the base type of the subrange should be.

Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Sun Jan 10 21:34:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:34:59 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W6B928C524DCF7E4AF027AE66E0@phx.gbl>


> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 

 

Have you seen the resulting diffs?

 

 

Would we just say, that the initial rd/wr interface was so wrong, that there

is a lot of "incorrect" code, so the ugly diff is the result?

That newer code wouldn't be so initially wrong, so would remain not so ugly?

Maybe.

 

 

VAR a:LONGINT;

      b:INTEGER;

INC(a, b);

 

 

doesn't that make perfect sense to even the most casual reader?

Many current proposals don't allow it.

  Though Randy's does allow it.

 

 

Indexing by LONGINT is also trivial.

Just do the usual range check and go.

Indexing by INTEGER also has a range check.

One difference would be that a subrange of LONGINTs that are all greater than LAST(INTEGER) could be a stack error, just as some indexing by INTEGER subranges can also be a static error (e.g. if the array element size times the all the elements of the subrange or enum are larger than the address space).

 

 

 > We need correct and maintainable software, especially at the systems level

 

Nearly all systems level software is written in a language or languages that manage to zero extend or sign extend integers to wider integers.

The Modula-3 compiler/runtime/garbage collector is the biggest exception I can think of, but so far it can't really handle large files.

 

 

 - Jay

 
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sun, 10 Jan 2010 15:00:58 -0500
> Subject: [M3devel] the LONGINT proposal
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1. LONGINT should be a distinct type different from INTEGER.
> 
> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 3. Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake. I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions. We need correct and maintainable software, especially at the systems level. Whatever is decided about LONGINT, we need to keep to the original design tenants of the language. 
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type. That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance. Programs should be written to run forever or until their job is completed or they are commanded to stop. 
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal. Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all? To me this keeps the discussion focused rather than the many different emails. Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects. Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing. Who should be involved in such votes? Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/a6f5921b/attachment-0001.html>

From hendrik at topoi.pooq.com  Sun Jan 10 21:38:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 15:38:32 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <20100110203832.GA16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

And what would be the type of 2000000000 + 2000000000?  Overflow because 
2000000000 is an INTEGER?
Whereas 3000000000 + 3000000000 would end up being LONGINT?

The only solutions I see for this problem are:

(a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

or

(b) Let operations on integers automatically produce values of 
sufficiently large ranges to be able to contain the results.

(b) seems to be incompatible with the use of the most efficient integer 
operations on a machinem=, which are of fixed bit-width.

(a) is what's proposed for the LONGINT extension.

It would be possible to combine (a) and (b), using (b) only for LONGINT, 
but you seem to be dead set against this.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Sun Jan 10 21:42:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:42:55 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:

> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn

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

From jay.krell at cornell.edu  Sun Jan 10 21:43:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:43:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>


Seems fine either way.

Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
 

 

And then, if that is true, mixing should be allowed..widen any constituents

in an expression to the widest type.

 

 

I realize mixing floating point and integer is less natural, nothing about

floating point is natural really, though on a 32bit platform

LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 

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

From jay.krell at cornell.edu  Sun Jan 10 21:45:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:45:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
Message-ID: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>


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/e5dd2ebf/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 21:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:48:21 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100110203832.GA16635@topoi.pooq.com>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<20100110203832.GA16635@topoi.pooq.com>
Message-ID: <63BBCB94-EB03-45FE-B13A-4AC4F273E538@cs.purdue.edu>

On 10 Jan 2010, at 15:38, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
>> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> 
>> Here's how things would work with subrange types.
>> 
>> A subrange written as currently
>> 
>> [lo .. hi]
>> 
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> 
>> A subrange with base type LONGINT would be written explicitly:
>> 
>> [lo .. hi] OF LONGINT
>> 
>> The constants lo/hi must both be in range for LONGINT.
>> 
>> We could also support the form:
>> 
>> [lo .. hi] OF INTEGER
>> 
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> 
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
>> 
>> Literals would be be range-checked when used as arithmetic operands or 
>> in assignment, with compile-time checks that they are in range 
>> ("compatible") with the types of the other operands or the destination 
>> of the assignment.
> 
> And what would be the type of 2000000000 + 2000000000?  Overflow because 
> 2000000000 is an INTEGER?

Constant expressions would retain their "value" nature so long as the expression can be computed at compile-time without overflow up to the precision of LONGINT.

> Whereas 3000000000 + 3000000000 would end up being LONGINT?
> 
> The only solutions I see for this problem are:
> 
> (a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

This is the current implementation.  0 and 0L are the same value as INTEGER and LONGINT.

> 
> or
> 
> (b) Let operations on integers automatically produce values of 
> sufficiently large ranges to be able to contain the results.

Problematic because it imposes expensive operations on natural integers.

> (b) seems to be incompatible with the use of the most efficient integer 
> operations on a machinem=, which are of fixed bit-width.

Right.

> (a) is what's proposed for the LONGINT extension.

Not just proposed.  Implemented now for over a year.

> It would be possible to combine (a) and (b), using (b) only for LONGINT, 
> but you seem to be dead set against this.

Indeed, I am.

> 
> -- hendrik
> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 



From hosking at cs.purdue.edu  Sun Jan 10 21:51:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:51:17 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
Message-ID: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>

No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.

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

> Seems fine either way.
> Assignability gives us, which we were missing before, VAR a:LONGINT := 0;
> 
> 
>  > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
>  > do have incompatible value representations).
>  
>  
> I keep seeing this and am surprised.
> Isn't it the case that REAL <= LONGREAL <= EXTENDED
> in terms of precision and range?
> LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
> EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
>  
>  
> And then, if that is true, mixing should be allowed..widen any constituents
> in an expression to the widest type.
>  
>  
> I realize mixing floating point and integer is less natural, nothing about
> floating point is natural really, though on a 32bit platform
> LONGREAL can hold all INTEGERS..
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 15:23:28 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] Integer literals
> 
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> 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
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sun Jan 10 21:52:16 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:52:16 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <ED3D3FD1-0327-4B52-9559-864AD7BEEE52@cs.purdue.edu>

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-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 21:53:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:53:12 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>


(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-0001.html>

From jay.krell at cornell.edu  Sun Jan 10 22:00:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 21:00:15 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>,
	<95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
Message-ID: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>


Hm..these hardware conversions..yeah they do exist.

But they are fast and lossless.

Depending on the instruction set, they aren't even avoidable.

  e.g. x86 I think usually does double arithmetic.

        68K maybe extended.

But to be clear, they tend to be a single instruction each, load or move.

Every INTEGER can be represented in a LONGINT, by sign extension.

Every REAL can be represented as LONGREAL. 

And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

 I was surprised by that actually, stepping through some hash table code,

   but it is just the way it is. There's I guess no integer division and

   the floating point is done with 64 or more bits of precision, so it works.

 

 

As long as conversion is fast and lossless..?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:51:17 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Integer literals




No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.


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

Seems fine either way.
Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not); 
 
And then, if that is true, mixing should be allowed..widen any constituents
in an expression to the widest type.
 
 
I realize mixing floating point and integer is less natural, nothing about
floating point is natural really, though on a 32bit platform
LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 


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

From hosking at cs.purdue.edu  Sun Jan 10 22:06:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:06:06 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
Message-ID: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>

Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.

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

> (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/a37318d7/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 10 22:08:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:08:18 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
References: <20100110164332.0c09a257.dimonax@att.net>
Message-ID: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>

This guy is trying to subscribe to m3devel.  Can someone help him?

Begin forwarded message:

> From: Chris <dimonax at att.net>
> Date: 10 January 2010 16:43:32 EST
> To: Tony Hosking <hosking at cs.purdue.edu>
> Subject: Re: CM3 development Inquiry.
> 
> On Fri, 8 Jan 2010 13:01:21 -0500
> Tony Hosking <hosking at cs.purdue.edu> wrote:
> 
>> Did you manage to subscribe?
> 
> I put in another subscription request just after your previous reply, and I'm still waiting. I wonder if the confirmation e-mail is getting through. Nonetheless, I'll keep trying.
> 
> 
> -- 
> Chris <dimonax at att.net>

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

From jay.krell at cornell.edu  Sun Jan 10 23:02:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:02:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	,,<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	,,<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	, , <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
Message-ID: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>


Is it really just me who finds the choices all fairly obvious?

You do the math in the wider type. Is that really surprising?

  Am I just, like, brain washed with years of assumptions?

That's what Rodney's proposal said.

In the case of MOD and DIV, you can pause for thought

and maybe make them return a narrower type, but

if you just want to be simple and stay wide, that's ok.

 

 - Jay


 


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




Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.


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

(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      +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      +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/085ab3d2/attachment-0001.html>

From hendrik at topoi.pooq.com  Sun Jan 10 23:11:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 17:11:37 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
Message-ID: <20100110221137.GB16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> 
> And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

Just for clarity, do you mean the Itanium here?

-- hendrik


From jay.krell at cornell.edu  Sun Jan 10 23:22:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:22:00 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100110221137.GB16635@topoi.pooq.com>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>,
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>,
	<20100110221137.GB16635@topoi.pooq.com>
Message-ID: <COL101-W30198A34B16863265449FCE66E0@phx.gbl>


Yes of course.

  echo %PROCESSOR_ARCHITECTURE%  

 

 - Jay


 
> Date: Sun, 10 Jan 2010 17:11:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> > 
> > And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?
> 
> Just for clarity, do you mean the Itanium here?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/0fab823d/attachment-0001.html>

From jayk123 at hotmail.com  Mon Jan 11 05:58:13 2010
From: jayk123 at hotmail.com (jayk123 at hotmail.com)
Date: Sun, 10 Jan 2010 20:58:13 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, , ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, , ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
	<COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
Message-ID: <BLU0-SMTP21D313FA40787E6A124A47E66D0@phx.gbl>

To repeat myself: you can reason about + via assignability, sort of.  
Of the two input types, you see which is assignable to which, and  
conceptually assign the inputs to two temporaries of that type.  
Assuming longint *not* assignable to integer, done. If it is  
assignable, pick the type that can guaranteeably hold all values of  
the two inputs.

In terms of implict vs. explict..I fallback to my usual claim: what  
people already probably think of as simple very often is not. The "red  
flag" of "complexity", I find, is raised very quickly, when people  
just don't like something.

I think there might be another way though. What if rd/wr users had to  
change *lots* of types from integer and cardinal to longint..and index  
by longint allowed? Maybe maybe that'd have a "pleasant" outcome. But  
still, given that NUMBER returns CARDINAL, still must end up mixing  
somehow, either via implicit or explicit conversion/assignment.


Btw are C's rules really so different or complicated? Don't they look  
like "assignability" too? The one problem I know of is in comparison  
if "full range" unsigned types with signed types. There are two  
equally good/bad options: I think called "sign preserving" and  
"magnitude preserving" aka "magnitude losing" and "sign losing".  
Either a large positive number becomes negative or a negative number  
becomes a large positive. I believe avoidance of this problem is why  
CARDINAL is "half range".


  - Jay (phone)

On Jan 10, 2010, at 2:02 PM, Jay K <jay.krell at cornell.edu> wrote:

> Is it really just me who finds the choices all fairly obvious?
> You do the math in the wider type. Is that really surprising?
>   Am I just, like, brain washed with years of assumptions?
> That's what Rodney's proposal said.
> In the case of MOD and DIV, you can pause for thought
> and maybe make them return a narrower type, but
> if you just want to be simple and stay wide, that's ok.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 16:06:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>
> Consider the following:  + is overloaded to perform both INTEGER and  
> LONGINT addition.  When invoking + we choose the appropriate  
> operation based on its operand types.  Why do you think it is  
> reasonable to assume that LONGINT+INTEGER should perform LONGINT +  
> instead of INTEGER +?  It is an *arbitrary* choice that you make  
> which should give us pause in imposing that arbitrary choice in the  
> language because it violates the principle of least surprise.  Don't  
> impose arbitrary choices that may confuse the programmer.
> Prohibiting mixed-operand operations prevents bugs arising when one  
> programmer inadvertently assumes that his personal arbitrary choice  
> is not the one that the language actually implements.
>
> Assignability is different in that the assignment operation is  
> unambiguously tied to the type of its left-hand-side.  Assignment  
> forces a value into a particular representation -- that of the pre- 
> allocated "storage" designated by the LHS.  If the value is not  
> compatible with that representation then we can raise a run-time  
> error.
>
> On 10 Jan 2010, at 15:53, Jay K wrote:
>
> (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 
>       +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 
>       +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/b9b6e1d0/attachment-0001.html>

From rcolebur at SCIRES.COM  Mon Jan 11 07:11:52 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 01:11:52 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:


I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/7e2517c3/attachment-0001.html>

From wagner at elegosoft.com  Mon Jan 11 10:51:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 10:51:34 +0100
Subject: [M3devel] Truncation problem fixed,
	was: Re:  another longint	variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <20100111105134.4zr9fs0lc00wsok8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> [replacing periods with semicolons to avoid truncation..]

Mike has made a change some days ago that should fix the truncation
of mails at certain periods. If anybody experiences this again,
you should let him know.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Mon Jan 11 11:52:57 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 11:52:57 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
Message-ID: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> This guy is trying to subscribe to m3devel.  Can someone help him?
>
> Begin forwarded message:
>
>> From: Chris <dimonax at att.net>
>> Date: 10 January 2010 16:43:32 EST
>> To: Tony Hosking <hosking at cs.purdue.edu>
>> Subject: Re: CM3 development Inquiry.
>>
>> On Fri, 8 Jan 2010 13:01:21 -0500
>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>
>>> Did you manage to subscribe?
>>
>> I put in another subscription request just after your previous   
>> reply, and I'm still waiting. I wonder if the confirmation e-mail   
>> is getting through. Nonetheless, I'll keep trying.

Unfortunately the address does not work:

This is the mail system at host mx0.elegosoft.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
     521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
     Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
     command)

If he really wants to join, he needs another mail address, but I cannot
tell him that.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Jan 11 13:17:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:17:56 +0000
Subject: [M3devel] some more "crazy" proposals
Message-ID: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>


1) change file/rd/wr sizes to be BigInteger.T

and/or

2) Introduce SeekL, IndexL, StatusL, etc.
default implementation calls Seek/Index/Status and does checked truncation.
Clients gradually port to LONGINT or BigInteger.T.
Completely source compatible.


3) BigInteger.T is The multiple-INTEGER precision type??
No compiler/language change??


I might try these out, and then go the extra step and port the file dialog to avoid the exception..
see what it all looks like...

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/3b5d2620/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jan 11 13:14:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:14:06 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>


Randy I won't cover everything but on some of these matters you are not alone.
In particular, INTEGER and LONGINT are different types, in the current
implementation, and I think in all proposals.


It is quite striking how the current implemtation makes them completely different.
However many proposals do allow assignability which does make it a bit
blurry to a user what different types mean.
One thing that I bet will always remain though, is that VAR parameters of INTEGER
cannot "bind" to LONGINT, and vice versa.
The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
without a cast, even if int and long are both 32bit.
That is, in C and C++, int and long are different types, just as in Modula-3,
INTEGER and LONGINT are different types.


Which goes to show one of my agendas: C isn't as bad as people think.
It isn't safe, granted. There is no formal module system, but
people are actually usually rigorous in their use of the informal system.
As well, one of the goals I have espoused is that UNSAFE Modula-3 be
not more unsafe than C. Which is why I don't like procedures to return ADDRESS
and expect every caller to cast/loophole -- that is just more unsafe than things should be.


I have some familiarity with 8 and 16 bit integers.
We can perhaps claim that there is a hypothetical system
with 16bit INTEGER and 32bit LONGINT?
And that our proposals do work in such a system?


There is some disagreement floating around apparently on even what
to call the INTEGER <=> LONGINT conversions.
Currently ORD converts to INTEGER.
Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.


I believe I saw a proposal that the converesions be named after the type:
  INTEGER(expr), LONGINT(expr).

That kind of smacks to me of "too hard to search for".

Here is a crazy verbose suggestion:
 LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

and allow it in safe modules?
At least it is existing syntax with roughly the desired meaning,
except that LOOPHOLE is and sounds unsafe.

CAST(expr, type)
CONVERT(expr, type)
?

I'm just making up words here of course.
VAL or ORD seem sufficient, esp. if you can specify the type.

gotta go,
 - Jay


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 01:11:52 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal
















Tony:

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope (see below).  Using differently named conversion operators would
lesson some of the ugliness of ORD/VAL and also prevent confusion with their
intended use as enumeration/INTEGER conversions.

 

Read on for the long-winded version?

 

According to NELSON (SPwM3), ORD and VAL convert between enumerations
and INTEGERs, and INTEGER is all integers represented by the implementation. 
So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit
processors.  

 

Today we see 32-bit and 64-bit processors as predominant, but I
remember the day when 8-bit and 16-bit were the norm.  Someday we may see
128-bit processors as the norm.  

 

(I?ve been cleaning up my basement office and ran across a
box of 8-inch floppy disks.  When I showed them to my daughter she
understood the meaning of ?floppy? as opposed to the rigid 3.5-inch
floppies of today.  But, I digress.)

 

On a 64-bit processor, this whole idea of LONGINT as 64-bits then
becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine
(assuming we had an implementation for one) the native word size would be less
than the 32-bits we seem to take for granted now.

 

One problem is that one doesn?t really know the range of
LONGINT unless we define it as some number of bits.  Rodney?s
proposal simply stated that LONGINT was at least as big as INTEGER but could be
larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same
in terms of implementation?, whereas on a 32-bit the LONGINT would have an
additional 32-bits more than INTEGER?  What about a 128-bit machine?

 

I say all this to point out the obvious, namely that LONGINT and
INTEGER are different types.  

 

Therefore, IMO the language must make it clear how these
different types interact.

 

I would argue that 

   x: LONGINT := 23;

is wrong!  The programmer should have to write

   x: LONGINT := 23L;

instead.

 

A subrange of LONGINT would be written as [23L..4200L] and would
be a different type than the integer subrange [23..4200] even though the ranges
are identical.

 

Likewise, IMO mixed arithmetic with the compiler deciding what
to do is wrong.  The programmer should have to explicitly write
conversions to a common type for arithmetic.

 

I have no problem with extending the existing operators to deal
with LONGINT; it?s just that the result should be LONGINT.

Given x: LONGINT := 49L;

   INC(x) yields 50L

   INC(x, 3L) yields 52L

      note that INC(x, 3) would be a
syntax error since 3 is an INTEGER and x is a LONGINT

   (x + 20L) yields 69L

      note that (x + 20) would be a
syntax error since 20 is an INTEGER and x is a LONGINT

   LAST(LONGINT) yields a LONGINT

 

Now that I think about it more, I have a problem using ORD/VAL
for the conversion since NELSON defines these as converting between enumerations
and INTEGERs, and since LONGINT is a different type than INTEGER and quite
possibly has a greater range than INTEGER.  Is the proposal to also allow
enumerations to use the range of LONGINT ?  Enumerations currently are
defined as having a range no greater than INTEGER.  To extend them to
LONGINT would lose the obvious performance benefits of keeping them same range
as native INTEGER.

 

Maybe we should invent new names for the conversions between
INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These
are probably bad names, but I use them below simply to illustrate (feel free to
come up with better names):

   Given longInt: LONGINT;   and  
int: INTEGER;

   int := DEMOTE(longInt); would perform the
conversion from LONGINT to INTEGER and would give a runtime range check error if
longInt is too big/small to fit in an INTEGER.

   longInt := PROMOTE(int) would always succeed in
performing the conversion from INTEGER to LONGINT but would make the conversion
explicit

   int + DEMOTE(longInt) would yield an INTEGER result
with all arithmetic being done in the range of INTEGER

   longInt + PROMOTE(int) would yield a LONGINT result
with all arithmetic being done in the range of LONGINT

 

Now if we were to allow checked assignability (as Tony is
leaning toward), I think we begin to get on the slippery slope.  How far
do we extend this to the point that it is not clear in the expression of the
code what is happening?  If I can write ?int := longInt;? why
not ?int := 23L;? and why not ?int := longInt + 57;?
and is this different than ?int := longInt + 57L;?? etc. etc.

 

I agree the ORD/VAL syntax is ugly, so that is another reason
(besides them applying to enumerations only) we should use different names for
the INTEGER/LONGINT conversions.

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope.  Using differently named conversion operators would lesson some of
the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER
conversions.

 

Regards,

Randy Coleburn

 





From: Tony Hosking [mailto:hosking at cs.purdue.edu]


Sent: Sunday, January 10, 2010 3:43 PM

To: Randy Coleburn

Cc: m3devel

Subject: Re: [M3devel] the LONGINT proposal





 



Hi Randy,





 





As someone who has actually written
Modula-3 programs for a living your opinions are always highly valued.  I
agree with you in principle and aims, except for requiring overflow to be a
checked run-time error.  The language definition already has a mechanism
for handling this in the require FloatMode interface.  It is not something
that the compiler should be involved in.  I also just now raised
a question about perhaps having integer literals adapt their type to the
context in which they are used.





 





I should point out that the current
mainline implementation does exactly what you propose (except overflow
checking).  It captures the fundamental spirit of Rodney's proposal but
does not permit mixed arithmetic or assignment.  Can I ask what your issue
is w.r.to checked assignability?  I am still leaning in favor.  It is
not much different from assignment from an INTEGER to a subrange, which
requires no explicit check, though of course there is a run-time range check.  Having
programmers explicitly write:





 





x: INTEGER := ORD(longint,
INTEGER);





 





seems unnecessary when they could
just write





 





x: INTEGER := longint;





 









This
is similar in spirit to:









 





x: [lo..hi] := integer;





 





 







On 10 Jan 2010, at 15:00, Randy
Coleburn wrote:











I've been trying to follow along on
this topic.



Here are my thoughts:



1.  LONGINT should be a distinct type different from INTEGER.



2.  There should be no mixed arithmetic between the types.  The
programmer must code conversions using ORD/VAL to make explicit the intention.
 Don't rely on some ill-remembered built-in conversion rule.



3.  Overflow should be a checked run-time error, not silently wrapped
around.



4.  WRT assignability, I think explicit conversions should be used.



These statements may make me unpopular with some who don't like to type much,
but I've always hated the tradeoff of understandability for brevity in
expression.



The important thing is not how fast we can type up a program, it is rather how
hard is it to make a mistake.  I think the spirit of Modula-3 is that the
language makes you a better programmer by forcing you to make your intentions
explicit rather than relying on the compiler to infer your intentions.  We
need correct and maintainable software, especially at the systems level.
 Whatever is decided about LONGINT, we need to keep to the original design
tenants of the language.  



And yes, I do think we need a LONGINT type, not just to deal with large file
sizes.



But even for long-lived readers/writers, whatever type you choose for the index
will eventually be insufficient, so you have to code for the possibility that
the range of the long lived reader/writer exceeds the range of your index type.
 That is just good programming.



I think sometimes that the new generation of programmers has been warped by
what I call the "Microsoft Mentality" where you must expect that you
need to reboot/restart every so often to maintain proper performance.
 Programs should be written to run forever or until their job is completed
or they are commanded to stop.  



As "we" begin to converge on the design changes, I like having
something concrete to look at, ala Rodney's proposal.  Can we take that
and keep tweaking it in these emails until we reach a final version acceptable
to all?  To me this keeps the discussion focused rather than the many
different emails.  Thus, what I am trying to say is put forth a numbered
proposal and each subsequent email must show adjustment to that proposal rather
than just a bunch of emails discussing various aspects.  Perhaps we should
vote on each proposed change, then decide to call a final vote on the whole
thing.  Who should be involved in such votes?  Right now the main
persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.



My two cents.



Regards,

Randy Coleburn





 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/62da63a9/attachment-0001.html>

From hendrik at topoi.pooq.com  Mon Jan 11 17:23:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Mon, 11 Jan 2010 11:23:01 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <20100111162301.GA23072@topoi.pooq.com>

On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.
> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
> 
> 
> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).
> 
> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
> 
> and allow it in safe modules?
> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.
> 
> CAST(expr, type)
> CONVERT(expr, type)
> ?
> 
> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

NARROW?  WIDEN?

And TRUNCATE if you really want to chop off the high-order bits without 
overflow check?

-- hendrik


From hosking at cs.purdue.edu  Mon Jan 11 18:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:12:25 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
Message-ID: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>

Actually, that diagnostic indicates that scc-mailrelay.att.net is blocking messages from the Elegosoft mail server (it is blacklisted!).

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 11 Jan 2010, at 05:52, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> This guy is trying to subscribe to m3devel.  Can someone help him?
>> 
>> Begin forwarded message:
>> 
>>> From: Chris <dimonax at att.net>
>>> Date: 10 January 2010 16:43:32 EST
>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>> Subject: Re: CM3 development Inquiry.
>>> 
>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>> 
>>>> Did you manage to subscribe?
>>> 
>>> I put in another subscription request just after your previous  reply, and I'm still waiting. I wonder if the confirmation e-mail  is getting through. Nonetheless, I'll keep trying.
> 
> Unfortunately the address does not work:
> 
> This is the mail system at host mx0.elegosoft.com.
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> For further assistance, please send mail to postmaster.
> 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> 
>                   The mail system
> 
> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>    command)
> 
> If he really wants to join, he needs another mail address, but I cannot
> tell him that.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/56b71c66/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 11 18:32:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:32:13 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:

> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.

>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.

>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 

Correct.  The current implementation treats them as completely separate.

>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.

This is what we currently implement.

>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.

>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.

>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.

>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.

>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...

>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/b7fdda06/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 11 18:42:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:00 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <90520DA3-BD5C-494F-875B-F77910088E0B@cs.purdue.edu>

On 11 Jan 2010, at 07:14, Jay K wrote:

> Randy I won't cover everything but on some of these matters you are not alone.
> In particular, INTEGER and LONGINT are different types, in the current
> implementation, and I think in all proposals.
> 
> 
> It is quite striking how the current implemtation makes them completely different.
> However many proposals do allow assignability which does make it a bit
> blurry to a user what different types mean.
> One thing that I bet will always remain though, is that VAR parameters of INTEGER
> cannot "bind" to LONGINT, and vice versa.
> The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
> without a cast, even if int and long are both 32bit.
> That is, in C and C++, int and long are different types, just as in Modula-3,
> INTEGER and LONGINT are different types.

But C has a much looser design philosophy than Modula-3.  We should not compromise Modula-3 by veering towards C.

> Which goes to show one of my agendas: C isn't as bad as people think.
> It isn't safe, granted. There is no formal module system, but
> people are actually usually rigorous in their use of the informal system.
> As well, one of the goals I have espoused is that UNSAFE Modula-3 be
> not more unsafe than C. Which is why I don't like procedures to return ADDRESS
> and expect every caller to cast/loophole -- that is just more unsafe than things should be.
> 
> 
> I have some familiarity with 8 and 16 bit integers.
> We can perhaps claim that there is a hypothetical system
> with 16bit INTEGER and 32bit LONGINT?
> And that our proposals do work in such a system?
> 
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.

I suppose ORD could convert to the underlying type, but given the intention that it be used to convert from an enumeration to an integer, then I think hardwiring it to return INTEGER is OK, since no enumeration will/should contain more elements than can be indexed by an INTEGER.  On the other hand, I see no real problem if ORD(longint) returns LONGINT.  It just means you have to do one more step to get an integer using VAL.

> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.

Yes, this is what we also currently implement.

> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).

I proposed that originally, but then decided that reusing VAL seemed much more intuitive.  After all, we are asking to treat a typed expression in one domain as a *value* in some other type domain, so long as the value has a representative in that domain.

> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

LOOPHOLE implies an unsafe operation!

> and allow it in safe modules?

Yuck!!!!!!!!!!!!!!!!

> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.

I vote we stick with VAL.

> CAST(expr, type)
> CONVERT(expr, type)
> ?

Yuck!


> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

Agreed!

> 
> gotta go,
>  - Jay
> 
> 
> From: rcolebur at SCIRES.COM
> To: hosking at cs.purdue.edu
> Date: Mon, 11 Jan 2010 01:11:52 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] the LONGINT proposal
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/b3339574/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 11 18:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:34 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100111162301.GA23072@topoi.pooq.com>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
	<20100111162301.GA23072@topoi.pooq.com>
Message-ID: <06DE4262-4D34-4908-9367-C277E1556416@cs.purdue.edu>

We have Word.T and Long.T to handle masking the higher-order bits.

On 11 Jan 2010, at 11:23, hendrik at topoi.pooq.com wrote:

> On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
>> 
>> There is some disagreement floating around apparently on even what
>> to call the INTEGER <=> LONGINT conversions.
>> Currently ORD converts to INTEGER.
>> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
>> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
>> 
>> 
>> I believe I saw a proposal that the converesions be named after the type:
>>  INTEGER(expr), LONGINT(expr).
>> 
>> That kind of smacks to me of "too hard to search for".
>> 
>> Here is a crazy verbose suggestion:
>> LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
>> 
>> and allow it in safe modules?
>> At least it is existing syntax with roughly the desired meaning,
>> except that LOOPHOLE is and sounds unsafe.
>> 
>> CAST(expr, type)
>> CONVERT(expr, type)
>> ?
>> 
>> I'm just making up words here of course.
>> VAL or ORD seem sufficient, esp. if you can specify the type.
> 
> NARROW?  WIDEN?
> 
> And TRUNCATE if you really want to chop off the high-order bits without 
> overflow check?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/dc4d31ac/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 11 19:39:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 13:39:21 -0500
Subject: [M3devel] some more "crazy" proposals
In-Reply-To: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
References: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
Message-ID: <69F1DBED-115F-44A5-93D6-7C2375EC3E8E@cs.purdue.edu>

Jay, as you'll note from the commit messages, I've made ORD/VAL consistent with Rodney's proposal.
I think this is much more consistent, in treating VAL as the only *conversion* operator for ordinals.
ORD is really just there to allow conversion of enumerations to INTEGER, but for consistency it makes sense to have ORD return the underlying value without any conversion.  This makes the equality:

ORD(n) = VAL(ORD(n), T) = n

where T is the type of n.

Unfortunately, it also means that your uses of ORD in the Rd/Wr code must now turn into VAL(n, INTEGER).

On 11 Jan 2010, at 07:17, Jay K wrote:

> 1) change file/rd/wr sizes to be BigInteger.T
> 
> and/or
> 
> 2) Introduce SeekL, IndexL, StatusL, etc.
> default implementation calls Seek/Index/Status and does checked truncation.
> Clients gradually port to LONGINT or BigInteger.T.
> Completely source compatible.
> 
> 
> 3) BigInteger.T is The multiple-INTEGER precision type??
> No compiler/language change??
> 
> 
> I might try these out, and then go the extra step and port the file dialog to avoid the exception..
> see what it all looks like...
> 
>  - Jay



From rodney_bates at lcwb.coop  Tue Jan 12 01:18:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:18:46 -0600
Subject: [M3devel] Mixed arithmetic
Message-ID: <4B4BBFE6.1090701@lcwb.coop>

Well, I have been mistaken.  I finally found the statement about argument
types of builtin operators.  Every time I go looking for this, I have trouble
finding it.  I had remembered it wrongly.  It does not say an actual argument must
be assignable to the type in the signature, it says it must be a _subtype_
of the type in the signature.  Actually, it says the overloading is resolved
using the subtype relation, but this has the same effect on what is and
isn't statically legal.

(2.6.1):  The particular operation will be selected so that each actual
           argument type is a subtype of the corresponding formal type or
           a member of the formal type class.

So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
rules.  We would have to insert 4 different overloaded signatures for
+, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
language changes for LONGINT a lot simpler.

This weakens my support of mixed arithmetic.

However, there is still some messiness to be resolved.  The relations do use
assignability rather than subtyping, in such a way that mixed comparisons
do fall out of the existing rules.  (The overload resolution is done on
type class, not type, and doesn't, by itself, preclude mixed INTEGER/
LONGINT comparisons.)  Then there are a lot of other places
that use assignability.  They are:

- assignment statements
- passing parameters to VALUE or READONLY formals
- passing VAR open array parameters (a different kind of assignability, not
      really relevant)
- RAISE statements
- RETURN statements
- Initial value assignment in a VAR declaration
- array subscripts in designators a[i]
- elements of set, array, and record constructors
- relational operators, including IN
- ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)

I too am generally a fan of syntactic explicitness, rather than having things
happen behind the scenes, without the programmer's coding them.  But if we
disallow mixed arithmetic operations, it seems to me that it becomes
quite arbitrary where we are allowing assignability and where we are
requiring explicit type conversions.

Without LONGINT in the picture, this arbitrariness didn't happen, because
there was no case where assignability vs. subtyping for the arguments of
the arithmetic operators made any difference.

I do think it would be particularly inconsistent to disallow the mixed
arithmetic but allow mixed relations.  As Tony has pointed out, these
two differ from the other uses of assignability in having two expressions
whose types must be used to infer a common value range to do the operation
in.  All the other uses of assignability have only one "target" type to
assign to.


From rodney_bates at lcwb.coop  Tue Jan 12 01:25:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:25:37 -0600
Subject: [M3devel] Integer overflow
In-Reply-To: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
Message-ID: <4B4BC181.8020807@lcwb.coop>

If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
I think wrapping around to the maximal negative value would be reasonable.  Even for
CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
done in the full INTEGER range).  But then the assignment of the result back to the
CARDINAL variable really must do a range check.  This derives from the assignment
x:= ... in the WITH equivalent, not from the + 1 operation.

Mainly, there is a pervasive principle in the safety of the language that you can
never get a bit pattern stored in a variable that does not map back to an abstract
value of its type.  We really need to preserve this.

Tony Hosking wrote:
> Even under the interpretation for INC that yields:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
> 
> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
> 
> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
> 
> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
> 
>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN INC(s) END;
>>
>> Should this fail at runtime with a range check error?
>>
>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>
>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
> 
> 


From rodney_bates at lcwb.coop  Tue Jan 12 01:45:27 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:45:27 -0600
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <4B4BC627.6030103@lcwb.coop>



Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is 
> the need for distinct literal forms.  This strikes me as odd, since 
> literals are really just ways of writing values, rather than stating 
> anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, 
> but they really do have incompatible value representations).

I agree, the need for distinctly typed literals is much greater for the
floating types than the integer types, because they can't be viewed
as having overlapping value sets in any reasonable way.

> 
> It strikes me that with checked assignability for INTEGER/LONGINT we 
> could also potentially treat integer literals as essentially "untyped" 
> (neither INTEGER nor LONGINT). (I still strongly resist going the route 
> of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants 
> lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be 
> unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base 
> type of the subrange should be.

This would eliminate _one_ reason for needing distinct integer literals.

> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

The reason I proposed the distinct literals is because of feeling very
badly burned by Ada.  It has a type "universal integer", which is builtin,
and all integer literals have this type.  They have unbounded range and
a complete set of arithmetic operators, which can only be evaluated at
compile time.  The type "universal integer" can't be named in source
code.

The rules for when they are converted to a type having a runtime representation
are complicated, messy, highly surprising, and a huge complication of the
language.  Static type information can propagate a long way through
language constructs.  The programmer's dilemma in figuring out just what
is happening is much worse than arithmetic operators that accept mixed
sizes and do the computation in the larger size.

Maybe the semantics of this idea could be done better than in Ada, but I spent
a lot of time trying, and didn't come up with anything that wasn't both too
complicated and not worth the gain, IMO.

We should come up with a complete language proposal before going this way.


> 

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Tue Jan 12 02:02:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 20:02:01 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <DB1A2DAE-CCAD-44EF-9687-DAD88C216DF3@cs.purdue.edu>

My firm position now is that we continue to disallow both mixed arithmetic *and* assignability, and stick with the status quo as described at:

http://www.cs.purdue.edu/~hosking/m3/reference/index.html
http://www.cs.purdue.edu/homes/hosking/m3/reference/complete/m3-defn-complete.pdf

On 11 Jan 2010, at 19:18, Rodney M. Bates wrote:

> Well, I have been mistaken.  I finally found the statement about argument
> types of builtin operators.  Every time I go looking for this, I have trouble
> finding it.  I had remembered it wrongly.  It does not say an actual argument must
> be assignable to the type in the signature, it says it must be a _subtype_
> of the type in the signature.  Actually, it says the overloading is resolved
> using the subtype relation, but this has the same effect on what is and
> isn't statically legal.
> 
> (2.6.1):  The particular operation will be selected so that each actual
>          argument type is a subtype of the corresponding formal type or
>          a member of the formal type class.
> 
> So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
> rules.  We would have to insert 4 different overloaded signatures for
> +, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
> language changes for LONGINT a lot simpler.
> 
> This weakens my support of mixed arithmetic.
> 
> However, there is still some messiness to be resolved.  The relations do use
> assignability rather than subtyping, in such a way that mixed comparisons
> do fall out of the existing rules.  (The overload resolution is done on
> type class, not type, and doesn't, by itself, preclude mixed INTEGER/
> LONGINT comparisons.)  Then there are a lot of other places
> that use assignability.  They are:
> 
> - assignment statements
> - passing parameters to VALUE or READONLY formals
> - passing VAR open array parameters (a different kind of assignability, not
>     really relevant)
> - RAISE statements
> - RETURN statements
> - Initial value assignment in a VAR declaration
> - array subscripts in designators a[i]
> - elements of set, array, and record constructors
> - relational operators, including IN
> - ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)
> 
> I too am generally a fan of syntactic explicitness, rather than having things
> happen behind the scenes, without the programmer's coding them.  But if we
> disallow mixed arithmetic operations, it seems to me that it becomes
> quite arbitrary where we are allowing assignability and where we are
> requiring explicit type conversions.
> 
> Without LONGINT in the picture, this arbitrariness didn't happen, because
> there was no case where assignability vs. subtyping for the arguments of
> the arithmetic operators made any difference.
> 
> I do think it would be particularly inconsistent to disallow the mixed
> arithmetic but allow mixed relations.  As Tony has pointed out, these
> two differ from the other uses of assignability in having two expressions
> whose types must be used to infer a common value range to do the operation
> in.  All the other uses of assignability have only one "target" type to
> assign to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/92f2fcce/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 02:18:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:18:26 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>


>> One thing I've really struggled with over the introduction of LONGINT is
>> the need for distinct literal forms. This strikes me as odd, since
>> literals are really just ways of writing values, rather than stating
>> anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct,
>> but they really do have incompatible value representations).
>
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.

 
Huh? This seems to me to be directly opposite of the truth.
LONGREAL is a strict superset of REAL in what it can represent.
There is *complete* overlap.
Am I really mistaken here?
Floating point is indeed very wierd, but it isn't this wierd.
Right?
 
 
 - Jay




---------------------------------------- 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 02:21:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:21:34 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>


> rather than having things
> happen behind the scenes, without the programmer's coding them
 
 
Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.
  It is two or three function calls.
Look at the garbage collector. 
Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
 I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.
 
 
Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
 
 
It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.
 
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 03:11:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:11:23 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <4405421D-C606-4DC4-B6D4-4C50DA03992B@cs.purdue.edu>

Yes, I agree.  I am now convinced that relaxing the current spec to allow assignability and mixed operand arithmetic is a swamp that we should steer well clear of.

On 11 Jan 2010, at 19:45, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.
> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> Here's how things would work with subrange types.
>> A subrange written as currently
>> [lo .. hi]
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> A subrange with base type LONGINT would be written explicitly:
>> [lo .. hi] OF LONGINT
>> The constants lo/hi must both be in range for LONGINT.
>> We could also support the form:
>> [lo .. hi] OF INTEGER
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> This would eliminate _one_ reason for needing distinct integer literals.
> 
>> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> The reason I proposed the distinct literals is because of feeling very
> badly burned by Ada.  It has a type "universal integer", which is builtin,
> and all integer literals have this type.  They have unbounded range and
> a complete set of arithmetic operators, which can only be evaluated at
> compile time.  The type "universal integer" can't be named in source
> code.
> 
> The rules for when they are converted to a type having a runtime representation
> are complicated, messy, highly surprising, and a huge complication of the
> language.  Static type information can propagate a long way through
> language constructs.  The programmer's dilemma in figuring out just what
> is happening is much worse than arithmetic operators that accept mixed
> sizes and do the computation in the larger size.
> 
> Maybe the semantics of this idea could be done better than in Ada, but I spent
> a lot of time trying, and didn't come up with anything that wasn't both too
> complicated and not worth the gain, IMO.
> 
> We should come up with a complete language proposal before going this way.
> 
> 
> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33599c21/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 03:09:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:09:39 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <4B4BC181.8020807@lcwb.coop>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
	<4B4BC181.8020807@lcwb.coop>
Message-ID: <8432422C-A96C-4A0A-A8F9-9EC10963548A@cs.purdue.edu>

If the type were INTEGER instead of CARDINAL then the current implementation *does* allow wrap-around.  I've fixed the range check so that overflow does not permit the bits for FIRST(INTEGER) to be stored in the CARDINAL.

On 11 Jan 2010, at 19:25, Rodney M. Bates wrote:

> If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
> I think wrapping around to the maximal negative value would be reasonable.  Even for
> CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
> done in the full INTEGER range).  But then the assignment of the result back to the
> CARDINAL variable really must do a range check.  This derives from the assignment
> x:= ... in the WITH equivalent, not from the + 1 operation.
> 
> Mainly, there is a pervasive principle in the safety of the language that you can
> never get a bit pattern stored in a variable that does not map back to an abstract
> value of its type.  We really need to preserve this.
> 
> Tony Hosking wrote:
>> Even under the interpretation for INC that yields:
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
>> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
>> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
>> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
>>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>> 
>>> VAR s: CARDINAL := LAST(INTEGER);
>>> BEGIN INC(s) END;
>>> 
>>> Should this fail at runtime with a range check error?
>>> 
>>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>> 
>>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>> 
>>> 
>>> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33f19a51/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 03:18:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:18:00 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>

On 11 Jan 2010, at 20:21, Jay K wrote:

> 
>> rather than having things
>> happen behind the scenes, without the programmer's coding them
> 
> 
> Just a reminder that things happen behind the scenes *all the time*.
> It is the norm, not the exception.
> Look at what "try" does.
>  It is two or three function calls.

Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.

> Look at the garbage collector. 

Again, that is not visible to the programmer.  Same again re programmer reasoning.

> Look at layering in various places.
> The system is not simple.
> This isn't a bad thing necessarily.
> Getting things done often requires complexity.
> I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.

His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.

> Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
> 
> 
> It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.

What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?

Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.

I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.

I strongly support the status quo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/02734d2d/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 04:02:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:02:55 +0000
Subject: [M3devel] 64bit file sizes now?
Message-ID: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expr).

 

 

And this is already in place.

 

 

?

 

 

So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.

Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

 

 

I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.

Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/6b8770ea/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:10:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:10:06 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>

On 11 Jan 2010, at 22:02, Jay K wrote:

> So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).

That's what I think makes most sense.

>  And this is already in place.

Yes, it's in place.

> ?
>  
> So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
> Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?

>  I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
> Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/f34e80d9/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 04:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:10:52 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
References: <4B4BBFE6.1090701@lcwb.coop>,
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>,
	<69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
Message-ID: <COL101-W65EDF1A26440E2A141F67FE66C0@phx.gbl>


The limited range of efficient integers will always be a problem.

 

 

After all, in the real world, there is no such thing as LAST(INTEGER), nor the notion that + can fail, but even in Modula-3 we have both of these unfortunate things for efficiency.

 

 

It is a wierd system already.

 

 

Having LAST(INTEGER) + 1 fail or be FIRST(INTEGER) but LAST(INTEGER) + 1L provide a more sensible result I'm skeptical makes it any worse or wierder than it already is.

 

 

On the other hand, rd/wr/file ugliness is also fairly unavoidable, and just would have been there from the start had things been done right.

 

 

It is the unavoidable case that "large" files, even if they do fit in address space, are hard to deal with efficiently. Programmers are very used to efficient random access and often don't design for sequential access. And heck, with the rise of SSDs replacing spinning magnetic disks, it isn't going to matter any longer anyway.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 21:18:00 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Mixed arithmetic




On 11 Jan 2010, at 20:21, Jay K wrote:




rather than having things

happen behind the scenes, without the programmer's coding them


Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.

 It is two or three function calls.



Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.


Look at the garbage collector. 



Again, that is not visible to the programmer.  Same again re programmer reasoning.


Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.



His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.


Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.




It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.


What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?


Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.


I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.


I strongly support the status quo.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/50f52f29/attachment-0001.html>

From rcolebur at SCIRES.COM  Tue Jan 12 04:11:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 22:11:51 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>

Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)
then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).  Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);
but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

So, at this point, to summarize, I think you are advocating:

1.      Distinct types INTEGER and LONGINT.

2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.

3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).

4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.

5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.

6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Now, what to do about converting from LONGINT to INTEGER?

a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

e.      Any other ideas?

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:


Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.



2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.


 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.


 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.


 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.


 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.


 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.


 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.


 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...


 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:



I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/77faa179/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 04:16:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:16:42 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
Message-ID: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>


Large files (64bit file sizes) are very old.

Windows 95 had them in the released API 14+ years ago (1995), NT a few years before that (1993?), betas earlier. I heard VMS had 64bit file sizes but I haven't confirmed.

 

 > If the use-case is typically INTEGER then perhaps we
 > need to think of alternatives using abstraction?
 

Hm. StatusLong, SeekLong, IndexLong, LengthLong?

Default calls Seek/Index/Length, range checked truncation?

Kind of an annoying duplicity of APIs though.

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 22:10:06 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] 64bit file sizes now?




On 11 Jan 2010, at 22:02, Jay K wrote:


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).



That's what I think makes most sense.


 And this is already in place.



Yes, it's in place.



?
 
So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.



If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?


 I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/35d6807e/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Jan 12 04:27:23 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 12 Jan 2010 03:27:23 +0000 (GMT)
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <420956.32527.qm@web23605.mail.ird.yahoo.com>

Hi all:
forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
(LAST(INTEGER) + 1) = FIRST (INTEGER)
This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
Please let me know if I'm wrong about this issue on current discussions. 

--- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] 64bit file sizes now?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 11 de enero, 2010 22:02
> 
> 
> 
> 
>  
> So.. LONGINT as I understand will remain roughly as it was,
> except VAL(expr, INTEGER) is how you convert expr to
> INTEGER, instead of ORD(expr).
> 
>  
> 
>  
> 
> And this is already in place.
> 
>  
> 
>  
> 
> ?
> 
>  
> 
>  
> 
> So I should go ahead and update File.i3/Status/size and
> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> the consequences"? The consequences are roughly the
> first diff I sent out, with the caveats that I used ORD()
> instead of VAL(,INTEGER), and a few packages were left to
> fix. It is mechanical and simple and predictable, just
> tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes"
> anyway, but a few might gain capacity.
> 
> Classic simple example is the mklib and libdump code, they
> read the entire file into memory and then deal with that.
> 
>  
> 
>  
> 
> I can send the diffs ahead of time, but there's really
> no choices left as to what they'll look like, it is
> forced by the limited capability of LONGINT.
> 
> Had they used LONGINT in the first place, of course,
> there'd be no diff at this time, the ugliness would have
> been builtin from the start.
> 
>  
> 
>  
> 
>  - Jay
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Tue Jan 12 04:40:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:40:28 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:

> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.

>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.

>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)

No, enumerations map only onto INTEGER.

> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.

>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.

>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)

> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 

This captures the identities precisely, which is why I reverted to the original formulation.

> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.

>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);

That is what is now implemented.

> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.

>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.

>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.

>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.

> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!

> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

> e.      Any other ideas?

I think we are done...

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/a7767a21/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:50:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:50:05 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <0EB89E7A-0804-4D07-9F80-CB1F5A343471@cs.purdue.edu>

Overflow checking is a whole other ball of wax... ;-)
The language reference provides for controlling the behavior of integer operations regarding overflow and divide by zero through the interface FloatMode.i3.  Unfortunately, the implementation of this interface on many targets is incomplete and the default behaviour is to allow integer operations to silently overflow.
Range checks are still injected by the compiler to ensure that no variable has a bit representation that is not a legal value for that variable.  Thus, for example:

VAR x: INTEGER := LAST(INTEGER)+1

will leave x with the value -1.

But,

VAR x: CARDINAL := LAST(INTEGER)+1

will cause a range fault because the overflowed result is not a legal CARDINAL.

It would be great if someone could devote some time to implementing this interface for x86 or x86_64 as they are the most widely used these days.  Of course, each OS target will probably need a different implementation.

On 11 Jan 2010, at 22:27, Daniel Alejandro Benavides D. wrote:

> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: [M3devel] 64bit file sizes now?
>> Para: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 11 de enero, 2010 22:02
>> 
>> 
>> 
>> 
>> 
>> So.. LONGINT as I understand will remain roughly as it was,
>> except VAL(expr, INTEGER) is how you convert expr to
>> INTEGER, instead of ORD(expr).
>> 
>> 
>> 
>> 
>> 
>> And this is already in place.
>> 
>> 
>> 
>> 
>> 
>> ?
>> 
>> 
>> 
>> 
>> 
>> So I should go ahead and update File.i3/Status/size and
>> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
>> the consequences"? The consequences are roughly the
>> first diff I sent out, with the caveats that I used ORD()
>> instead of VAL(,INTEGER), and a few packages were left to
>> fix. It is mechanical and simple and predictable, just
>> tedious and ugly.
>> Most Rd/Wr users are limited to INTEGER "sizes"
>> anyway, but a few might gain capacity.
>> 
>> Classic simple example is the mklib and libdump code, they
>> read the entire file into memory and then deal with that.
>> 
>> 
>> 
>> 
>> 
>> I can send the diffs ahead of time, but there's really
>> no choices left as to what they'll look like, it is
>> forced by the limited capability of LONGINT.
>> 
>> Had they used LONGINT in the first place, of course,
>> there'd be no diff at this time, the ugliness would have
>> been builtin from the start.
>> 
>> 
>> 
>> 
>> 
>> - Jay
>> 
>> 		 	   		  
>> 
> 
> 
> 



From jay.krell at cornell.edu  Tue Jan 12 04:46:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:46:13 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>


True that:

 

> (LAST(INTEGER) + 1) = FIRST (INTEGER)


 

many folks would like to see fail before it gets to the "=".

 

The dilemna remains though because:

 

> (LAST(INTEGER) + 1L) = FIRST (INTEGER)


 

would not fail.


So, you can either look at it as they produce different values, or one succeeds and one fails.

Either way people don't like two different expressions doing two different things.

Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.

 

There something here about "transitivity" or "replacement":

 

j2 := VAL(i1, LONGINT) + j3;

vs.

j2 := i1 + j3;

 

pretty clearly have the same meaning.

The conversion is always trivial and always succeeds.

Does anyone really find it ambiguous?

 

 - Jay

 
> Date: Tue, 12 Jan 2010 03:27:23 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] 64bit file sizes now?
> 
> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: [M3devel] 64bit file sizes now?
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: lunes, 11 de enero, 2010 22:02
> > 
> > 
> > 
> > 
> > 
> > So.. LONGINT as I understand will remain roughly as it was,
> > except VAL(expr, INTEGER) is how you convert expr to
> > INTEGER, instead of ORD(expr).
> > 
> > 
> > 
> > 
> > 
> > And this is already in place.
> > 
> > 
> > 
> > 
> > 
> > ?
> > 
> > 
> > 
> > 
> > 
> > So I should go ahead and update File.i3/Status/size and
> > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > the consequences"? The consequences are roughly the
> > first diff I sent out, with the caveats that I used ORD()
> > instead of VAL(,INTEGER), and a few packages were left to
> > fix. It is mechanical and simple and predictable, just
> > tedious and ugly.
> > Most Rd/Wr users are limited to INTEGER "sizes"
> > anyway, but a few might gain capacity.
> > 
> > Classic simple example is the mklib and libdump code, they
> > read the entire file into memory and then deal with that.
> > 
> > 
> > 
> > 
> > 
> > I can send the diffs ahead of time, but there's really
> > no choices left as to what they'll look like, it is
> > forced by the limited capability of LONGINT.
> > 
> > Had they used LONGINT in the first place, of course,
> > there'd be no diff at this time, the ugliness would have
> > been builtin from the start.
> > 
> > 
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/f3bf331f/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:57:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:57:38 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
Message-ID: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>

On 11 Jan 2010, at 22:46, Jay K wrote:

> True that:
>  
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> 
>  
> many folks would like to see fail before it gets to the "=".

WIthout overflow checking the addition will not fail.

>  
> The dilemna remains though because:
>  
> > (LAST(INTEGER) + 1L) = FIRST (INTEGER)

Actually, you mean VAL(LAST(INTEGER), LONGINT) + 1L

> would not fail.
> 
> So, you can either look at it as they produce different values, or one succeeds and one fails.

The point is that the type explicitly tells you whether you might be in trouble with overflow.

> Either way people don't like two different expressions doing two different things.
> Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.
>  
> There something here about "transitivity" or "replacement":
>  
> j2 := VAL(i1, LONGINT) + j3;
> vs.
> j2 := i1 + j3;

It is not referentially transparent.  It requires innate knowledge about promotion rules to understand.  That's what "not referentially transparent" means!

>  
> pretty clearly have the same meaning.
> The conversion is always trivial and always succeeds.
> Does anyone really find it ambiguous?
>  
>  - Jay
> 
>  
> > Date: Tue, 12 Jan 2010 03:27:23 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com; jay.krell at cornell.edu
> > Subject: Re: [M3devel] 64bit file sizes now?
> > 
> > Hi all:
> > forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> > This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> > Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> > Please let me know if I'm wrong about this issue on current discussions. 
> > 
> > --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> > 
> > > De: Jay K <jay.krell at cornell.edu>
> > > Asunto: [M3devel] 64bit file sizes now?
> > > Para: "m3devel" <m3devel at elegosoft.com>
> > > Fecha: lunes, 11 de enero, 2010 22:02
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So.. LONGINT as I understand will remain roughly as it was,
> > > except VAL(expr, INTEGER) is how you convert expr to
> > > INTEGER, instead of ORD(expr).
> > > 
> > > 
> > > 
> > > 
> > > 
> > > And this is already in place.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So I should go ahead and update File.i3/Status/size and
> > > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > > the consequences"? The consequences are roughly the
> > > first diff I sent out, with the caveats that I used ORD()
> > > instead of VAL(,INTEGER), and a few packages were left to
> > > fix. It is mechanical and simple and predictable, just
> > > tedious and ugly.
> > > Most Rd/Wr users are limited to INTEGER "sizes"
> > > anyway, but a few might gain capacity.
> > > 
> > > Classic simple example is the mklib and libdump code, they
> > > read the entire file into memory and then deal with that.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > I can send the diffs ahead of time, but there's really
> > > no choices left as to what they'll look like, it is
> > > forced by the limited capability of LONGINT.
> > > 
> > > Had they used LONGINT in the first place, of course,
> > > there'd be no diff at this time, the ugliness would have
> > > been builtin from the start.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > 
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/59d798f0/attachment-0001.html>

From rcolebur at SCIRES.COM  Tue Jan 12 05:09:46 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:09:46 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

I'm sorry, I missed the fact that you changed the type to "Integer" vs. "INTEGER" and defined "Integer" to be "INTEGER" or "LONGINT".

I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be "happy" with this state of affairs.

I am confused though by your last set of statements, namely:

>I don't think we need to do this, assuming you understand what I have said above.
>
>ORD(x: INTEGER): LONGINT
>ORD(x: LONGINT): INTEGER
>ORD(x: Enumeration): INTEGER
>ORD(x: Subrange): Base(Subrange)
>
>ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

Didn't you mean:
                ORD(x:INTEGER): INTEGER
                ORD(x:LONGINT): LONGINT

Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
"m3-libs\m3core"
"m3-libs\libm3"
"m3-tools\m3tk"
So some recent changes have caused a problem.

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 10:40 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:


Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.


 I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.


 Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

No, enumerations map only onto INTEGER.


Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.


 The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.


 So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)


then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).

This captures the identities precisely, which is why I reverted to the original formulation.


Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.


 I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);

That is what is now implemented.


but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.


 I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.


 So, at this point, to summarize, I think you are advocating:
1.      Distinct types INTEGER and LONGINT.
2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.


 Now, what to do about converting from LONGINT to INTEGER?
a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.


b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!


d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

e.      Any other ideas?

I think we are done...



Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:



Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.




2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.



 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.



 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.



 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.



 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.



 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.



 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.



 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...



 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:




I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/e7c16c65/attachment-0001.html>

From jdp at polstra.com  Tue Jan 12 05:43:50 2010
From: jdp at polstra.com (John Polstra)
Date: Mon, 11 Jan 2010 20:43:50 -0800
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <4B4BFE06.5010400@polstra.com>

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From jay.krell at cornell.edu  Tue Jan 12 05:55:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 04:55:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
Message-ID: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>


I thought FloatMode was only related to floating point.

So I looked:

 

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

 

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


 

This part of it should be easy to implement for all architectures.

The entire thing probably isn't too difficult either on many platforms either.

 

However...I was surprised by this.

I thought the real "intent" in Modula-3 to not have this be configurable

and endeavor for overflow and divide by zero to always immediately

raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

 

For the floating point stuff:

 

Probably like other per-platform code, this should be done in #ifdefed C.

 

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx

http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html

etc.

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/32017d54/attachment-0001.html>

From rcolebur at SCIRES.COM  Tue Jan 12 05:59:01 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:59:01 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <4B4BFE06.5010400@polstra.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>

I also took the liberty of contacting him.  Shown below is my message and his response:
Regards,
Randy

On Mon, 11 Jan 2010 12:19:26 -0500
Randy Coleburn <rcolebur at SCIRES.COM> wrote:

> Just want to let you know that the folks hosting the mail list service are trying to fulfill your request to be added to the m3devel mail list.
> 
> The problem seems to be blacklisting of one of the hosts.  At first it seemed your email address was blacklisted, but upon further investigation it seems your email server (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has blacklisted the mail list server at elegosoft.  Note that the elegosoft server is based in Germany.
> 
> The server admins are working on the problem, but not sure if/when it will be resolved.
> 
> I'm one of the developers and also subscribe to the list and noticed the traffic about your request, so thought I would try and send you an email to see if it gets thru and to let you know of the problem.
> 
> Regards,
> Randy
> 

Thanks for the heads up. I'll give them a call to see what the problem is.

AT&T actually does it's mail hosting through Yahoo mail, so they might actually be the ones doing the blacklisting. I'm going to do some poking around on this end; and I'll send you an email if I find anything noteworthy.

Thank you.

-- 
Chris <dimonax at att.net>


-----Original Message-----
From: John Polstra [mailto:jdp at polstra.com] 
Sent: Monday, January 11, 2010 11:44 PM
To: Tony Hosking
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] Fwd: CM3 development Inquiry.

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From rcolebur at SCIRES.COM  Tue Jan 12 06:18:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>

Jay,

I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.

This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.

Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.

I agree that lumping the integer overflow control into an interface named "FloatMode" makes it a bit hard to find since "FloatMode" would make one think that the interface deals only with floating point.

So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won't care and his code will eventually break.  See the comments about long-lived readers/writers for an example.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode

I thought FloatMode was only related to floating point.
So I looked:

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.

However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

For the floating point stuff:

Probably like other per-platform code, this should be done in #ifdefed C.

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/ba0a561e/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 06:32:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 05:32:35 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W55FC6ED07465737B2146C4E66C0@phx.gbl>


Rewrite code to avoid overflow?

 That seems..difficult.

 Write it in a typical normal straightfoward

   fashion and rely on overflow checking to avoid bugs, imho.

 

I think relying on silent wrap is bad but relying on overflow

checks is appropriate.

 

Really what I think is you need multiple types or interfaces.

So that you can request silent wraparound for certain code

and overflow checking for other code. It's not a per-thread

setting, but a type thing.

It is more "statically bound" than a runtime per thread setting.

 

In the absence of this profusion of

types though, a good safe compromise is the INTEGER/Word

split. INTEGER is signed and should check overflow.

 

Word is unsigned and silently wraps.

 

Really this isn't everything. You also want unsigned

with overflow checks, maybe signed with silent wraparound.

Maybe the arithmetic library provides all this.

I need to check.

 

 

Testing your code one way and shipping it another way

is a bad recipe. The checks need to be preserved

in the shipping version because testing is never complete.

Also because the checks might have unintended side effects.

Ship what you test.

 

 

Again though, isn't silent wraparound a safety hole?

Or maybe not, maybe given that we have array bounds checking,

maybe safety is preserved?

(You know, what would happen incorrectly when positive + positive

yields negative?)

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: Re: [M3devel] FloatMode





Jay, 
 
I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.
 
This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.
 
Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.
 
I agree that lumping the integer overflow control into an interface named ?FloatMode? makes it a bit hard to find since ?FloatMode? would make one think that the interface deals only with floating point.
 
So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won?t care and his code will eventually break.  See the comments about long-lived readers/writers for an example.
 
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode
 
I thought FloatMode was only related to floating point.
So I looked:
 
   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.
 
   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}

 
This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.
 
However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
 
For the floating point stuff:
 
Probably like other per-platform code, this should be done in #ifdefed C.
 
http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/57b85e47/attachment-0001.html>

From mika at async.async.caltech.edu  Tue Jan 12 06:46:03 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:46:03 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>
Message-ID: <20100112054603.A07EA1A2078@async.async.caltech.edu>

Jay K writes:
>
>>> One thing I've really struggled with over the introduction of LONGINT is
>>> the need for distinct literal forms. This strikes me as odd=2C since
>>> literals are really just ways of writing values=2C rather than stating
>>> anything about how they should be represented.
>>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
>=2C
>>> but they really do have incompatible value representations).
>>
>> I agree=2C the need for distinctly typed literals is much greater for the
>> floating types than the integer types=2C because they can't be viewed
>> as having overlapping value sets in any reasonable way.
>
>=20
>Huh? This seems to me to be directly opposite of the truth.
>LONGREAL is a strict superset of REAL in what it can represent.
>There is *complete* overlap.
>Am I really mistaken here?
>Floating point is indeed very wierd=2C but it isn't this wierd.
>Right?
>=20
>=20
> - Jay

Jay, I think if you have hardware that's strictly compliant with IEEE
754, you're right.  Or at least there exists an interpretation of the
values that have this property.  I alluded earlier to the fact that
Alpha represents single-precision by zeroing out the middle of the
double-precision register (some of the mantissa and some of the exponent).

However I'm sure there are systems for which this is not true.  Is 
Modula-3 forbidden from being ported to such machines?

    Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:47:25 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:47:25 -0800
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl> 
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <20100112054725.2C8ED1A207C@async.async.caltech.edu>

Jay K writes:
>
>> rather than having things
>> happen behind the scenes=2C without the programmer's coding them
>=20
>=20
>Just a reminder that things happen behind the scenes *all the time*.
>It is the norm=2C not the exception.
>Look at what "try" does.
>  It is two or three function calls.
>Look at the garbage collector.=20
>Look at layering in various places.

These things are not visible to the programmer.

     Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:53:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:53:49 -0800
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
	<COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>
Message-ID: <20100112055349.CBEFE1A2080@async.async.caltech.edu>


Why not change the implementation to something using LONGINT (or
BigInteger.T...)  and then provide the old ones as a thin veneer over
the new implementation, marking the old ones as <*OBSOLETE*>...

    Mika


Jay K writes:
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Large files (64bit file sizes) are very old.
>
>Windows 95 had them in the released API 14+ years ago (1995)=2C NT a few ye=
>ars before that (1993?)=2C betas earlier. I heard VMS had 64bit file sizes =
>but I haven't confirmed.
>
>=20
>
> > If the use-case is typically INTEGER then perhaps we
> > need to think of alternatives using abstraction?
>=20
>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?
>
>Default calls Seek/Index/Length=2C range checked truncation?
>
>Kind of an annoying duplicity of APIs though.
>
>=20
>
> - Jay
>=20
>
>
>From: hosking at cs.purdue.edu
>Date: Mon=2C 11 Jan 2010 22:10:06 -0500
>To: jay.krell at cornell.edu
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] 64bit file sizes now?
>
>
>
>
>On 11 Jan 2010=2C at 22:02=2C Jay K wrote:
>
>
>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(ex=
>pr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire)=
>.
>
>
>
>That's what I think makes most sense.
>
>
> And this is already in place.
>
>
>
>Yes=2C it's in place.
>
>
>
>?
>=20
>So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Le=
>ngth to all be LONGINT=2C "whatever the consequences"? The consequences are=
> roughly the first diff I sent out=2C with the caveats that I used ORD() in=
>stead of VAL(=2CINTEGER)=2C and a few packages were left to fix. It is mech=
>anical and simple and predictable=2C just tedious and ugly.
>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few might g=
>ain capacity.
>Classic simple example is the mklib and libdump code=2C they read the entir=
>e file into memory and then deal with that.
>
>
>
>If the use-case is typically INTEGER then perhaps we need to think of alter=
>natives using abstraction?
>
>
> I can send the diffs ahead of time=2C but there's really no choices left a=
>s to what they'll look like=2C it is forced by the limited capability of LO=
>NGINT.
>Had they used LONGINT in the first place=2C of course=2C there'd be no diff=
> at this time=2C the ugliness would have been builtin from the start.
>
>When they originally wrote it large file sizes were only proposed not imple=
>mented.  I don't think C even had long long then.  (Yes=2C I am showing my =
>age! -- we are talking almost 20 years ago now!)  If they had used LONGINT =
>from the start then folks would have not had any ugliness because all would=
> have used LONGINT.    Now=2C to save some hassles in future=2C perhaps we =
>need a better abstraction!  Let's ponder that before you propagate your cha=
>nges.
>
> 		 	   		  =
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Large files (64bit file sizes) are very old.<BR>
>Windows 95 had them in the released&nbsp=3BAPI 14+ years ago (1995)=2C NT a=
> few years before that (1993?)=2C betas earlier. I heard VMS had 64bit file=
> sizes but I haven't confirmed.<BR>
>&nbsp=3B<BR>
><DIV>&nbsp=3B&gt=3B If the use-case is typically INTEGER then perhaps we</D=
>IV>
><DIV>&nbsp=3B&gt=3B need to think of alternatives using abstraction?</DIV>
>&nbsp=3B<BR>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?<BR>
>Default calls Seek/Index/Length=2C range checked truncation?<BR>
>Kind of an annoying duplicity of APIs though.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>
><HR id=3DstopSpelling>
>From: hosking at cs.purdue.edu<BR>Date: Mon=2C 11 Jan 2010 22:10:06 -0500<BR>T=
>o: jay.krell at cornell.edu<BR>CC: m3devel at elegosoft.com<BR>Subject: Re: [M3de=
>vel] 64bit file sizes now?<BR><BR><BASE>
><DIV><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLL=
>APSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPA=
>CING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxAppl=
>e-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BOR=
>DER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LE=
>TTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=
>=3DecxApple-style-span>
><DIV style=3D"WORD-WRAP: break-word"><SPAN style=3D"TEXT-TRANSFORM: none=3B=
> TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B W=
>HITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WO=
>RD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TRANSFORM:=
> none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvet=
>ica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C=
>0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TR=
>ANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12p=
>x Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(=
>0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D=
>"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B F=
>ONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COL=
>OR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN =
>style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separ=
>ate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: norma=
>l=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-spa=
>n><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPS=
>E: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACIN=
>G: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-s=
>tyle-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER=
>-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTE=
>R-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3Dec=
>xApple-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=
>=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: norma=
>l=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" =
>class=3DecxApple-style-span>
><DIV><SPAN style=3D"FONT-SIZE: medium" class=3DecxApple-style-span>On 11 Ja=
>n 2010=2C at 22:02=2C Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN>=
></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
><DIV><BR class=3DecxApple-interchange-newline>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(e=
>xpr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire=
>).<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>That's what I think makes most sense.</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BAnd this is already in place.<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>Yes=2C it's in place.</DIV>
><DIV><BR></DIV>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>?<BR>&nbsp=3B<BR>So I should go ahead and update File.i3/Status/size and R=
>d/Wr/Index/Seek/Length to all be LONGINT=2C "whatever the consequences"? Th=
>e consequences are roughly the first diff I sent out=2C with the caveats th=
>at I used ORD() instead of VAL(=2CINTEGER)=2C and a few packages were left =
>to fix. It is mechanical and simple and predictable=2C just tedious and ugl=
>y.<BR>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few m=
>ight gain capacity.<BR>Classic simple example is the mklib and libdump code=
>=2C they read the entire file into memory and then deal with that.<BR></DIV=
>></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>If the use-case is typically INTEGER then perhaps we need to think of =
>alternatives using abstraction?</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BI can send the diffs ahead of time=2C but there's really no choice=
>s left as to what they'll look like=2C it is forced by the limited capabili=
>ty of LONGINT.<BR>Had they used LONGINT in the first place=2C of course=2C =
>there'd be no diff at this time=2C the ugliness would have been builtin fro=
>m the start.</DIV></SPAN></BLOCKQUOTE><BR></DIV>
><DIV>When they originally wrote it large file sizes were only proposed not =
>implemented. &nbsp=3BI don't think C even had <FONT class=3DecxApple-style-=
>span face=3DCourier>long long</FONT>&nbsp=3Bthen. &nbsp=3B(Yes=2C I am show=
>ing my age! -- we are talking almost 20 years ago now!) &nbsp=3BIf they had=
> used LONGINT from the start then folks would have not had any ugliness bec=
>ause all would have used LONGINT. &nbsp=3B &nbsp=3BNow=2C to save some hass=
>les in future=2C perhaps we need a better abstraction! &nbsp=3BLet's ponder=
> that before you propagate your changes.</DIV>
><DIV><BR></DIV> 		 	   		  </body>
></html>=
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_--


From jay.krell at cornell.edu  Tue Jan 12 07:19:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:19:45 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>


When do you forsee any non-IEEE 754 floating point environments coming into existance?

 

Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?

For that matter, probably Perl and Python, but I'd have to check.

Chances are high they only expose 64bit float and nothing else.

 

 

The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?

 

 

I know, I know "never say never", but sometimes....?

 

 

Certainly there are also 80bit formats on x86 and 68K.

 Though x86 is moving away from this with SSE/SSE2.

And I think 128bit formats on PowerPC.

And something beyond 64bits on IA64 (Itanium).

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/a8d6a0f6/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 07:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:21:43 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W608B0F5C8B52AB95E8D61E66C0@phx.gbl>


And even these 80 bit and 128 bit formats I'm sure can represent all values losslessly of the smaller types. I have to look into this stuff though.

 

 - Jay

 


From: jay.krell at cornell.edu
To: mika at async.async.caltech.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Integer literals
Date: Tue, 12 Jan 2010 06:19:45 +0000



When do you forsee any non-IEEE 754 floating point environments coming into existance?
 
Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?
For that matter, probably Perl and Python, but I'd have to check.
Chances are high they only expose 64bit float and nothing else.
 
 
The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?
 
 
I know, I know "never say never", but sometimes....?
 
 
Certainly there are also 80bit formats on x86 and 68K.
 Though x86 is moving away from this with SSE/SSE2.
And I think 128bit formats on PowerPC.
And something beyond 64bits on IA64 (Itanium).
 
 
 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/656c93c9/attachment-0001.html>

From mika at async.async.caltech.edu  Tue Jan 12 07:42:43 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 22:42:43 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
Message-ID: <20100112064243.6828D1A2078@async.async.caltech.edu>

Jay K writes:
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?

x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
done in extended and then truncated by a store/load pair, if I remember
correctly).  That's not a non-IEEE format.  And I find it puzzling that
we don't expose the x87 native format in Modula-3 as EXTENDED.

One common completely non-IEEE format is Cray floating point.

In any case writing IEEE floating point into the specification of a
systems language like Modula-3 seems completely wrong to me.
Who knows what tomorrow will bring?

    Mika

>
>=20
>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>ature of all CPUs=2C at least ones that have any floating point support? Or=
> any software floating point library?
>
>For that matter=2C probably Perl and Python=2C but I'd have to check.
>
>Chances are high they only expose 64bit float and nothing else.
>
>=20
>
>=20
>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?
>
>=20
>
>=20
>
>I know=2C I know "never say never"=2C but sometimes....?
>
>=20
>
>=20
>
>Certainly there are also 80bit formats on x86 and 68K.
>
> Though x86 is moving away from this with SSE/SSE2.
>
>And I think 128bit formats on PowerPC.
>
>And something beyond 64bits on IA64 (Itanium).
>
>=20
>
>=20
>
> - Jay
>=20
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Integer literals=20
>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>> From: mika at async.async.caltech.edu
>>=20
>> Jay K writes:
>> >
>> >>> One thing I've really struggled with over the introduction of LONGINT=
> is
>> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>e
>> >>> literals are really just ways of writing values=3D2C rather than stat=
>ing
>> >>> anything about how they should be represented.
>> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>tinct=3D
>> >=3D2C
>> >>> but they really do have incompatible value representations).
>> >>
>> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
>r the
>> >> floating types than the integer types=3D2C because they can't be viewe=
>d
>> >> as having overlapping value sets in any reasonable way.
>> >
>> >=3D20
>> >Huh? This seems to me to be directly opposite of the truth.
>> >LONGREAL is a strict superset of REAL in what it can represent.
>> >There is *complete* overlap.
>> >Am I really mistaken here?
>> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
>> >Right?
>> >=3D20
>> >=3D20
>> > - Jay
>>=20
>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>> 754=2C you're right. Or at least there exists an interpretation of the
>> values that have this property. I alluded earlier to the fact that
>> Alpha represents single-precision by zeroing out the middle of the
>> double-precision register (some of the mantissa and some of the exponent)=
>.
>>=20
>> However I'm sure there are systems for which this is not true. Is=20
>> Modula-3 forbidden from being ported to such machines?
>>=20
>> Mika
> 		 	   		  =
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?<BR>
>&nbsp=3B<BR>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>ng a feature of all CPUs=2C at least ones that have any floating point supp=
>ort? Or any software floating point library?<BR>
>For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>Chances are high they only expose 64bit float and nothing else.<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>I know=2C I know "never say never"=2C but sometimes....?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>Certainly there are also 80bit formats on x86 and 68K.<BR>
>&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>And I think 128bit formats on PowerPC.<BR>
>And something beyond 64bits on IA64 (Itanium).<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>=3B literals are really just ways of writing values=3D2C rather than statin=
>g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>  		  </body>
></html>=
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--


From jay.krell at cornell.edu  Tue Jan 12 07:55:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:55:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>, ,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>,
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>,
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>


IEEE-754 is extremely long standing.

 

But it isn't the issue anyway.

 

The issue is if there exist good candiates for REAL and LONGREAL

such that LONGREAL can losslessly represent all values of REAL.

 

C systems are gradually supporting 3 or more floating point formats.

PowerPC has an optional 128 bit long double.

http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html

 

I wonder if ultimately we should provide "pieces" for people

to define their own types:

 

TYPE Int1 = BITS 32, unsigned, integer, trap overflow;

TYPE Int2 = BITS 64, signed, integer, silent overflow;

TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;

TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;

 

and then provide just a few "canned" "popular" types so that

a lot of code can interoperate with a lot of code, but if a programmer

really needs something else, he has a chance of defining it.

 

Or maybe we can only define what is efficient in hardware, but still

do so with a syntax like this??

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> Date: Mon, 11 Jan 2010 22:42:43 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> Jay K writes:
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?
> 
> x86 (well, x87) is actually very much IEEE 754. It's almost the reference
> implementation. Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly). That's not a non-IEEE format. And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.
> 
> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?
> 
> Mika
> 
> >
> >=20
> >
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
> >ature of all CPUs=2C at least ones that have any floating point support? Or=
> > any software floating point library?
> >
> >For that matter=2C probably Perl and Python=2C but I'd have to check.
> >
> >Chances are high they only expose 64bit float and nothing else.
> >
> >=20
> >
> >=20
> >
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?
> >
> >=20
> >
> >=20
> >
> >I know=2C I know "never say never"=2C but sometimes....?
> >
> >=20
> >
> >=20
> >
> >Certainly there are also 80bit formats on x86 and 68K.
> >
> > Though x86 is moving away from this with SSE/SSE2.
> >
> >And I think 128bit formats on PowerPC.
> >
> >And something beyond 64bits on IA64 (Itanium).
> >
> >=20
> >
> >=20
> >
> > - Jay
> >=20
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Integer literals=20
> >> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
> >> From: mika at async.async.caltech.edu
> >>=20
> >> Jay K writes:
> >> >
> >> >>> One thing I've really struggled with over the introduction of LONGINT=
> > is
> >> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
> >e
> >> >>> literals are really just ways of writing values=3D2C rather than stat=
> >ing
> >> >>> anything about how they should be represented.
> >> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
> >tinct=3D
> >> >=3D2C
> >> >>> but they really do have incompatible value representations).
> >> >>
> >> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
> >r the
> >> >> floating types than the integer types=3D2C because they can't be viewe=
> >d
> >> >> as having overlapping value sets in any reasonable way.
> >> >
> >> >=3D20
> >> >Huh? This seems to me to be directly opposite of the truth.
> >> >LONGREAL is a strict superset of REAL in what it can represent.
> >> >There is *complete* overlap.
> >> >Am I really mistaken here?
> >> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
> >> >Right?
> >> >=3D20
> >> >=3D20
> >> > - Jay
> >>=20
> >> Jay=2C I think if you have hardware that's strictly compliant with IEEE
> >> 754=2C you're right. Or at least there exists an interpretation of the
> >> values that have this property. I alluded earlier to the fact that
> >> Alpha represents single-precision by zeroing out the middle of the
> >> double-precision register (some of the mantissa and some of the exponent)=
> >.
> >>=20
> >> However I'm sure there are systems for which this is not true. Is=20
> >> Modula-3 forbidden from being ported to such machines?
> >>=20
> >> Mika
> > =
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Verdana
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?<BR>
> >&nbsp=3B<BR>
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
> >ng a feature of all CPUs=2C at least ones that have any floating point supp=
> >ort? Or any software floating point library?<BR>
> >For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
> >Chances are high they only expose 64bit float and nothing else.<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >I know=2C I know "never say never"=2C but sometimes....?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >Certainly there are also 80bit formats on x86 and 68K.<BR>
> >&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
> >And I think 128bit formats on PowerPC.<BR>
> >And something beyond 64bits on IA64 (Itanium).<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> > m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
> >R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
> >.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
> >gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
> >oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
> >iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
> >=3B literals are really just ways of writing values=3D2C rather than statin=
> >g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
> >d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
> >ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
> >t=3B&gt=3B but they really do have incompatible value representations).<BR>=
> >&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
> >ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> > types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
> >gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
> >=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
> >e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
> >rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
> >overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
> >g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
> >Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
> >R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
> >pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> > interpretation of the<BR>&gt=3B values that have this property. I alluded =
> >earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
> >oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> > mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
> >there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
> >den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> =
> > </body>
> ></html>=
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/60619ac5/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 09:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 08:00:41 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W53BC0E8E635AB782E72BD8E66C0@phx.gbl>


 > Also, in case anyone is interested
> the current HEAD fails to compile the following packages on Windows Vista:
> m3core, libm3, m3tk

 

It works for me. On XP, but same thing.

Be sure to run upgrade.py to first update the compiler.

An older compiler cannot build a current m3core and/or libm3.

I got errors in Convert.m3 for example.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 23:09:46 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal





  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/557b4a5b/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 10:23:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 09:23:00 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>


I propose that integer signed overflow always raise an immediate exception.

Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.

For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

 

 

I propose that FloatMode's integer features not be the way forward.

 

 

There are two implementation strategies.

 

 

 - "check the carry flag"

   A processor-specific thing, but possibly something easy for the gcc backend to do.

   And very likely easy for the integrated backend.

   Probably very efficient.

 

 

 - internally generate function calls for every arithmetic operation

   like how sets are implemented

 

 

 Implementing most such functions is easy enough in portable C.

 Or maybe using Modula-3 and interface Word.

 

 

 e.g.

   void add(int a, int b, int* c, int* overflow)

   {

    int d = (a + b);

    /* overflow if input signs are equal and output sign is different;

        if input signs are unequal, overflow is not possible

        positive + positive: expect positive, else overflow

        negative + negative: expect negative, else overflow

        positive + negative: overflow not possible */

    *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

 

   void sub(int a, int b, int* c, int* overflow)

   {

    int d = (a - b);

    /* overflow if input signs are unequal and output sign is different than first input;

        if input signs are equal, overflow is not possible;

        positive - negative: expect positive, overflow if negative

        negative - positive: expect negative, overflow if positive

        positive - positive, negative - negative: overflow not possible */

    *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

#include <limits.h>

 

  void mult(int a, int b, int* c, int* overflow)

  {

    /* do operation in higher precision and check if it fits */

    int64 d = (a * (int64)b);

    *c = (int)d;

    *overflow = (d >= INT_MIN && d <= INT_MAX);

  }

 

/* for interface Word */

  typedef unsigned uint;

 

  void addu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a + b);

    /* overflow if output less than either input */

    *overflow = (d < a);

    *c = d;

 }

 

  void subu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a - b);

    /* overflow if output greater than first input */

    *overflow = (d > a);

    *c = d;

 }

 

  void multu(uint a, uint b, uint* c, int* overflow)

  {

    /* operate at higher precision and see if it fits */

     uint64 d = (a * (uint64)b);

    *overflow = (d <= UINT_MAX);

    *c = (uint)d;

 }

 

 void multLU(uint64 a, uint64 b, uint64* c, int* overflow)

 {

  /* break it down into smaller operations, not shown, but not difficult */

 }

 

 

Yes I know this is inefficient, but such is a possible price of portable safety.

 

 

A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

 

  

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/9a600909/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 10:23:24 +0000
Subject: [M3devel] Change File.i3/Status.size from CARDINAL to
	[0L..LAST(LONGINT)].
In-Reply-To: <20100112102039.C3F672474001@birch.elegosoft.com>
References: <20100112102039.C3F672474001@birch.elegosoft.com>
Message-ID: <COL101-W288784810774F26CD509E0E66C0@phx.gbl>


diff attached (cvs is lame..)

 

 - Jay


 
> Date: Tue, 12 Jan 2010 11:20:39 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/12 11:20:39
> 
> Modified files:
> cm3/m3-db/stable/src/: LogManager.m3 
> cm3/m3-libs/libbuf/src/: Buf.m3 
> cm3/m3-libs/libm3/src/os/Common/: File.i3 
> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 
> SocketPosix.m3 
> cm3/m3-libs/libm3/src/os/WIN32/: FSWin32.m3 FileWin32.m3 
> LazyConsole.m3 
> cm3/m3-libs/libm3/src/rw/: FileRd.m3 FileWr.m3 
> cm3/m3-sys/cm3/src/: WebFile.m3 
> cm3/m3-sys/cm3ide/src/utils/: Buf.m3 
> cm3/m3-sys/fix_nl/src/: Main.m3 
> cm3/m3-sys/m3quake/src/: QScanner.m3 
> cm3/m3-sys/mklib/src/: Main.m3 
> cm3/m3-tools/cmpdir/src/: Main.m3 
> cm3/m3-tools/dirfp/src/: Main.m3 
> cm3/m3-tools/m3tohtml/src/: DBRd.m3 
> 
> Log message:
> Change File.i3/Status.size from CARDINAL to [0L..LAST(LONGINT)].
> (Notice that some code checks if it is < 0, though don't
> confuse that with <= 0.)
> Leave rd/wr essentially unchanged.
> This is probably enough to fix the exception when browsing to a directory with large files.
> Not that much/any code can read/write such files on 32bit system -- all the direct users of File.i3
> appear to read the entire file into memory.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment-0001.txt>

From wagner at elegosoft.com  Tue Jan 12 13:13:05 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 12 Jan 2010 13:13:05 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> Actually, that diagnostic indicates that scc-mailrelay.att.net is   
> blocking messages from the Elegosoft mail server (it is blacklisted!).

Ups, I must have misread that. I should pay better attention.
Mike, can you investigate why we're blacklisted at att?

Thanks,

Olaf

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>
>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous    
>>>> reply, and I'm still waiting. I wonder if the confirmation e-mail  
>>>>   is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From michael.anderson at elego.de  Tue Jan 12 13:52:32 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 13:52:32 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
Message-ID: <20100112135232.hd9dy91casc0g0kk@mail.elego.de>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> Actually, that diagnostic indicates that scc-mailrelay.att.net is    
>> blocking messages from the Elegosoft mail server (it is   
>> blacklisted!).
>
> Ups, I must have misread that. I should pay better attention.
> Mike, can you investigate why we're blacklisted at att?
>

I'm looking into it. I filled out att's unblock form and asked for  
clarification. I don't see anything in logs that looks like abuse from  
our side.  Messages to martinbishop at bellsouth.net have apparently been  
getting bounced by att for some time.

Mike

> Thanks,
>
> Olaf
>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous    
>>>>>  reply, and I'm still waiting. I wonder if the confirmation   
>>>>> e-mail   is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                  The mail system
>>>
>>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>>   521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>>   Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>   command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30   
>>> 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 18:00:04 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 12:00:04 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
References: <20100112064243.6828D1A2078@async.async.caltech.edu>
	<COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
Message-ID: <20100112170003.GA13141@topoi.pooq.com>

On Tue, Jan 12, 2010 at 06:55:27AM +0000, Jay K wrote:
> 
> TYPE Int1 = BITS 32, unsigned, integer, trap overflow;
> 
> TYPE Int2 = BITS 64, signed, integer, silent overflow;
> 
> TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;
> 
> TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;
> 
>  
> 
> and then provide just a few "canned" "popular" types so that
> 
> a lot of code can interoperate with a lot of code, but if a programmer
> 
> really needs something else, he has a chance of defining it.
> 
>  
> 
> Or maybe we can only define what is efficient in hardware, but still
> 
> do so with a syntax like this??

That resembles the approach of C--.  You have to explicitly define the 
precision, byte sex, etc. of your data, and the compiler refuses your 
program if it doesn't match what the machine provides.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 19:31:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:31:46 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <09217458-CE1E-4928-85EE-E8DCC4CC7755@cs.purdue.edu>


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 12 Jan 2010, at 01:42, Mika Nystrom wrote:

> Jay K writes:
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?
> 
> x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
> implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly).  That's not a non-IEEE format.  And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.

That would also be a great project for someone to pick up.  ;-)  Just trying to encourage participation...

> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?

I agree that the spec should be neutral on the formats.  Just as it is about INTEGER and ADDRESS.

> 
>    Mika
> 
>> 
>> =20
>> 
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>> ature of all CPUs=2C at least ones that have any floating point support? Or=
>> any software floating point library?
>> 
>> For that matter=2C probably Perl and Python=2C but I'd have to check.
>> 
>> Chances are high they only expose 64bit float and nothing else.
>> 
>> =20
>> 
>> =20
>> 
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?
>> 
>> =20
>> 
>> =20
>> 
>> I know=2C I know "never say never"=2C but sometimes....?
>> 
>> =20
>> 
>> =20
>> 
>> Certainly there are also 80bit formats on x86 and 68K.
>> 
>> Though x86 is moving away from this with SSE/SSE2.
>> 
>> And I think 128bit formats on PowerPC.
>> 
>> And something beyond 64bits on IA64 (Itanium).
>> 
>> =20
>> 
>> =20
>> 
>> - Jay
>> =20
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Integer literals=20
>>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>>> From: mika at async.async.caltech.edu
>>> =20
>>> Jay K writes:
>>>> 
>>>>>> One thing I've really struggled with over the introduction of LONGINT=
>> is
>>>>>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>> e
>>>>>> literals are really just ways of writing values=3D2C rather than stat=
>> ing
>>>>>> anything about how they should be represented.
>>>>>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>> tinct=3D
>>>> =3D2C
>>>>>> but they really do have incompatible value representations).
>>>>> 
>>>>> I agree=3D2C the need for distinctly typed literals is much greater fo=
>> r the
>>>>> floating types than the integer types=3D2C because they can't be viewe=
>> d
>>>>> as having overlapping value sets in any reasonable way.
>>>> 
>>>> =3D20
>>>> Huh? This seems to me to be directly opposite of the truth.
>>>> LONGREAL is a strict superset of REAL in what it can represent.
>>>> There is *complete* overlap.
>>>> Am I really mistaken here?
>>>> Floating point is indeed very wierd=3D2C but it isn't this wierd.
>>>> Right?
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>> =20
>>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>>> 754=2C you're right. Or at least there exists an interpretation of the
>>> values that have this property. I alluded earlier to the fact that
>>> Alpha represents single-precision by zeroing out the middle of the
>>> double-precision register (some of the mantissa and some of the exponent)=
>> .
>>> =20
>>> However I'm sure there are systems for which this is not true. Is=20
>>> Modula-3 forbidden from being ported to such machines?
>>> =20
>>> Mika
>> 		 	   		  =
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 10pt=3B
>> font-family:Verdana
>> }
>> --></style>
>> </head>
>> <body class=3D'hmmessage'>
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?<BR>
>> &nbsp=3B<BR>
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>> ng a feature of all CPUs=2C at least ones that have any floating point supp=
>> ort? Or any software floating point library?<BR>
>> For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>> Chances are high they only expose 64bit float and nothing else.<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> I know=2C I know "never say never"=2C but sometimes....?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> Certainly there are also 80bit formats on x86 and 68K.<BR>
>> &nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>> And I think 128bit formats on PowerPC.<BR>
>> And something beyond 64bits on IA64 (Itanium).<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
>> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>> R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>> .async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>> gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>> oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>> iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>> =3B literals are really just ways of writing values=3D2C rather than statin=
>> g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>> d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>> ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>> t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>> &gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>> ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
>> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>> gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>> =3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>> e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>> rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>> overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>> g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>> Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>> R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>> pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
>> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>> earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>> oing out the middle of the<BR>&gt=3B double-precision register (some of the=
>> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>> there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>> den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>> 		  </body>
>> </html>=
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/e0a38233/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Jan 12 19:33:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:33:59 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>

On 11 Jan 2010, at 23:55, Jay K wrote:

> I thought FloatMode was only related to floating point.
> So I looked:
>  
>    "IntOverflow" = an integer operation produced a result whose
>    absolute value is too large to be represented.
>  
>    "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
> 
>  
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>  
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

Yes, that's the issue.

>  For the floating point stuff:
>  
> Probably like other per-platform code, this should be done in #ifdefed C.

Agreed...  does that mean you will bite?  ;-)

>  
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/522b2ac7/attachment-0001.html>

From hendrik at topoi.pooq.com  Tue Jan 12 19:55:21 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 13:55:21 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <20100112185520.GA21429@topoi.pooq.com>

On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
> On 11 Jan 2010, at 23:55, Jay K wrote:
> >  
> > Probably like other per-platform code, this should be done in #ifdefed C.
> 
> Agreed...  does that mean you will bite?  ;-)

I seem to remember an ad for Modula 3 once that went something like
 <big number> lines of code, and not a single ifdef!

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 19:59:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 18:59:24 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>


Maybe. But I don't want to prevent anyone else from stepping in.
And I want to bring up more platforms.
My integer implementation might be inefficient.
 
 
I see these as three or possibly more separate areas.
 Integer overflow. 
 Integer divide by zero. 
 Floating point. 
 
 
Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms is probably already "not silent", so not bad.
 
 
I'm not sure about unsigned/Word.T overflow, how that is supposed to be handled. In particular, signed overflow and unsigned overflow are slightly different, and unsigned/Word possibly suggests allowing silent overflow.
 
Again I really see quite a number of options here and programmer should indicate intent via choice of type or interface/function.
Fixed width, trap overflow, silent overflow, extent precision on overflow, etc.
 
 
I was talking to a friend about the integer/longint stuff.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 13:33:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
>
>
> On 11 Jan 2010, at 23:55, Jay K wrote:
>
> I thought FloatMode was only related to floating point.
> So I looked:
>
> "IntOverflow" = an integer operation produced a result whose
> absolute value is too large to be represented.
>
> "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
>
>
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
>
> Yes, that's the issue.
>
> For the floating point stuff:
>
> Probably like other per-platform code, this should be done in #ifdefed C.
>
> Agreed... does that mean you will bite? ;-)
>
>
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>
> - Jay
>
> 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:02:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:02:49 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <20100112185520.GA21429@topoi.pooq.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>,
	<20100112185520.GA21429@topoi.pooq.com>
Message-ID: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>


That's *really* *not* a good thing.
 
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 13:55:21 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>
>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>
>> Agreed... does that mean you will bite? ;-)
>
> I seem to remember an ad for Modula 3 once that went something like
> lines of code, and not a single ifdef!
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:13:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:13:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>, ,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>, ,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>, ,
	<20100112185520.GA21429@topoi.pooq.com>,
	<COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
Message-ID: <COL101-W200C77A1ABE9F1CAA90BCE66C0@phx.gbl>


Instead of the small evil of #ifdefs, we had two large evils:
 
 
 - cloning headers, fragile, tedious, error-prone 
   Though I think generally safe, *if* done *extremely* *carefully* and *correctly*. There is a need for the underlying system to not change. The commercial systems all do that well. 64bit FreeBSD seems to have a poor record at least. NetBSD changes the symbol names maybe often. etc.
 
 
 - cloning nearly identical Modula-3 code many times

 
The second could have been reduced, by making directories keyed by processor 
architecture or kernel, instead of architecture_kernel pairs.
 
 
The first could have been reduced a lot by limiting it to only what we use.
That was what I did at first with Cygwin.
But still.
 
 
By using #ifdefs we have gained a lot of portability and thrown away many lines of code.
 
 
A C generating backend will increase portability another very big step.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 19:02:49 +0000
> Subject: Re: [M3devel] FloatMode
>
>
> That's *really* *not* a good thing.
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 12 Jan 2010 13:55:21 -0500
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>>
>>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>>
>>> Agreed... does that mean you will bite? ;-)
>>
>> I seem to remember an ad for Modula 3 once that went something like
>> lines of code, and not a single ifdef!
>>
>> -- hendrik 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 20:21:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:21:14 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>

On 11 Jan 2010, at 23:09, Randy Coleburn wrote:

> Tony:
>  
> I?m sorry, I missed the fact that you changed the type to ?Integer? vs. ?INTEGER? and defined ?Integer? to be ?INTEGER? or ?LONGINT?.
>  
> I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be ?happy? with this state of affairs.
>  
> I am confused though by your last set of statements, namely:
>  
> >I don't think we need to do this, assuming you understand what I have said above.
> > 
> >ORD(x: INTEGER): LONGINT
> >ORD(x: LONGINT): INTEGER
> >ORD(x: Enumeration): INTEGER
> >ORD(x: Subrange): Base(Subrange)
> > 
> >ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> Didn?t you mean:
>                 ORD(x:INTEGER): INTEGER
>                 ORD(x:LONGINT): LONGINT

Sorry, yes.   Cut/paste error.

>  Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
> "m3-libs\m3core"
> "m3-libs\libm3"
> "m3-tools\m3tk"
> So some recent changes have caused a problem.

Did you bootstrap a new compiler?  You will need to bootstrap a compiler before you can compile the revised ORD/VAL definitions.

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 10:40 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> On 11 Jan 2010, at 22:11, Randy Coleburn wrote:
> 
> 
> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?
>  
> Sorry, my error.  I realised after writing that I had mis-spoken.
> 
> 
>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.
>  
> That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):
>  
> 55,56c55,56
> <               ORD  (element: Ordinal): INTEGER
> <               VAL  (i: INTEGER; T: OrdinalType): T
> ---
> >               ORD  (element: Ordinal): Integer
> >               VAL  (i: Integer; T: OrdinalType): T
> 74c74
> < If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
> ---
> > If n is an integer of type T, ORD(n) = VAL(n, T) = n.
>  
> Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.
> 
> 
>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)
>  
> No, enumerations map only onto INTEGER.
> 
> 
> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).
>  
> I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.
> 
> 
>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!
>  
> Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.
> 
> 
>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)
>  
> No,
>  
> longint := VAL(integer, LONGINT)
> integer := VAL(longint, INTEGER)
> int := ORD(int)
> longint := ORD(longint)
> 
> 
> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 
>  
> This captures the identities precisely, which is why I reverted to the original formulation.
> 
> 
> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)
>  
> Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.
> 
> 
>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);
>  
> That is what is now implemented.
> 
> 
> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.
>  
> No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.
> 
> 
>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.
>  
> ORD now can never cause a checked runtime error, just as with Nelson.
> 
> 
>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?
>  
> Yes, correct.  This is what is now implemented in the CVS head.
> 
> 
>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.
>  
> See above.
> 
> 
> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.
>  
> See above.
>  
> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.
>  
> No assignability!
> 
> 
> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.
>  
> I don't think we need to do this, assuming you understand what I have said above.
>  
> ORD(x: INTEGER): LONGINT
> ORD(x: LONGINT): INTEGER
> ORD(x: Enumeration): INTEGER
> ORD(x: Subrange): Base(Subrange)
>  
> ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> e.      Any other ideas?
>  
> I think we are done...
> 
> 
>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/79a91506/attachment-0001.html>

From mika at async.async.caltech.edu  Tue Jan 12 20:28:07 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:28:07 -0800
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
	<COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>
Message-ID: <20100112192807.055FC1A2079@async.async.caltech.edu>

Jay K writes:
>
>Maybe. But I don't want to prevent anyone else from stepping in.
>And I want to bring up more platforms.
>My integer implementation might be inefficient.
>=20
>=20
>I see these as three or possibly more separate areas.
> Integer overflow.=20
> Integer divide by zero.=20
> Floating point.=20
>=20
>=20
>Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms =
>is probably already "not silent"=2C so not bad.
>=20
>=20
>I'm not sure about unsigned/Word.T overflow=2C how that is supposed to be h=
>andled. In particular=2C signed overflow and unsigned overflow are slightly=
> different=2C and unsigned/Word possibly suggests allowing silent overflow.

Word.T never overflows.  Tons of code depends on this!

Also a lot of machines don't have integer flags, don't forget that.  (Alpha
and MIPS come to mind, although MIPS has an "add-with-exception" instruction.)

     Mika

>=20
>Again I really see quite a number of options here and programmer should ind=
>icate intent via choice of type or interface/function.
>Fixed width=2C trap overflow=2C silent overflow=2C extent precision on over=
>flow=2C etc.
>=20
>=20
>I was talking to a friend about the integer/longint stuff.
>=20
>=20
> - Jay
>
>
>________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 13:33:59 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>>
>>
>> On 11 Jan 2010=2C at 23:55=2C Jay K wrote:
>>
>> I thought FloatMode was only related to floating point.
>> So I looked:
>>
>> "IntOverflow" =3D an integer operation produced a result whose
>> absolute value is too large to be represented.
>>
>> "IntDivByZero" =3D integer "DIV" or "MOD" by zero.
>> \end{quote}
>>
>>
>> This part of it should be easy to implement for all architectures.
>> The entire thing probably isn't too difficult either on many platforms ei=
>ther.
>>
>> However...I was surprised by this.
>> I thought the real "intent" in Modula-3 to not have this be configurable
>> and endeavor for overflow and divide by zero to always immediately
>> raise an exception? The only "out" is that it might not get implemented o=
>n some platforms for some reason?
>>
>> Yes=2C that's the issue.
>>
>> For the floating point stuff:
>>
>> Probably like other per-platform code=2C this should be done in #ifdefed =
>C.
>>
>> Agreed... does that mean you will bite? =3B-)
>>
>>
>> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
>> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
>> etc.
>>
>> - Jay
>>
>> 		 	   		  =


From hosking at cs.purdue.edu  Tue Jan 12 20:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:30:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
Message-ID: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>

On 12 Jan 2010, at 04:23, Jay K wrote:

> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

That is going to pose a performance issue (that many C programmers may baulk at!).

> I propose that FloatMode's integer features not be the way forward.

Why not?

> There are two implementation strategies.
>  
>  
>  - "check the carry flag"
>    A processor-specific thing, but possibly something easy for the gcc backend to do.
>    And very likely easy for the integrated backend.
>    Probably very efficient.

Yes, doable.

>   - internally generate function calls for every arithmetic operation
>    like how sets are implemented

Very bad for performance.  We should rely on the processor support for arithmetic traps or condition variables.


>   Implementing most such functions is easy enough in portable C.
>  Or maybe using Modula-3 and interface Word.

Not the best way going forward...

>   e.g.
>    void add(int a, int b, int* c, int* overflow)
>    {
>     int d = (a + b);
>     /* overflow if input signs are equal and output sign is different;
>         if input signs are unequal, overflow is not possible
>         positive + positive: expect positive, else overflow
>         negative + negative: expect negative, else overflow
>         positive + negative: overflow not possible */
>     *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
>  
>    void sub(int a, int b, int* c, int* overflow)
>    {
>     int d = (a - b);
>     /* overflow if input signs are unequal and output sign is different than first input;
>         if input signs are equal, overflow is not possible;
>         positive - negative: expect positive, overflow if negative
>         negative - positive: expect negative, overflow if positive
>         positive - positive, negative - negative: overflow not possible */
>     *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
> #include <limits.h>
>  
>   void mult(int a, int b, int* c, int* overflow)
>   {
>     /* do operation in higher precision and check if it fits */
>     int64 d = (a * (int64)b);
>     *c = (int)d;
>     *overflow = (d >= INT_MIN && d <= INT_MAX);
>   }
>  
> /* for interface Word */
>   typedef unsigned uint;
>  
>   void addu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a + b);
>     /* overflow if output less than either input */
>     *overflow = (d < a);
>     *c = d;
>  }
>  
>   void subu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a - b);
>     /* overflow if output greater than first input */
>     *overflow = (d > a);
>     *c = d;
>  }
>  
>   void multu(uint a, uint b, uint* c, int* overflow)
>   {
>     /* operate at higher precision and see if it fits */
>      uint64 d = (a * (uint64)b);
>     *overflow = (d <= UINT_MAX);
>     *c = (uint)d;
>  }
>  
>  void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>  {
>   /* break it down into smaller operations, not shown, but not difficult */
>  }
>  
>  
> Yes I know this is inefficient, but such is a possible price of portable safety.
>  
>  
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

FloatMode seems a perfectly reasonable way forward doesn't it?  It allows both trap-based and (with compiler support) checked condition code implementations.

>  
>   
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/8f3c37df/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 12 20:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:46:21 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
Message-ID: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>


I'm not against using "hardware traps", if they exist.
I'll have to do a bunch of research as to their existance.
 
 
 
I don't think one should be able to turn this on or off.
I think it should be static per type or interface/library.
 
 
Even so, if it is a runtime configuration, I realize
that the implementation, on a system
without hardware traps, with a processor-specific
flag would look *like*:
 
 
 check for overflow 
 if no overflow, continue on as usual
 if overflow, call out to a function
   that function:
      fetch the thread local
      depending on *that*, raise an exception or continue on 
 
 
I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
 
 
Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
 
 
That can also be highly portable, mimicing the algorithms I showed.
 
 
The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
 
 
- Jay



________________________________
> Subject: Re: [M3devel] integer overflow
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 14:30:00 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>
>
> On 12 Jan 2010, at 04:23, Jay K wrote:
>
> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>
> That is going to pose a performance issue (that many C programmers may baulk at!).
>
> I propose that FloatMode's integer features not be the way forward.
>
> Why not?
>
> There are two implementation strategies.
>
>
> - "check the carry flag"
> A processor-specific thing, but possibly something easy for the gcc backend to do.
> And very likely easy for the integrated backend.
> Probably very efficient.
>
> Yes, doable.
>
> - internally generate function calls for every arithmetic operation
> like how sets are implemented
>
> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>
>
> Implementing most such functions is easy enough in portable C.
> Or maybe using Modula-3 and interface Word.
>
> Not the best way going forward...
>
> e.g.
> void add(int a, int b, int* c, int* overflow)
> {
> int d = (a + b);
> /* overflow if input signs are equal and output sign is different;
> if input signs are unequal, overflow is not possible
> positive + positive: expect positive, else overflow
> negative + negative: expect negative, else overflow
> positive + negative: overflow not possible */
> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
>
> void sub(int a, int b, int* c, int* overflow)
> {
> int d = (a - b);
> /* overflow if input signs are unequal and output sign is different than first input;
> if input signs are equal, overflow is not possible;
> positive - negative: expect positive, overflow if negative
> negative - positive: expect negative, overflow if positive
> positive - positive, negative - negative: overflow not possible */
> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
> #include
>
> void mult(int a, int b, int* c, int* overflow)
> {
> /* do operation in higher precision and check if it fits */
> int64 d = (a * (int64)b);
> *c = (int)d;
> *overflow = (d>= INT_MIN && d <= INT_MAX);
> }
>
> /* for interface Word */
> typedef unsigned uint;
>
> void addu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a + b);
> /* overflow if output less than either input */
> *overflow = (d < a);
> *c = d;
> }
>
> void subu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a - b);
> /* overflow if output greater than first input */
> *overflow = (d> a);
> *c = d;
> }
>
> void multu(uint a, uint b, uint* c, int* overflow)
> {
> /* operate at higher precision and see if it fits */
> uint64 d = (a * (uint64)b);
> *overflow = (d <= UINT_MAX);
> *c = (uint)d;
> }
>
> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
> {
> /* break it down into smaller operations, not shown, but not difficult */
> }
>
>
> Yes I know this is inefficient, but such is a possible price of portable safety.
>
>
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>
> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 20:57:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:57:52 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <20100112195752.22AC21A2079@async.async.caltech.edu>


Are you actually proposing making range checking mandatory for integer
arithmetic?

I think that's a bad idea... the performance hit could be very high
(especially on some architectures).

The language should already guarantee that problems in this area can't
cause unchecked runtime errors.

     Mika

Jay K writes:
>
>I'm not against using "hardware traps"=2C if they exist.
>I'll have to do a bunch of research as to their existance.
>=20
>=20
>=20
>I don't think one should be able to turn this on or off.
>I think it should be static per type or interface/library.
>=20
>=20
>Even so=2C if it is a runtime configuration=2C I realize
>that the implementation=2C on a system
>without hardware traps=2C with a processor-specific
>flag would look *like*:
>=20
>=20
> check for overflow=20
> if no overflow=2C continue on as usual
> if overflow=2C call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*=2C raise an exception or continue on=20
>=20
>=20
>I suspect I could easily quickly put in place a portable implementation=2C =
>and..like *almost* everything else that isn't I/O bound (other than code si=
>ze issue).
>=20
>=20
>Hm. Actually another very good approach is probably to have the front end i=
>nline most of this logic=2C like everything except 64bit multiplication on =
>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>ly probably competitive. There is already inlining of the computation of th=
>e result=2C and merely passing three parameters won't be cheap.
>=20
>=20
>That can also be highly portable=2C mimicing the algorithms I showed.
>=20
>=20
>The front end can also do the optimization where overflow isn't necessarily=
> checked for every single operation.
>=20
>=20
>- Jay
>
>
>
>________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>>
>>
>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>
>> I propose that integer signed overflow always raise an immediate exceptio=
>n.
>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
> no exceptions at all.
>> For folks that want silent wraparound=2C maybe a separate interface like =
>UnsafeInt.
>>
>> That is going to pose a performance issue (that many C programmers may ba=
>ulk at!).
>>
>> I propose that FloatMode's integer features not be the way forward.
>>
>> Why not?
>>
>> There are two implementation strategies.
>>
>>
>> - "check the carry flag"
>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>kend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>>
>> Yes=2C doable.
>>
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>>
>> Very bad for performance. We should rely on the processor support for ari=
>thmetic traps or condition variables.
>>
>>
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>>
>> Not the best way going forward...
>>
>> e.g.
>> void add(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a + b)=3B
>> /* overflow if input signs are equal and output sign is different=3B
>> if input signs are unequal=2C overflow is not possible
>> positive + positive: expect positive=2C else overflow
>> negative + negative: expect negative=2C else overflow
>> positive + negative: overflow not possible */
>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>>
>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a - b)=3B
>> /* overflow if input signs are unequal and output sign is different than =
>first input=3B
>> if input signs are equal=2C overflow is not possible=3B
>> positive - negative: expect positive=2C overflow if negative
>> negative - positive: expect negative=2C overflow if positive
>> positive - positive=2C negative - negative: overflow not possible */
>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>> #include
>>
>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d =3D (a * (int64)b)=3B
>> *c =3D (int)d=3B
>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>> }
>>
>> /* for interface Word */
>> typedef unsigned uint=3B
>>
>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a + b)=3B
>> /* overflow if output less than either input */
>> *overflow =3D (d < a)=3B
>> *c =3D d=3B
>> }
>>
>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a - b)=3B
>> /* overflow if output greater than first input */
>> *overflow =3D (d> a)=3B
>> *c =3D d=3B
>> }
>>
>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d =3D (a * (uint64)b)=3B
>> *overflow =3D (d <=3D UINT_MAX)=3B
>> *c =3D (uint)d=3B
>> }
>>
>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>> {
>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>t */
>> }
>>
>>
>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>e safety.
>>
>>
>> A hybrid is probably possible if the gcc backend support must be processo=
>r specific and we gradually provide the implementations.
>>
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>both trap-based and (with compiler support) checked condition code implemen=
>tations.
>>
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>> 		 	   		  =


From jay.krell at cornell.edu  Tue Jan 12 21:21:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:21:27 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>


Range checking and overflow checking I think are different.
 
 
TYPE T1 = [1..6];
a:T1 := 7; (* range check error *)
b:T1 := 6;
c:T1 := 1;
d:T1 := b + c; (* range check error *)
e:T1 := c - b; (* range check error *)
f:ARRAY [1..4] OF INTEGER;
f[b] := 0; (* range check error *)
g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
 
 
But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
 
 
Initially it'll probably be a command line option or such.
 
 
Or maybe it isn't a safety issue?
As long as one has checks on array indexing? Which I'm sure we do.
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 12 Jan 2010 11:57:52 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
>
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
>
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).
>
> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.
>
> Mika
>
> Jay K writes:
>>
>>I'm not against using "hardware traps"=2C if they exist.
>>I'll have to do a bunch of research as to their existance.
>>=20
>>=20
>>=20
>>I don't think one should be able to turn this on or off.
>>I think it should be static per type or interface/library.
>>=20
>>=20
>>Even so=2C if it is a runtime configuration=2C I realize
>>that the implementation=2C on a system
>>without hardware traps=2C with a processor-specific
>>flag would look *like*:
>>=20
>>=20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*=2C raise an exception or continue on=20
>>=20
>>=20
>>I suspect I could easily quickly put in place a portable implementation=2C =
>>and..like *almost* everything else that isn't I/O bound (other than code si=
>>ze issue).
>>=20
>>=20
>>Hm. Actually another very good approach is probably to have the front end i=
>>nline most of this logic=2C like everything except 64bit multiplication on =
>>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>>ly probably competitive. There is already inlining of the computation of th=
>>e result=2C and merely passing three parameters won't be cheap.
>>=20
>>=20
>>That can also be highly portable=2C mimicing the algorithms I showed.
>>=20
>>=20
>>The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>>=20
>>=20
>>- Jay
>>
>>
>>
>>________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exceptio=
>>n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>>UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may ba=
>>ulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>>kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes=2C doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for ari=
>>thmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>>
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>>first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>> #include
>>>
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>>
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>>
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>>t */
>>> }
>>>
>>>
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>>e safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processo=
>>r specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>>both trap-based and (with compiler support) checked condition code implemen=
>>tations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 21:27:06 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 12:27:06 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112202706.C98571A2079@async.async.caltech.edu>

Jay K writes:
>
>Range checking and overflow checking I think are different.
>=20
>=20
>TYPE T1 =3D [1..6]=3B
>a:T1 :=3D 7=3B (* range check error *)
>b:T1 :=3D 6=3B
>c:T1 :=3D 1=3B
>d:T1 :=3D b + c=3B (* range check error *)
>e:T1 :=3D c - b=3B (* range check error *)
>f:ARRAY [1..4] OF INTEGER=3B
>f[b] :=3D 0=3B (* range check error *)
>g:INTEGER :=3D LAST(INTEGER) - 5 + a=3B (* overflow *)
>=20
>=20
>But anyway=2C yes it will be slower=2C but I believe it should be mandatory=
>=2C at least in safe modules=2C it is needed for safety=2C and I doubt it'l=
>l be *noticably* slower for the vast majority of code.
>=20
>=20
>Initially it'll probably be a command line option or such.
>=20
>=20
>Or maybe it isn't a safety issue?
>As long as one has checks on array indexing? Which I'm sure we do.

That was my point.  It shouldn't be a safety issue.  It's orthogonal to the
Modula-3 definition of UNSAFE.

    Mika



From michael.anderson at elego.de  Tue Jan 12 21:35:55 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 21:35:55 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100112213555.v7disk2h44kkcos8@mail.elego.de>

Hi All,

att.net has responded and promised to have us off of their blacklist  
within 48 hours.
I'll inform Chris from another mail server.

Mike

Quoting Randy Coleburn <rcolebur at SCIRES.COM>:

> I also took the liberty of contacting him.  Shown below is my   
> message and his response:
> Regards,
> Randy
>
> On Mon, 11 Jan 2010 12:19:26 -0500
> Randy Coleburn <rcolebur at SCIRES.COM> wrote:
>
>> Just want to let you know that the folks hosting the mail list   
>> service are trying to fulfill your request to be added to the   
>> m3devel mail list.
>>
>> The problem seems to be blacklisting of one of the hosts.  At first  
>>  it seemed your email address was blacklisted, but upon further   
>> investigation it seems your email server   
>> (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has   
>> blacklisted the mail list server at elegosoft.  Note that the   
>> elegosoft server is based in Germany.
>>
>> The server admins are working on the problem, but not sure if/when   
>> it will be resolved.
>>
>> I'm one of the developers and also subscribe to the list and   
>> noticed the traffic about your request, so thought I would try and   
>> send you an email to see if it gets thru and to let you know of the  
>>  problem.
>>
>> Regards,
>> Randy
>>
>
> Thanks for the heads up. I'll give them a call to see what the problem is.
>
> AT&T actually does it's mail hosting through Yahoo mail, so they   
> might actually be the ones doing the blacklisting. I'm going to do   
> some poking around on this end; and I'll send you an email if I find  
>  anything noteworthy.
>
> Thank you.
>
> --
> Chris <dimonax at att.net>
>
>
> -----Original Message-----
> From: John Polstra [mailto:jdp at polstra.com]
> Sent: Monday, January 11, 2010 11:44 PM
> To: Tony Hosking
> Cc: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: CM3 development Inquiry.
>
> I forwarded this to him, and my mail log says it was delivered.
>
> John
>
> Tony Hosking wrote:
>> Actually, that diagnostic indicates that scc-mailrelay.att.net
>> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft
>> mail server (it is blacklisted!).
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu
>>> <mailto:hosking at cs.purdue.edu>>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous
>>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail
>>>>>  is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com
>>> <http://mx0.elegosoft.com>.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                   The mail system
>>>
>>> <dimonax at att.net <mailto:dimonax at att.net>>: host
>>> scc-mailrelay.att.net[204.127.208.75] said:
>>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521
>>> DNSRBL:
>>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>    command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
>>> 86 95
>>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>
>>
>



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 21:37:49 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 15:37:49 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112203749.GA27597@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
> 
> Range checking and overflow checking I think are different.
>  
>  
> TYPE T1 = [1..6];
> a:T1 := 7; (* range check error *)
> b:T1 := 6;
> c:T1 := 1;
> d:T1 := b + c; (* range check error *)
> e:T1 := c - b; (* range check error *)
> f:ARRAY [1..4] OF INTEGER;
> f[b] := 0; (* range check error *)
> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>  
>  
> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>  
>  
> Initially it'll probably be a command line option or such.
>  
>  
> Or maybe it isn't a safety issue?
> As long as one has checks on array indexing? Which I'm sure we do.

I always thought one of the points about declared ranges (instead of 
making everything just int, as C does) was to enable one to suppress 
most of the array indexing checks safely.

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 21:51:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:51:46 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112203749.GA27597@topoi.pooq.com>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>,
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>,
	<20100112203749.GA27597@topoi.pooq.com>
Message-ID: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>


> subranges allow suppressing array index checks
 
I didn't know that.
Sounds reasonable.
I haven't contradicted it, have I?
 
 
That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.
 
Gotta go,
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 15:37:49 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
>>
>> Range checking and overflow checking I think are different.
>>
>>
>> TYPE T1 = [1..6];
>> a:T1 := 7; (* range check error *)
>> b:T1 := 6;
>> c:T1 := 1;
>> d:T1 := b + c; (* range check error *)
>> e:T1 := c - b; (* range check error *)
>> f:ARRAY [1..4] OF INTEGER;
>> f[b] := 0; (* range check error *)
>> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>>
>>
>> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>>
>>
>> Initially it'll probably be a command line option or such.
>>
>>
>> Or maybe it isn't a safety issue?
>> As long as one has checks on array indexing? Which I'm sure we do.
>
> I always thought one of the points about declared ranges (instead of
> making everything just int, as C does) was to enable one to suppress
> most of the array indexing checks safely.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Tue Jan 12 22:17:00 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 16:17:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
References: <20100112203749.GA27597@topoi.pooq.com>
	<COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
Message-ID: <20100112211700.GA29801@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:51:46PM +0000, Jay K wrote:
> 
> > subranges allow suppressing array index checks
>  
> I didn't know that.
> Sounds reasonable.
> I haven't contradicted it, have I?

No.  Assignments to subrange variables can be a lot less frequent than 
the use of those variables as subscripts, especially in, say, 
matrix-handling code.

>  
>  
> That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
> Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.

Might not have to check the lower bound at all.
Might only have to check the upper bound when you have to anyway in the 
loop control.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 23:02:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:02:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <E48D174B-D53C-4D58-8F13-10B450ED3437@cs.purdue.edu>

On 12 Jan 2010, at 14:57, Mika Nystrom wrote:

> 
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
> 
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).

I agree.

> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.

It does.

> 
>     Mika
> 
> Jay K writes:
>> 
>> I'm not against using "hardware traps"=2C if they exist.
>> I'll have to do a bunch of research as to their existance.
>> =20
>> =20
>> =20
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>> =20
>> =20
>> Even so=2C if it is a runtime configuration=2C I realize
>> that the implementation=2C on a system
>> without hardware traps=2C with a processor-specific
>> flag would look *like*:
>> =20
>> =20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>>  that function:
>>     fetch the thread local
>>     depending on *that*=2C raise an exception or continue on=20
>> =20
>> =20
>> I suspect I could easily quickly put in place a portable implementation=2C =
>> and..like *almost* everything else that isn't I/O bound (other than code si=
>> ze issue).
>> =20
>> =20
>> Hm. Actually another very good approach is probably to have the front end i=
>> nline most of this logic=2C like everything except 64bit multiplication on =
>> 32bit platform. At first I though that'd be too bloating=2C but it's actual=
>> ly probably competitive. There is already inlining of the computation of th=
>> e result=2C and merely passing three parameters won't be cheap.
>> =20
>> =20
>> That can also be highly portable=2C mimicing the algorithms I showed.
>> =20
>> =20
>> The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>> =20
>> =20
>> - Jay
>> 
>> 
>> 
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> 
>>> 
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>> 
>>> I propose that integer signed overflow always raise an immediate exceptio=
>> n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>> UnsafeInt.
>>> 
>>> That is going to pose a performance issue (that many C programmers may ba=
>> ulk at!).
>>> 
>>> I propose that FloatMode's integer features not be the way forward.
>>> 
>>> Why not?
>>> 
>>> There are two implementation strategies.
>>> 
>>> 
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>> kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>> 
>>> Yes=2C doable.
>>> 
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>> 
>>> Very bad for performance. We should rely on the processor support for ari=
>> thmetic traps or condition variables.
>>> 
>>> 
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>> 
>>> Not the best way going forward...
>>> 
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> 
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>> first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> #include
>>> 
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>> 
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>> 
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>> 
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>> t */
>>> }
>>> 
>>> 
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>> e safety.
>>> 
>>> 
>>> A hybrid is probably possible if the gcc backend support must be processo=
>> r specific and we gradually provide the implementations.
>>> 
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>> both trap-based and (with compiler support) checked condition code implemen=
>> tations.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 		 	   		  =



From hosking at cs.purdue.edu  Tue Jan 12 23:09:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:09:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>

On 12 Jan 2010, at 14:46, Jay K wrote:

> I'm not against using "hardware traps", if they exist.
> I'll have to do a bunch of research as to their existence.

Their existence is why FloatMode was designed in the first place.

> I don't think one should be able to turn this on or off.
> I think it should be static per type or interface/library.

I disagree.  You are conflating language safety with what the semantics of arithmetic should be.  The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C).  Overflow doesn't create a "bad" value for an INTEGER.  It is still an INTEGER value.  It is just that the value is obtained by overflowed arithmetic in the hardware.


> Even so, if it is a runtime configuration, I realize
> that the implementation, on a system
> without hardware traps, with a processor-specific
> flag would look *like*:
> 
> 
> check for overflow 
> if no overflow, continue on as usual
> if overflow, call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*, raise an exception or continue on 

Why do you assume we would even support thread-local handling of overflow?    If we did, I would argue that the code would be more like:

check if this thread cares about overflow
if it does then check the overflow flag and raise an exception if it is set

> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
> 
> 
> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.

The inline sequence would be quite cheap if we really needed to go that route.

> That can also be highly portable, mimicing the algorithms I showed.
> 
> 
> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.

Correct.  It is never needed for subranges that don't include the extremes of the integer representation.

> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> 
>> 
>> On 12 Jan 2010, at 04:23, Jay K wrote:
>> 
>> I propose that integer signed overflow always raise an immediate exception.
>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>> 
>> That is going to pose a performance issue (that many C programmers may baulk at!).
>> 
>> I propose that FloatMode's integer features not be the way forward.
>> 
>> Why not?
>> 
>> There are two implementation strategies.
>> 
>> 
>> - "check the carry flag"
>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>> 
>> Yes, doable.
>> 
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>> 
>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>> 
>> 
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>> 
>> Not the best way going forward...
>> 
>> e.g.
>> void add(int a, int b, int* c, int* overflow)
>> {
>> int d = (a + b);
>> /* overflow if input signs are equal and output sign is different;
>> if input signs are unequal, overflow is not possible
>> positive + positive: expect positive, else overflow
>> negative + negative: expect negative, else overflow
>> positive + negative: overflow not possible */
>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> 
>> void sub(int a, int b, int* c, int* overflow)
>> {
>> int d = (a - b);
>> /* overflow if input signs are unequal and output sign is different than first input;
>> if input signs are equal, overflow is not possible;
>> positive - negative: expect positive, overflow if negative
>> negative - positive: expect negative, overflow if positive
>> positive - positive, negative - negative: overflow not possible */
>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> #include
>> 
>> void mult(int a, int b, int* c, int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d = (a * (int64)b);
>> *c = (int)d;
>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>> }
>> 
>> /* for interface Word */
>> typedef unsigned uint;
>> 
>> void addu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a + b);
>> /* overflow if output less than either input */
>> *overflow = (d < a);
>> *c = d;
>> }
>> 
>> void subu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a - b);
>> /* overflow if output greater than first input */
>> *overflow = (d> a);
>> *c = d;
>> }
>> 
>> void multu(uint a, uint b, uint* c, int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d = (a * (uint64)b);
>> *overflow = (d <= UINT_MAX);
>> *c = (uint)d;
>> }
>> 
>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>> {
>> /* break it down into smaller operations, not shown, but not difficult */
>> }
>> 
>> 
>> Yes I know this is inefficient, but such is a possible price of portable safety.
>> 
>> 
>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>> 
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Tue Jan 12 23:51:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 22:51:29 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
Message-ID: <COL101-W272903528EBD5811FFF56CE66C0@phx.gbl>


I didn't think many processors offered integer overflow "traps".
I'm so used to condition flags being the way, on x86, PowerPC, 6502, etc.
  (6502 it turns out is awful, but you don't realize you are in the insane asylum until you leave it; signed comparisons required doing an actual "destructive" subtract, the "compare" instruction only "works" for unsigned comparisons) 
 
 
Divide by zero and floating point I'm more familiar with.
  Though I think x86 and PowerPC vary on that point -- integer divide by zero.
  I think that was mentioned on the "let's change architectures yet again" guide.
 
 
The reason you'd check for overflow before you'd check if the thread cares about overflow, is that the first is probably *much* cheaper and yields "true" much less often. Checking if the thread cares about trapping overflow requires getting a thread local. Checking for overflow on x86 is typically one conditional branch I believe. Or maybe a "cmove", probably cheaper.
 
 
Granted, if you get the address of the thread locals only upon entry (such as in a function with TRY!) and you only check the bit when there hasn't been a function call (such as to possibly change the setting), then the check isn't too too bad. Still, one conditional branch, encoded to be predicted correctly (whichever way that is..), seems cheap. Plus there might be a reasonable way to "accumulate" overflow that is even cheaper. Like, having a local overflow variable and if you have e := a + b + c + d, do like:
 
 
  overflow = 0;  
  e = a + b;  
  overflow += carry;  
  e += c;  
  overflow += carry;  
  e += d;  
  overflow += carry;  
  if overflow raise 
 
 
might be cheaper than:
  overflow = 0;  
  e = a + b;  
  if overflow raise 
  e += c;  
  if overflow raise 
  e += d;  
  if overflow raise 
 
 
 
I really thought that detecting/trapping integer overflow was part of being safe. It seems I was very mistaken.
So I guess any work here is really not so important as I thought?
Someone convince me that it is actually important?
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 17:09:36 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On 12 Jan 2010, at 14:46, Jay K wrote:
>
>> I'm not against using "hardware traps", if they exist.
>> I'll have to do a bunch of research as to their existence.
>
> Their existence is why FloatMode was designed in the first place.
>
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>
> I disagree. You are conflating language safety with what the semantics of arithmetic should be. The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C). Overflow doesn't create a "bad" value for an INTEGER. It is still an INTEGER value. It is just that the value is obtained by overflowed arithmetic in the hardware.
>
>
>> Even so, if it is a runtime configuration, I realize
>> that the implementation, on a system
>> without hardware traps, with a processor-specific
>> flag would look *like*:
>>
>>
>> check for overflow
>> if no overflow, continue on as usual
>> if overflow, call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*, raise an exception or continue on
>
> Why do you assume we would even support thread-local handling of overflow? If we did, I would argue that the code would be more like:
>
> check if this thread cares about overflow
> if it does then check the overflow flag and raise an exception if it is set
>
>> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
>>
>>
>> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
>
> The inline sequence would be quite cheap if we really needed to go that route.
>
>> That can also be highly portable, mimicing the algorithms I showed.
>>
>>
>> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
>
> Correct. It is never needed for subranges that don't include the extremes of the integer representation.
>
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010, at 04:23, Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exception.
>>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may baulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes, doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a + b);
>>> /* overflow if input signs are equal and output sign is different;
>>> if input signs are unequal, overflow is not possible
>>> positive + positive: expect positive, else overflow
>>> negative + negative: expect negative, else overflow
>>> positive + negative: overflow not possible */
>>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>>
>>> void sub(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a - b);
>>> /* overflow if input signs are unequal and output sign is different than first input;
>>> if input signs are equal, overflow is not possible;
>>> positive - negative: expect positive, overflow if negative
>>> negative - positive: expect negative, overflow if positive
>>> positive - positive, negative - negative: overflow not possible */
>>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>> #include
>>>
>>> void mult(int a, int b, int* c, int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d = (a * (int64)b);
>>> *c = (int)d;
>>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint;
>>>
>>> void addu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a + b);
>>> /* overflow if output less than either input */
>>> *overflow = (d < a);
>>> *c = d;
>>> }
>>>
>>> void subu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a - b);
>>> /* overflow if output greater than first input */
>>> *overflow = (d> a);
>>> *c = d;
>>> }
>>>
>>> void multu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d = (a * (uint64)b);
>>> *overflow = (d <= UINT_MAX);
>>> *c = (uint)d;
>>> }
>>>
>>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>>> {
>>> /* break it down into smaller operations, not shown, but not difficult */
>>> }
>>>
>>>
>>> Yes I know this is inefficient, but such is a possible price of portable safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 00:02:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 23:02:58 +0000
Subject: [M3devel] integer overflow and for loops
Message-ID: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>


http://www.roland-illig.de/articles/modula-3-for-loop.pdf





  		 	   		  

From hosking at cs.purdue.edu  Wed Jan 13 03:18:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:18:59 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>

> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

This assumes that overflow checks should be defined on integers in the language.  Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language.  I think this is an unacceptable overhead for a systems programming language.  C does not have it.  The characteristics of restricted range integer arithmetic are well understood.  If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).



From rcolebur at SCIRES.COM  Wed Jan 13 03:23:04 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:23:04 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>

Ok, I thought I understood this, but now I'm not sure.

I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.

I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle

Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.

Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\m3core
                package C:\cm3\Sandbox\m3-libs\libm3
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle
                package C:\cm3\Sandbox\m3-sys\mklib

The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Q1:  So, am I to infer that in the process of "bootstrapping" a new compiler using an old one, that you have to leave out "m3core" and "libm3" on the first pass, or is there some other logic going on here?

Q2:  Next, if "m3staloneback" and "m3bundle" are needed, shouldn't they be listed as part of the "front" group in pkginfo.txt?

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/44324723/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan 13 03:30:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:30:49 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>

On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:

> Ok, I thought I understood this, but now I?m not sure.
>  
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay?s upgrade.py to see what it does.
>  
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>  
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>  
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
>  
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>  
> Q1:  So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?

It has to do with bootstrapping the compiler to implement feature FOO.  Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries.  First you build a compiler that can compiler FOO (using the old libraries).  Then you make the FOO change to the libraries, and recompile the compiler against the new libraries.  Now both libraries and compiler are FOO-capable.  Carry on...

> Q2:  Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?

They aren't actually needed here.  Not sure why they are included.  Nor is import-libs unless on Windows perhaps.

>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/897e86ba/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 13 03:57:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 02:57:07 +0000
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>,
	<2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
Message-ID: <COL101-W132DFD4126C48933CFAA6DE66B0@phx.gbl>


m3stalonebak I think is never used, agreed.
m3bundle I don't remember why I put it there.
 
 
  Probably because in upgrade.sh or such, there was logic like if m3bundle not found in path, build it fairly early. Something like that. A lot of this is based on what the *.sh files did/do, though there is also divergence/improvement/regression.
  - The *.sh files accept additional cm3 parameters, *.py not yet.
  - The *.sh files read pkginfo.txt, which I was a vocal proponent of and implemented mostly. The *.py not yet (yeah yeah, I'm a hypocrite.)
(*.py is still arguably better than the older *.sh here, in that the data drivenness of it has less redundancy, e.g. the ordering is only present once).
 
 
import-libs is "self filtering", building it does nothing, successfully, for other targets.
 
 
Agreed.
There is are unavoidable circularities.
 
 
Historically there was also a problem with adding new targets.
If libm3 "knew" about a different list of targets than cm3, then cm3 couldn't build it. Maybe similar with m3core but I think not.
So you had to avoid using your pre-existing cm3 to build a current libm3.
First build cm3, then libm3.
That problem is gone now.
What libm3 actually I think "knew" about was more like the hash ("fingerprint") of an enum that listed all targets, which is about the same as having an exact list (few collisions that aren't also exact matches). Anyway, the list is gone.
 
 
But the circularities are and still can be present.
m3core/libm3 use LONGINT for example, so a sufficiently old cm3 can't compile them.
 
 
This is the nature of writing a system in itself.
Definitely a worthwhile tradeoff.
:)
 
 
 - Jay




________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:30:49 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] two questions on bootstrapping the compiler
>
>
>
> On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:
>
> Ok, I thought I understood this, but now I?m not sure.
>
> I had trouble rebuilding everything due to the recent changes. So, I ran Jay?s upgrade.py to see what it does.
>
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
>
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\m3core
> package C:\cm3\Sandbox\m3-libs\libm3
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
> package C:\cm3\Sandbox\m3-sys\mklib
>
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>
> Q1: So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?
>
> It has to do with bootstrapping the compiler to implement feature FOO. Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries. First you build a compiler that can compiler FOO (using the old libraries). Then you make the FOO change to the libraries, and recompile the compiler against the new libraries. Now both libraries and compiler are FOO-capable. Carry on...
>
> Q2: Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?
>
> They aren't actually needed here. Not sure why they are included. Nor is import-libs unless on Windows perhaps.
>
>
> Regards,
> Randy Coleburn
>
> 		 	   		  

From rcolebur at SCIRES.COM  Wed Jan 13 03:57:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:57:02 -0500
Subject: [M3devel] LONGINT on NT386
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>

Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?

I ask, because currently on Windows, LONGINT has same range as INTEGER.

Is there anything I can do to help?

BYTESIZE(INTEGER) =4
BYTESIZE(CARDINAL)=4
BYTESIZE(LONGINT) =4

FIRST(INTEGER) =-2147483648
LAST (INTEGER) = 2147483647

FIRST(CARDINAL)=0
LAST (CARDINAL)=2147483647

FIRST(LONGINT) =-2147483648
LAST (LONGINT) = 2147483647

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/9c6de4be/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 13 04:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:08:47 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
Message-ID: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>


If isn't needed for safety, then I agree.
I really thought it was needed for safety.
But I do not "argue" that that is true.
I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
 
 
That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
This is a common problem. There are several solutions all with tradeoffs.
It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
I tend to think type/interface are the best options.
 
 
INTERFACE IntegerOverflowOut;
 
 
(* maybe UNTRACED REF := NIL for "compatibility" *)
 
PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;

PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
 
 
INTERFACE IntegerOverflowRaises;
 
EXCEPTION Error;
 
PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
 
 
INTERFACE IntegerOverflowSilent;
 
 
PROCEDURE Add(a,b: INTEGER): INTEGER;
PROCEDURE Sub(a,b: INTEGER): INTEGER;
PROCEDURE Mult(a,b: INTEGER): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT;
PROCEDURE SubLong(a,b: LONGINT): LONGINT;
PROCEDURE MultLong(a,b: LONGINT): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
 
 
Notice how two of the interfaces are "source compatible" and allow
easy switching between them for testing/investigation.
That might be deemed a feature, and provided somehow across all three.
 
 
Is anyone strongly opposed to providing something *like* these in m3core?
Maybe inlined by the compiler?
 
 
You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
 
And sometimes not.
 
 
 - Jay



----------------------------------------
> Subject: Re: [M3devel] integer overflow and for loops
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:18:59 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 04:27:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:27:05 +0000
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>


It's not easy to fix.
I386_MINGWIN is the easiest way actually..
I'll look at it again soon..
Maybe we should have an option where the front end decomposes things?
Or makes function calls?
That is probably a pleasantly nice option.
 
 
 - Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 21:57:02 -0500
> Subject: [M3devel] LONGINT on NT386
>
>
> Ok, so now that we have this LONGINT type, what else needs
> to take place for it to be useful?
>
> I ask, because currently on Windows, LONGINT has same range
> as INTEGER.
>
>
> Is there anything I can do to help?
>
>
>
>
>
>
>
> BYTESIZE(INTEGER) =4
>
> BYTESIZE(CARDINAL)=4
>
> BYTESIZE(LONGINT) =4
>
>
>
> FIRST(INTEGER) =-2147483648
>
> LAST (INTEGER) = 2147483647
>
>
>
> FIRST(CARDINAL)=0
>
> LAST (CARDINAL)=2147483647
>
>
>
> FIRST(LONGINT) =-2147483648
>
> LAST (LONGINT) = 2147483647
>
>
>
>
>
>
>
> Regards,
>
>
>
> Randy Coleburn
>
> 		 	   		  

From roland.illig at gmx.de  Wed Jan 13 08:33:46 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Wed, 13 Jan 2010 08:33:46 +0100
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <4B4D775A.9040603@gmx.de>

Jay K schrieb:
> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

My main point in that article was not the integer overflow but the fact 
of having an ugly sentence like "don't use the FOR loop for large 
numbers" in the language definition. Additionally, one would not expect 
the FOR loop to loop endlessly. These are the things I wanted to fix 
back then.

Roland


From wagner at elegosoft.com  Wed Jan 13 10:43:03 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 13 Jan 2010 10:43:03 +0100
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
Message-ID: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>
>>  Also, in case anyone is interested, the current HEAD fails to   
>> compile the following packages on Windows Vista:
>> "m3-libs\m3core"
>> "m3-libs\libm3"
>> "m3-tools\m3tk"
>> So some recent changes have caused a problem.
>
> Did you bootstrap a new compiler?  You will need to bootstrap a   
> compiler before you can compile the revised ORD/VAL definitions.

So if I understand this correctly, should we finally get to release
5.8, then this compiler won't be able to compile the current trunk
head? That is, not unless we merge this change to the release branch?

Anything else that we should do for 5.8?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed Jan 13 15:25:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:25:14 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <20100113142513.GA25925@topoi.pooq.com>

On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
>  
>  
> INTERFACE IntegerOverflowOut;

While we're at it, should there be a carry out as well?

-- hendrik



From hendrik at topoi.pooq.com  Wed Jan 13 15:32:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:32:32 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100113143232.GB25925@topoi.pooq.com>

On Tue, Jan 12, 2010 at 09:23:04PM -0500, Coleburn, Randy wrote:
> Ok, I thought I understood this, but now I'm not sure.
> 
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.
> 
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
> 
> Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.
> 
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
> 
> The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Also "mklib".

-- hendrik


From hosking at cs.purdue.edu  Wed Jan 13 16:09:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:01 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <8E064BBE-460E-45AE-B08A-82B8AA6A5B16@cs.purdue.edu>

That's because the integrated backed on Windows doesn't currently support LONGINT.  Someone needs to smarten up the code generator to cope with LONGINT.

On 12 Jan 2010, at 21:57, Coleburn, Randy wrote:

> Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?
>  
> I ask, because currently on Windows, LONGINT has same range as INTEGER.
>  
> Is there anything I can do to help?
>  
> BYTESIZE(INTEGER) =4
> BYTESIZE(CARDINAL)=4
> BYTESIZE(LONGINT) =4
> 
> FIRST(INTEGER) =-2147483648
> LAST (INTEGER) = 2147483647
> 
> FIRST(CARDINAL)=0
> LAST (CARDINAL)=2147483647
> 
> FIRST(LONGINT) =-2147483648
> LAST (LONGINT) = 2147483647
>  
> Regards,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/4d5a20cb/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan 13 16:09:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:59 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
Message-ID: <831906E2-A122-4C17-BA03-C0101F4DFE85@cs.purdue.edu>

On 12 Jan 2010, at 22:27, Jay K wrote:

> It's not easy to fix.
> I386_MINGWIN is the easiest way actually..
> I'll look at it again soon..
> Maybe we should have an option where the front end decomposes things?

It is the job of the backend to map to machine types.  Don't go complicating the front-end unnecessarily: compiler design 101.

> Or makes function calls?
> That is probably a pleasantly nice option.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Tue, 12 Jan 2010 21:57:02 -0500
>> Subject: [M3devel] LONGINT on NT386
>> 
>> 
>> Ok, so now that we have this LONGINT type, what else needs
>> to take place for it to be useful?
>> 
>> I ask, because currently on Windows, LONGINT has same range
>> as INTEGER.
>> 
>> 
>> Is there anything I can do to help?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> BYTESIZE(INTEGER) =4
>> 
>> BYTESIZE(CARDINAL)=4
>> 
>> BYTESIZE(LONGINT) =4
>> 
>> 
>> 
>> FIRST(INTEGER) =-2147483648
>> 
>> LAST (INTEGER) = 2147483647
>> 
>> 
>> 
>> FIRST(CARDINAL)=0
>> 
>> LAST (CARDINAL)=2147483647
>> 
>> 
>> 
>> FIRST(LONGINT) =-2147483648
>> 
>> LAST (LONGINT) = 2147483647
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Randy Coleburn
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:14:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:14:52 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <2227245F-1770-4D86-B74A-CEBDA15FCB2D@cs.purdue.edu>

On 13 Jan 2010, at 04:43, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>> 
>>> Also, in case anyone is interested, the current HEAD fails to  compile the following packages on Windows Vista:
>>> "m3-libs\m3core"
>>> "m3-libs\libm3"
>>> "m3-tools\m3tk"
>>> So some recent changes have caused a problem.
>> 
>> Did you bootstrap a new compiler?  You will need to bootstrap a  compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?

Correct.  I suggest we merge the changes to avoid inconsistency.  This will be the first official release with LONGINT in it so let's make sure we make it right before anyone starts actually using it...

> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Wed Jan 13 16:40:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:40:20 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>

I really don't think an interface should support overflow checks for unsigned types.  We have Word.T and Long.T with their current semantics.  To be honest I don't think this is really a high priority right now.

I do have another suggestion for where to direct your energies.  :-)  What about going back to smartening up the integrated backend to generate LONGINT properly on Windows?  As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end.  Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html

We only need the following:

Load Relaxed:  MOV (from memory)
Load Acquire:  MOV (from memory)
Load Seq_Cst:  LOCK XADD(0) // alternative: MFENCE,MOV (from memory)

Store Relaxed: MOV (into memory)
Store Release: MOV (into memory)
Store Seq Cst: LOCK XCHG    // alternative: MOV (into memory),MFENCE

Acquire Fence: <ignore>
Release Fence: <ignore>
Acq_Rel Fence: <ignore>
Seq_Cst Fence: MFENCE

Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).

One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable.  The ops as currently defined do not take an offset.  This would permit more efficient addressing modes for the instructions just like regular loads/stores.

On 12 Jan 2010, at 22:08, Jay K wrote:

> 
> If isn't needed for safety, then I agree.
> I really thought it was needed for safety.
> But I do not "argue" that that is true.
> I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> 
> 
> That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> This is a common problem. There are several solutions all with tradeoffs.
> It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> I tend to think type/interface are the best options.
> 
> 
> INTERFACE IntegerOverflowOut;
> 
> 
> (* maybe UNTRACED REF := NIL for "compatibility" *)
> 
> PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> 
> 
> INTERFACE IntegerOverflowRaises;
> 
> EXCEPTION Error;
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> 
> 
> INTERFACE IntegerOverflowSilent;
> 
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER;
> PROCEDURE Sub(a,b: INTEGER): INTEGER;
> PROCEDURE Mult(a,b: INTEGER): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> 
> 
> Notice how two of the interfaces are "source compatible" and allow
> easy switching between them for testing/investigation.
> That might be deemed a feature, and provided somehow across all three.
> 
> 
> Is anyone strongly opposed to providing something *like* these in m3core?
> Maybe inlined by the compiler?
> 
> 
> You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> 
> And sometimes not.
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] integer overflow and for loops
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 21:18:59 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>> 
>> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:47:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:47:19 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <4B4D775A.9040603@gmx.de>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>
Message-ID: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> 
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
> 
> Roland



From rcolebur at SCIRES.COM  Wed Jan 13 17:41:44 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 11:41:44 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>,
	<F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD7F1902@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland

From rcolebur at SCIRES.COM  Wed Jan 13 19:00:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 13:00:02 -0500
Subject: [M3devel] integer overflow and for loops
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E412@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland


From jay.krell at cornell.edu  Wed Jan 13 22:39:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:39:34 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
Message-ID: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>


Agreed. I might have more a clue this time around for LONGINT/NT386.

I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:

    last_imm   : INTEGER := 0;
    lowbound   : INTEGER := FIRST (INTEGER);
    upbound    : INTEGER := LAST (INTEGER);


Something is bugging me a bit though.

Is TInt also used to hold LONGINT values for 32bit targets?

 

I'll look into the atomics too.

It's easy, because in particular, we can just be overly strict on the memory model.

Boehm's prototype already is -- using full barriers where only release/acquire is called for.

 

mfence is a "relatively new" instruction. We are ok with that?

 

I'll try to report back later about the offset question.

I'll compile some C examples and see what addressing modes get used. :)

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 10:40:20 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> 
> I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> 
> We only need the following:
> 
> Load Relaxed: MOV (from memory)
> Load Acquire: MOV (from memory)
> Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> 
> Store Relaxed: MOV (into memory)
> Store Release: MOV (into memory)
> Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> 
> Acquire Fence: <ignore>
> Release Fence: <ignore>
> Acq_Rel Fence: <ignore>
> Seq_Cst Fence: MFENCE
> 
> Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> 
> One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> 
> On 12 Jan 2010, at 22:08, Jay K wrote:
> 
> > 
> > If isn't needed for safety, then I agree.
> > I really thought it was needed for safety.
> > But I do not "argue" that that is true.
> > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > 
> > 
> > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > This is a common problem. There are several solutions all with tradeoffs.
> > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > I tend to think type/interface are the best options.
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> > 
> > 
> > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > 
> > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > 
> > 
> > INTERFACE IntegerOverflowRaises;
> > 
> > EXCEPTION Error;
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > 
> > 
> > INTERFACE IntegerOverflowSilent;
> > 
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > 
> > 
> > Notice how two of the interfaces are "source compatible" and allow
> > easy switching between them for testing/investigation.
> > That might be deemed a feature, and provided somehow across all three.
> > 
> > 
> > Is anyone strongly opposed to providing something *like* these in m3core?
> > Maybe inlined by the compiler?
> > 
> > 
> > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > 
> > And sometimes not.
> > 
> > 
> > - Jay
> > 
> > 
> > 
> > ----------------------------------------
> >> Subject: Re: [M3devel] integer overflow and for loops
> >> From: hosking at cs.purdue.edu
> >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> >> CC: m3devel at elegosoft.com
> >> To: jay.krell at cornell.edu
> >> 
> >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> >> 
> >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/456d6837/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 13 22:45:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:45:17 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>


Yes and no. I was thinking about this too.

In general this "race" never ends.

However:

  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"

   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

 

  - the "race" should actually "slow down" now that I fixed the platform list problem :)

     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use

     (to be clear, the "front" group needs to be more careful about using more features;

     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

 

 

If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.

They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/b0ca354d/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan 13 22:53:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 16:53:19 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
Message-ID: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>

On 13 Jan 2010, at 16:45, Jay K wrote:

> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

We should merge head back to release for LONGINT as it is now (more consistently) implemented.

>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.

I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.

>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

That would be good too.

>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/45b4c7b7/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 13 22:58:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:58:55 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <20100113142513.GA25925@topoi.pooq.com>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<20100113142513.GA25925@topoi.pooq.com>
Message-ID: <COL101-W5136334F62E4E28C53D39BE66B0@phx.gbl>


I believe it is the same thing. As long as you still compute the lower bits correctly.

There should also be carry in.

And check if the arithmetic library doesn't already provide this stuff.

 

 

You might also provide a library, where, at least for add/sub, signed and unsigned

operations are merged but two extra bits are output: "signed overflow" and "unsigned overflow".

Probably all processors do that in one add/sub instruction that produces at least

2 status flags.

"signed overflow" is the "second to last carry bit" as I recall.

"unsigned overflow" is merely the "last carry bit".

 

 

Another way to look at it is that there is signed overflow if there was

carry into the sign bit.

 

 

Another implementation choice is what lower bits to return if there is overflow.

I had a "new idea" that you might as well just always use the direct

implementation to compute the lower bits. It's a little extra work

in the highest precision multiplication case but probably ok.

That is -- look at hand.c, how m3_mult_u64 throws away the

result of the last m3_add_u64.

 

Someone should also write a bunch of code with these things and then

argue for operator overloading in the language. :)

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 09:25:14 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> 
> While we're at it, should there be a carry out as well?
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/1cc7e05e/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 13 23:39:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 22:39:53 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>


Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

I kind of think Target.Int should remain being implemented as an array of 8 bit integers.

That preserves flexibility of targeting basically "anything from anything".

 

 

Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.

  Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.

 

 

As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

I think it's a pretty simple fix.

 

 

There is still a bug targeting 64bit from 32bit because of this.

The attempts to declare "maximally sized arrays" fails.

m3core has a hack where it uses 2GB or 4GB instead of the real max.

The "jvideo" package still fails to cross compile.

 

 

 - Jay
 


Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
From: hosking at cs.purdue.edu
Date: Wed, 13 Jan 2010 16:53:19 -0500
CC: wagner at elegosoft.com; m3devel at elegosoft.com
To: jay.krell at cornell.edu




On 13 Jan 2010, at 16:45, Jay K wrote:


Yes and no. I was thinking about this too.
In general this "race" never ends.
However:
  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)



We should merge head back to release for LONGINT as it is now (more consistently) implemented.


  - the "race" should actually "slow down" now that I fixed the platform list problem :)
     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
     (to be clear, the "front" group needs to be more careful about using more features;
     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).



Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.


I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.


 If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).



That would be good too.


 
 
 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/c982b40d/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 02:05:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:05:10 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
	<COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
Message-ID: <D3FCB564-EA7A-441C-B5E7-1DAEB00CDA77@cs.purdue.edu>

On 13 Jan 2010, at 16:39, Jay K wrote:

> Agreed. I might have more a clue this time around for LONGINT/NT386.
> I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:
>     last_imm   : INTEGER := 0;
>     lowbound   : INTEGER := FIRST (INTEGER);
>     upbound    : INTEGER := LAST (INTEGER);
> 
> Something is bugging me a bit though.
> Is TInt also used to hold LONGINT values for 32bit targets?

Yes, but the range is dictated by the n field of TInt.  So, you'd need to have 8-byte TInt for 64-bit LONGINT.

>  I'll look into the atomics too.
> It's easy, because in particular, we can just be overly strict on the memory model.

Correct: x86 is closest to SC.

> Boehm's prototype already is -- using full barriers where only release/acquire is called for.

Right.

>  mfence is a "relatively new" instruction. We are ok with that?

Our targets that support this should probably be equivalent of "-arch i686" (gcc flag) and above.  Notice that targets can always revert to locks to implement things.

>  I'll try to report back later about the offset question.
> I'll compile some C examples and see what addressing modes get used. :)

:-)

>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Wed, 13 Jan 2010 10:40:20 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] integer overflow and for loops
> > 
> > I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> > 
> > I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64:http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> > 
> > We only need the following:
> > 
> > Load Relaxed: MOV (from memory)
> > Load Acquire: MOV (from memory)
> > Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> > 
> > Store Relaxed: MOV (into memory)
> > Store Release: MOV (into memory)
> > Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> > 
> > Acquire Fence: <ignore>
> > Release Fence: <ignore>
> > Acq_Rel Fence: <ignore>
> > Seq_Cst Fence: MFENCE
> > 
> > Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> > 
> > One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> > 
> > On 12 Jan 2010, at 22:08, Jay K wrote:
> > 
> > > 
> > > If isn't needed for safety, then I agree.
> > > I really thought it was needed for safety.
> > > But I do not "argue" that that is true.
> > > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > > 
> > > 
> > > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > > This is a common problem. There are several solutions all with tradeoffs.
> > > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > > I tend to think type/interface are the best options.
> > > 
> > > 
> > > INTERFACE IntegerOverflowOut;
> > > 
> > > 
> > > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > > 
> > > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > 
> > > 
> > > INTERFACE IntegerOverflowRaises;
> > > 
> > > EXCEPTION Error;
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > 
> > > 
> > > INTERFACE IntegerOverflowSilent;
> > > 
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > > 
> > > 
> > > Notice how two of the interfaces are "source compatible" and allow
> > > easy switching between them for testing/investigation.
> > > That might be deemed a feature, and provided somehow across all three.
> > > 
> > > 
> > > Is anyone strongly opposed to providing something *like* these in m3core?
> > > Maybe inlined by the compiler?
> > > 
> > > 
> > > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > > 
> > > And sometimes not.
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > > ----------------------------------------
> > >> Subject: Re: [M3devel] integer overflow and for loops
> > >> From: hosking at cs.purdue.edu
> > >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> > >> CC: m3devel at elegosoft.com
> > >> To: jay.krell at cornell.edu
> > >> 
> > >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> > >> 
> > >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> > >> 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/7be48d81/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 02:35:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:35:45 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
Message-ID: <2ED96294-8D8F-4F73-8B5E-C7EA588D5A85@cs.purdue.edu>

On 13 Jan 2010, at 17:39, Jay K wrote:

> Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

It's a possibility except for overflow checks, etc. on compile-time constant folding, so perhaps not.

> I kind of think Target.Int should remain being implemented as an array of 8 bit integers.
> That preserves flexibility of targeting basically "anything from anything".

True, I guess not.

>  Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.
>   Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.
>  
>  
> As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

They should always be representable as INTEGER, no?

> I think it's a pretty simple fix.
>  
>  
> There is still a bug targeting 64bit from 32bit because of this.
> The attempts to declare "maximally sized arrays" fails.

Oh, yes, now I get you.

> m3core has a hack where it uses 2GB or 4GB instead of the real max.
> The "jvideo" package still fails to cross compile.


RIght.

>  
>  
>  - Jay
>  
> Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 16:53:19 -0500
> CC: wagner at elegosoft.com; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> On 13 Jan 2010, at 16:45, Jay K wrote:
> 
> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)
> 
> We should merge head back to release for LONGINT as it is now (more consistently) implemented.
> 
>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).
> 
> Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.
> 
> I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.
> 
>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).
> 
> That would be good too.
> 
>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/4c9ba8a4/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 14 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 10:23:24 +0000
Subject: [M3devel] merging head m3front to release
Message-ID: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>


 > merging head m3front to release

 

The changes are big and I don't understand them right away.

Just do a wholesale copy?

(and remember related changes to m3tk and m3core)

 

A parameter got renamed lhs => traced or vice versa 

through a lot of the code, but not always. And the value

of it sometimes changed but not always.

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/28a3e89f/attachment-0001.html>

From wagner at elegosoft.com  Thu Jan 14 11:56:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Jan 2010 11:56:49 +0100
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 13 Jan 2010, at 16:45, Jay K wrote:
>
>> Yes and no. I was thinking about this too.
>> In general this "race" never ends.
>> However:
>>   - right this is first release with LONGINT, and I think there are  
>>  incompatibilities between head and release esp. wrt "ORD"
>>    (Had we added e.g. "assignability" and release was just a   
>> compatible subset, different; I think it is actually "incompatible".)
>
> We should merge head back to release for LONGINT as it is now (more   
> consistently) implemented.
>
>>   - the "race" should actually "slow down" now that I fixed the   
>> platform list problem :)
>>      but still, the "race" isn't guaranteeably gone; there might   
>> still be new language features that m3core/libm3 use
>>      (to be clear, the "front" group needs to be more careful about  
>>  using more features;
>>      for example, it would be "useful" for me to use LONGINT in   
>> m3back, and then build a non-NT386 hosted compiler, in order to get  
>>  LONGINT support into NT386, however my preference at the moment is  
>>  to use Target.Int to "simulate" 64bit arithmetic in the compiler   
>> ("constant folding" and such, as it already does for 32bit   
>> integers); the compiler basically supports targeting 32bit INTEGER   
>> even on a host with only 8 or 16bit INTEGER, as I understand).
>
> Yes, I could have made use of LONGINT but didn't so as to retain   
> cross-compilation from short to long LONGINT platforms.
>
> I don't understand what you are saying about needing to simulate   
> 64-bit arithmetic.  We can do that already.  I don't think the   
> compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be   
> surprised if that actually works.
>
>>  If I or anyone checks that the exception is gone now in GUI file   
>> open dialog, maybe merge those changes too.
>> They are pretty small. I haven't touched rd/wr yet (well, they were  
>>  touched *slightly*).
>
> That would be good too.

Can one of you please do the necessary merges? I had a quick look,
but there were too many commits to find the relevant things quickly.

We should try to be selective and not merge just everything though;
CVS needs two labels or dates to do those three point merges
(cvs update -j -r rev1 -r rev2; build; cvs commit).

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Jan 14 13:36:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100114123342.98F412474001@birch.elegosoft.com>
References: <20100114123342.98F412474001@birch.elegosoft.com>
Message-ID: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>


In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..

 

 

 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0005.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0007.txt>

From jay.krell at cornell.edu  Thu Jan 14 13:37:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:37:45 +0000
Subject: [M3devel] longint changes to release branch
In-Reply-To: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
References: <20100114123342.98F412474001@birch.elegosoft.com>,
	<COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
Message-ID: <COL101-W251E60863732D724E2A93EE66A0@phx.gbl>


Also, I'm slightly guessing here as to what should go to release.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3commit at elegosoft.com; m3devel at elegosoft.com
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: Re: [M3devel] [M3commit] CVS Update: cm3



In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..
 
 
 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/8b1d6459/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 14:44:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:44:54 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
Message-ID: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>

On 14 Jan 2010, at 05:23, Jay K wrote:

>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.

That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).

I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/348e9b5c/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 14:45:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:45:27 -0500
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
Message-ID: <9EF41FDC-DF20-4024-99FC-ADCA6CE44BAC@cs.purdue.edu>

I won't have time for it for at least 2 weeks.

On 14 Jan 2010, at 05:56, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 13 Jan 2010, at 16:45, Jay K wrote:
>> 
>>> Yes and no. I was thinking about this too.
>>> In general this "race" never ends.
>>> However:
>>>  - right this is first release with LONGINT, and I think there are  incompatibilities between head and release esp. wrt "ORD"
>>>   (Had we added e.g. "assignability" and release was just a  compatible subset, different; I think it is actually "incompatible".)
>> 
>> We should merge head back to release for LONGINT as it is now (more  consistently) implemented.
>> 
>>>  - the "race" should actually "slow down" now that I fixed the  platform list problem :)
>>>     but still, the "race" isn't guaranteeably gone; there might  still be new language features that m3core/libm3 use
>>>     (to be clear, the "front" group needs to be more careful about  using more features;
>>>     for example, it would be "useful" for me to use LONGINT in  m3back, and then build a non-NT386 hosted compiler, in order to get  LONGINT support into NT386, however my preference at the moment is  to use Target.Int to "simulate" 64bit arithmetic in the compiler  ("constant folding" and such, as it already does for 32bit  integers); the compiler basically supports targeting 32bit INTEGER  even on a host with only 8 or 16bit INTEGER, as I understand).
>> 
>> Yes, I could have made use of LONGINT but didn't so as to retain  cross-compilation from short to long LONGINT platforms.
>> 
>> I don't understand what you are saying about needing to simulate  64-bit arithmetic.  We can do that already.  I don't think the  compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be  surprised if that actually works.
>> 
>>> If I or anyone checks that the exception is gone now in GUI file  open dialog, maybe merge those changes too.
>>> They are pretty small. I haven't touched rd/wr yet (well, they were  touched *slightly*).
>> 
>> That would be good too.
> 
> Can one of you please do the necessary merges? I had a quick look,
> but there were too many commits to find the relevant things quickly.
> 
> We should try to be selective and not merge just everything though;
> CVS needs two labels or dates to do those three point merges
> (cvs update -j -r rev1 -r rev2; build; cvs commit).
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/3be3eafd/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 18:40:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 12:40:32 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
Message-ID: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 12:14, Tony Hosking wrote:

> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/b74f377f/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Jan 14 20:34:24 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 14:34:24 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>

No, the only scripts I've changed are mine in scripts/dev/windows.  These don't have anything to do with Tinderbox.
Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484





On 14 Jan 2010, at 12:14, Tony Hosking wrote:


Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/bec28c6a/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 14 20:57:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 14:57:15 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>

Hmm.  The only other commits I've seen are Jay's.  Jay?

On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:

> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>  
> 
> 
>  
>  
> On 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/0b0d827a/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 14 23:09:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:09:17 +0000
Subject: [M3devel] initializing Target.Int
In-Reply-To: <20100114135750.080852474001@birch.elegosoft.com>
References: <20100114135750.080852474001@birch.elegosoft.com>
Message-ID: <COL101-W65F274A88DB4C659B147C3E66A0@phx.gbl>


Uninitialized seems pretty much always bad.

n := 0 appears to be illegal.

 

 - Jay

 
> Date: Thu, 14 Jan 2010 14:57:50 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/14 14:57:49
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.i3 
> 
> Log message:
> This is deliberately uninitialised!
> It defaults to 0 anyway.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/afde87e9/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 14 23:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:21:43 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
Message-ID: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>


"lastok" of the release branch, which this appears to be, was expected to fail.
(and for head was expected a few days ago)

Previous compiler can't build m3core.

Must first build compiler, then m3core.

The usual occasional problem.

 

  - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 14:57:15 -0500
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Output from "cron" command

Hmm.  The only other commits I've seen are Jay's.  Jay?




On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:



No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
Regards,
Randy
 


From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command
 
Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

 

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

 

Randy/Jay, did you change something related to this?

 



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 14 Jan 2010, at 12:14, Tony Hosking wrote:




Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f6fcf293/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 14 23:28:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:28:33 +0000
Subject: [M3devel] merging head m3front to release
In-Reply-To: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
Message-ID: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>


If it's just a wholesale copy, I can do that fairly easily/quickly/soon.

  Anyone can.

You are certain a wholesale copy, of all of m3front? Final answer?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 08:44:54 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] merging head m3front to release




On 14 Jan 2010, at 05:23, Jay K wrote:


 > merging head m3front to release
 
The changes are big and I don't understand them right away.
Just do a wholesale copy?
(and remember related changes to m3tk and m3core)
 
A parameter got renamed lhs => traced or vice versa 
through a lot of the code, but not always. And the value
of it sometimes changed but not always.



That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).


I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/990dc763/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 00:22:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:22:03 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
	<COL101-W39241284420296C5E5118FE66A0@phx.gbl>
Message-ID: <E9ED6716-3CCB-4DF3-B25E-D34DF4097E16@cs.purdue.edu>

Yes.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:28, Jay K wrote:

> If it's just a wholesale copy, I can do that fairly easily/quickly/soon.
>   Anyone can.
> You are certain a wholesale copy, of all of m3front? Final answer?
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 08:44:54 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] merging head m3front to release
> 
> On 14 Jan 2010, at 05:23, Jay K wrote:
> 
>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.
> 
> That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).
> 
> I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
> Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/61d5c355/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 00:24:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:24:06 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>

I'm not sure what that implies...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:21, Jay K wrote:

> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>  
>   - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Hmm.  The only other commits I've seen are Jay's.  Jay?
> 
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> 
> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/17d1ca27/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 00:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 23:58:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
Message-ID: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Fri Jan 15 02:10:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 01:10:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <COL101-W25419C91933D529A477126E6690@phx.gbl>


> What should always work actually..
 
Except that I've seen "blessed" in our Hudson process
a cm3 that just always crashes.
It happened multiple times on my SOLgnu/SOLsun machine.
I had to delete a bunch of cm3 and go back to an older one.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:58:33 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
> Tony you know all this.
> This email is redundant for you.
>
>
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>
>
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
>
>
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>
>
> If this works, its cm3 output can be "blessed" as "something".
>
>
>
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>
>
> Again the output can be "blessed" as "something".
>
>
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>
>
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>
>
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>
>
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>
>
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>
>
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>
>
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>
>
> - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>>
>> I'm not sure what that implies...
>>
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>>
>>
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>>
>> - Jay
>>
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Hmm. The only other commits I've seen are Jay's. Jay?
>>
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>
>> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
>> Regards,
>> Randy
>>
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>
>> Randy/Jay, did you change something related to this?
>>
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>
>>
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>>
>> produced the following output:
>>
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>>
>>
>>
>> 		 	   		  

From rcolebur at SCIRES.COM  Fri Jan 15 05:45:50 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 23:45:50 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, ,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>

Jay / Tony:

I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".

RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".

Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".

RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
1.  Copies some of the other scripts and documentation I use to the "bin" folder.
2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
4.  Stage-2:  Builds and ships all packages in the "front" group.
5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.

Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?

Regards,
Randy Coleburn

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, January 14, 2010 6:59 PM
To: Tony
Cc: m3devel
Subject: Re: [M3devel] Output from "cron" command


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  


From hosking at cs.purdue.edu  Fri Jan 15 05:49:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 23:49:18 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>

I think so.  Jay can comment more accurately re Windows.

On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:

> Jay / Tony:
> 
> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
> 
> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
> 
> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".
> 
> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
> 1.  Copies some of the other scripts and documentation I use to the "bin" folder.
> 2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
> 3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
> 4.  Stage-2:  Builds and ships all packages in the "front" group.
> 5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
> 
> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Thursday, January 14, 2010 6:59 PM
> To: Tony
> Cc: m3devel
> Subject: Re: [M3devel] Output from "cron" command
> 
> 
> Tony you know all this.
> This email is redundant for you.
> 
> 
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
> 
> 
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
> 
> 
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
> 
> 
> If this works, its cm3 output can be "blessed" as "something".
> 
> 
> 
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
> 
> 
> Again the output can be "blessed" as "something".
> 
> 
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
> 
> 
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
> 
> 
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
> 
> 
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
> 
> 
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
> 
> 
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
> 
> 
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> 
>> 
>> I'm not sure what that implies...
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>> 
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>> 
>> - Jay
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Hmm. The only other commits I've seen are Jay's. Jay?
>> 
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>> 
>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>> Regards,
>> Randy
>> 
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>> 
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>> 
>> Randy/Jay, did you change something related to this?
>> 
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>> 
>> 
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>> 
>> produced the following output:
>> 
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>> 
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>> 
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Fri Jan 15 07:07:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 06:07:56 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>,
	<D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
Message-ID: <COL101-W18358BFDB1FF6BCB94C49DE6690@phx.gbl>


Not quite. shipping cm3 doesn't put it in the right place, so you have to "manually" copy it.
 
 
At some point I'd like to see about making that work better
but it isn't high priority.
 
 
In particular, on Windows you can rename away an in-use .exe/.dll and then copy over.
 
 
But I think I've seen the behavior on other systems that replacing in-use executables/.so files causes a "random" mix of in-memory code/data and crashes. (And I know Windows is usually criticized for not letting you replace "running code", but the reality is more lenient than people realize, the reality of allowing such things is far more complicated than people realize (how do I ensure the old version eventually is not used?) and I believe other systems have similar or more stringent restrictions, e.g. AIX).
 
 
We should probably make shipping in cminstall put the configuration files in place or somesuch, instead of leaving it to all the scripts.
There is a tension in that programming in Python being much easier and more pleasant than any of the alternatives such as Modula-3 or Quake..
 
 
Anyway, I just use the *.py files, on Linux, Darwin, NT, OpenBSD, FreeBSD, NetBSD, Solaris, etc. (MIPS64_OPENBSD so far I don't have Python for, it's like the only one).
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:49:18 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] Output from "cron" command
>
> I think so. Jay can comment more accurately re Windows.
>
> On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:
>
>> Jay / Tony:
>>
>> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
>>
>> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
>>
>> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file. It depends on "pkgInfo.txt".
>>
>> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
>> 1. Copies some of the other scripts and documentation I use to the "bin" folder.
>> 2. Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
>> 3. Stage-1: Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
>> 4. Stage-2: Builds and ships all packages in the "front" group.
>> 5. Stage-3: Builds and ships a distribution. Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
>>
>> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
>>
>> Regards,
>> Randy Coleburn
>>
>> -----Original Message-----
>> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
>> Sent: Thursday, January 14, 2010 6:59 PM
>> To: Tony
>> Cc: m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>> Tony you know all this.
>> This email is redundant for you.
>>
>>
>> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>>
>>
>> We have as I understand "pairs" of automated builds.
>> Though actually more than two could make sense.
>>
>>
>> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>>
>>
>> If this works, its cm3 output can be "blessed" as "something".
>>
>>
>>
>> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>>
>>
>> Again the output can be "blessed" as "something".
>>
>>
>> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>>
>>
>> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>>
>>
>> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>>
>>
>> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>>
>>
>> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>>
>>
>> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>>
>>
>> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>>
>>>
>>> I'm not sure what that implies...
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>>
>>> "lastok" of the release branch, which this appears to be, was expected to fail.
>>> (and for head was expected a few days ago)
>>> Previous compiler can't build m3core.
>>> Must first build compiler, then m3core.
>>> The usual occasional problem.
>>>
>>> - Jay
>>>
>>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>>> To: rcolebur at SCIRES.COM
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Hmm. The only other commits I've seen are Jay's. Jay?
>>>
>>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>>
>>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>>> Regards,
>>> Randy
>>>
>>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>>> Sent: Thursday, January 14, 2010 12:41 PM
>>> To: Tony Hosking
>>> Cc: m3devel m3devel
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>>
>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>>
>>> Randy/Jay, did you change something related to this?
>>>
>>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>>
>>>
>>> Your "cron" job on niagara.cs.purdue.edu
>>> $HOME/cm3/scripts/regression/cron.sh
>>>
>>> produced the following output:
>>>
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 06:30:09 -- checkout in progress.
>>> [start checkout 2010.01.14 06:30:17]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 06:45:08]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 06:45:13 -- compile in progress.
>>> [start compile 2010.01.14 06:45:13]
>>> compile return value: 0
>>> [end compile 2010.01.14 08:49:36]
>>> COMPILE_RETURN = 0
>>> 2010.01.14 08:49:56 -- tests in progress.
>>> [start run-tests 2010.01.14 08:49:56]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> [end run-tests 2010.01.14 11:02:11]
>>> TESTS_RETURN = 510
>>> *** TESTS FAILED
>>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 11:05:04 -- checkout in progress.
>>> [start checkout 2010.01.14 11:05:06]
>>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 11:20:02]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 11:20:08 -- compile in progress.
>>> [start compile 2010.01.14 11:20:08]
>>> compile return value: 1
>>> [end compile 2010.01.14 12:11:12]
>>> COMPILE_RETURN = 1
>>> *** COMPILE FAILED
>>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>>
>>>
>>>
>>>
> 		 	   		  

From wagner at elegosoft.com  Fri Jan 15 10:05:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 15 Jan 2010 10:05:09 +0100
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, 
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> "lastok" of the release branch, which this appears to be, was   
> expected to fail.
> (and for head was expected a few days ago)
>
> Previous compiler can't build m3core.
>
> Must first build compiler, then m3core.
>
> The usual occasional problem.

The release-builds fail, too.

Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
AMD64_LINUX has no previous release, it needs to be fixed manually.
I expect SOLgnu on Niagara to fail soon, too.

The upgrade.sh script should take care for all problems encountered
during bootstrapping a (slightly) incompatible compiler.

In  
http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846

it fails with a quake error though:

5369           
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh  
upgrade
5370          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
5371          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
5372  NEXT    quake runtime error:  
"/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line  
13: quake runtime error: undefined variable: M3_PROFILING
5373
5374          --procedure--  -line-  -file---
5375                             13   
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
5376          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
5377          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5

Later libm3 cannot be compiled due to errors in FilePosix.

Error reporting should definitely be better here, but it's unlikely that
I find the time to do that soon.

Olaf


>   - Jay
>
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm.  The only other commits I've seen are Jay's.  Jay?
>
>
>
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
>
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows.    
> These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
>
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts   
> results in improper bootstrapping of the compiler...
>
>
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
>
>
> Randy/Jay, did you change something related to this?
>
>
>
>
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan 15 12:17:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:17:59 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W48219CDFF89BDE026F09A1E6690@phx.gbl>


ps: the thing do is also what I alluded to:

 

use a "latest" build, but skip m3core/libm3.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] Output from "cron" command
Date: Fri, 15 Jan 2010 11:16:45 +0000



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/875a534f/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 12:16:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>


Interestingly, my upgrade.py goes ahead and foists current configuration files any

old compiler. I've definitely spent some time working around problems

with older compilers in the current configurations.

And older compilers definitely don't always have a good configuration,

so replacing it is not a bad idea.

 

 

That said, this isn't that big a deal. The scripts

prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/cb7ffe36/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 13:16:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 12:16:04 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>,
	<COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
Message-ID: <COL101-W69543449C8565130D44A9E6690@phx.gbl>


well, I did something else instead; let's see how it goes

 

 - Jay

 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: Re: [M3devel] Output from "cron" command



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/efb1e269/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 17:51:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 11:51:18 -0500
Subject: [M3devel] Oops, forgot to ask
In-Reply-To: <4B2965B7.6040304@lcwb.coop>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>
	<4B2965B7.6040304@lcwb.coop>
Message-ID: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>

I just dug this correspondence out of my pile and realised that we still don't have LONGCARD.  This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines.  I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3.  Might as well do it now instead of later, so the pain is not dragged out over time.

On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
>> 
>>  
>>> Hi Gang,
>>> 
>>> 0 - CARDINALs are an integral type defined by the language
>>> spec to be from 0 (zero) to MAXINT (not MAXCARD).  Recently,
>>> a change was made to CM3 to extend the language it recognizes
>>> beyond the original language spec (SPWM3), now CM3 understands
>>> a LONGINT.  
>>> Was there a corresponding LONGCARD defined?
>>>    
>> 
>> No.  But you can write:
>> 
>> [0L..LAST(LONGINT)]
>> 
>> just as
>> 
>> CARDINAL=[0..LAST(INTEGER)]
>>  
> Actually, the line above was once true, long long ago, when dinosaurs
> roamed unfettered.  CARDINAL was changed to be "just like"
> (but not equal to) [0..LAST(INTEGER)].  This would have been
> maybe early 1990s. 
> It took me years to figure out what this actually meant, and more
> years to figure out why, but I believe I now know.  CARDINAL is not an
> equal type to [0..LAST(INTEGER)], but otherwise has all the same
> properties.  This makes the two mutually assignable, which is close
> enough to equal to not matter in most contexts.  The exact consequences
> follow from other language rules. 
> The motivation is this:  [0..LAST(INTEGER)] on a 32-bit machine is not
> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> machines with different values of LAST(INTEGER)), because the numeric
> value of LAST(INTEGER) is part of the expanded type.  The one place this
> matters is if you use pickles to transfer data between machines of different
> word sizes.  If the type is [0..LAST(INTEGER)], the type signature (a hash
> of the complete, expanded type definition) is different on the two machines,
> and values of or containing this type cannot be transferred.  Exact type
> signature matches are used in pickles to find corresponding types when
> reading. 
> But pickles handle different sized INTEGER values fine, expanding/shortening
> as needed.  Being a leaf in a type definition, INTEGER is always the same
> type on any machine.  So CARDINAL was changed to be its own unique
> type too, so it would be possible also to transfer CARDINAL values in pickles
> between different word sizes. 
> So, we really should have a LONGCARD, parallel to CARDINAL.
> 
> Note that this also affects network objects, which use pickles to transfer
> values of the objects.
> 
> 
>> 
>>  
>>> Can is use all 64-bits, or is it restricted to 63, like
>>> the CARDINAL is only 31-bits.
>>>    
>> 
>> 63 bits, since its underlying base type is LONGINT.
>> 
>> 
>>  
>>> 
>>> 
>>> 
>>> +--------------------------------------------------------+
>>> | Peter P. Eiserloh                                      |
>>> +--------------------------------------------------------+
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>  



From jay.krell at cornell.edu  Fri Jan 15 21:53:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:53:51 +0000
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
Message-ID: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>


I know. But see here from 2001:

 

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2



Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.

 

It seems some of the 4.1/5.1 changes never made it from a branch to head??


 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:04:48 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> 
> *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> ***************
> *** 236,241 ****
> --- 236,242 ----
> 
> PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> RAISES {OSError.E} =
> + VAR log: TEXT;
> BEGIN
> IF NOT lm.recoverable(nm) THEN
> RAISE OSError.E(
> ***************
> *** 243,253 ****
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! IF TestFile(lm.logfn(nm)) THEN
> ! RETURN FS.Status(nm).size > 0
> ! ELSE
> ! RETURN TRUE
> ! END;
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> --- 244,251 ----
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! log := lm.logfn(nm);
> ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> 
> 
> On 15 Jan 2010, at 13:03, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 13:03:10
> > 
> > Modified files:
> > cm3/m3-db/stable/src/: LogManager.m3 
> > 
> > Log message:
> > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/62e18b50/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 21:57:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:57:58 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
 file size on 32bit platform)
In-Reply-To: <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
Message-ID: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>


I at least did move the hacks to one place.

I agree it isn't nice.

This is due to my changes, not yours -- changing File.T.status().size to LONGINT.

There's no way to use that in the "compiler" and still support old compiler/libm3, right?

Ok now that I centralized it to sysutils?

 

 

Leave status() alone as using INTEGER and introduce statusL()?

 

 

Or leave size alone and introduce sizeL?

 That's not a complete solution because you have to set size to something.

  -1 if it doesn't fit?

 

 

Or just get past the bootstrapping and put it back using VAL?

It seems a tough situation..the compiler is otherwise I believe

very compatible with old compiler/libm3.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/870c16bb/attachment-0001.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:08:59 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:08:59 -0500
Subject: [M3devel] question on cm3 versioning & dating
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7B8@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

When running upgrade.py, the compiler gets invoked as follows on my system:

C:\cm3\bin\cm3.exe  -build -DROOT=C:/cm3/Sandbox -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15

I also note that the "cm3 -version" option currently produces the following:

Critical Mass Modula-3 version d5.8.2
  last updated: 2009-07-15
  compiled: 2010-01-13 02:33:39
  configuration: C:\cm3\bin\cm3.cfg
  host: NT386
defaulting to native build: NT386
  target: NT386

Questions:


1.       What is purpose of the various "-DCM3..." arguments and should these be changing based on some formula or rule?


2.       I note that when compiling "cm3" package, I get complaints about missing version file information.  What should I be doing to correct this, if anything?  See below:

missing CM3_VERSION_NUMBER will read version file
missing CM3_VERSION_TEXT will read version file
missing CM3_LAST_CHANGED will read version file

It would seem that these three items have some parallel to the "-DCM3..." arguments.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/88197ea8/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 22:17:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:17:15 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
Message-ID: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>

On 15 Jan 2010, at 15:57, Jay K wrote:

> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?

Yes.

> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.

It very soon will not be.

>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/83dcb1f9/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 22:20:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:20:03 -0500
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
	<COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
Message-ID: <9CA89F2F-4065-480D-A20C-87B983CE511B@cs.purdue.edu>

Aha!  Weird!  I'll leave it alone.

On 15 Jan 2010, at 15:53, Jay K wrote:

> I know. But see here from 2001:
>  
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2
> 
> 
> Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.
>  
> It seems some of the 4.1/5.1 changes never made it from a branch to head??
> 
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:04:48 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> > 
> > *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> > --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> > ***************
> > *** 236,241 ****
> > --- 236,242 ----
> > 
> > PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> > RAISES {OSError.E} =
> > + VAR log: TEXT;
> > BEGIN
> > IF NOT lm.recoverable(nm) THEN
> > RAISE OSError.E(
> > ***************
> > *** 243,253 ****
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! IF TestFile(lm.logfn(nm)) THEN
> > ! RETURN FS.Status(nm).size > 0
> > ! ELSE
> > ! RETURN TRUE
> > ! END;
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > --- 244,251 ----
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! log := lm.logfn(nm);
> > ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > 
> > 
> > On 15 Jan 2010, at 13:03, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 13:03:10
> > > 
> > > Modified files:
> > > cm3/m3-db/stable/src/: LogManager.m3 
> > > 
> > > Log message:
> > > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> > 



From jay.krell at cornell.edu  Fri Jan 15 22:34:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:34:11 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
Message-ID: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>


We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.

That is more ok for m3core, less ok for cm3/m3quake.

As well, m3core also couldn't be built with recent but slightly old compiler.

    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).

    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.

 

 

The sysutils/m3quake/cm3 changes should stand?

Ok removing "32" from the name and letting it return >4GB on 64bit platforms.

But I think either it can't use libm3.File.T.status().size, OR we have to

make status().size more compatible such as by introducing statusL or sizeL.

32bit code wouldn't see >4GB file sizes unless actively changed.

Maybe not a bad idea.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/8fdf539f/attachment-0001.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:45:42 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Not sure about your statement that recent cm3.exe can't be used to bootstrap new compiler.

I haven't done an update in last 2 days, but up until then, I've been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.

Are you saying that if I get current update (I'm only a couple of days out of sync with HEAD) that I won't be able to bootstrap anymore?

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.


The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.


 - Jay


________________________________
From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
On 15 Jan 2010, at 15:57, Jay K wrote:

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

Ok now that I centralized it to sysutils?


Leave status() alone as using INTEGER and introduce statusL()?


Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?


Or just get past the bootstrapping and put it back using VAL?

Yes.

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

It very soon will not be.



 - Jay


> From: hosking at cs.purdue.edu<mailto:hosking at cs.purdue.edu>
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de<mailto:jkrell at elego.de>
> CC: m3commit at elegosoft.com<mailto:m3commit at elegosoft.com>
> Subject: Re: [M3commit] CVS Update: cm3
>
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
>
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
>
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> >
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
> > m3makefile
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c
> >
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/898d6377/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 22:46:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:46:48 +0000
Subject: [M3devel] Oops, forgot to ask (LONGCARD)
In-Reply-To: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>,
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>,
	<4B2965B7.6040304@lcwb.coop>,
	<A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
Message-ID: <COL101-W161A9EA86E5E2209FDC950E6690@phx.gbl>


sysutils.GetFileSize use by the compiler should help.

And still I'm open to introducing statusL() or sizeL and leaving status()/size as INTEGER.

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 11:51:18 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Oops, forgot to ask
> 
> I just dug this correspondence out of my pile and realised that we still don't have LONGCARD. This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines. I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3. Might as well do it now instead of later, so the pain is not dragged out over time.
> 
> On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:
> 
> > Tony Hosking wrote:
> >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
> >> 
> >> 
> >>> Hi Gang,
> >>> 
> >>> 0 - CARDINALs are an integral type defined by the language
> >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,
> >>> a change was made to CM3 to extend the language it recognizes
> >>> beyond the original language spec (SPWM3), now CM3 understands
> >>> a LONGINT. 
> >>> Was there a corresponding LONGCARD defined?
> >>> 
> >> 
> >> No. But you can write:
> >> 
> >> [0L..LAST(LONGINT)]
> >> 
> >> just as
> >> 
> >> CARDINAL=[0..LAST(INTEGER)]
> >> 
> > Actually, the line above was once true, long long ago, when dinosaurs
> > roamed unfettered. CARDINAL was changed to be "just like"
> > (but not equal to) [0..LAST(INTEGER)]. This would have been
> > maybe early 1990s. 
> > It took me years to figure out what this actually meant, and more
> > years to figure out why, but I believe I now know. CARDINAL is not an
> > equal type to [0..LAST(INTEGER)], but otherwise has all the same
> > properties. This makes the two mutually assignable, which is close
> > enough to equal to not matter in most contexts. The exact consequences
> > follow from other language rules. 
> > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not
> > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> > machines with different values of LAST(INTEGER)), because the numeric
> > value of LAST(INTEGER) is part of the expanded type. The one place this
> > matters is if you use pickles to transfer data between machines of different
> > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash
> > of the complete, expanded type definition) is different on the two machines,
> > and values of or containing this type cannot be transferred. Exact type
> > signature matches are used in pickles to find corresponding types when
> > reading. 
> > But pickles handle different sized INTEGER values fine, expanding/shortening
> > as needed. Being a leaf in a type definition, INTEGER is always the same
> > type on any machine. So CARDINAL was changed to be its own unique
> > type too, so it would be possible also to transfer CARDINAL values in pickles
> > between different word sizes. 
> > So, we really should have a LONGCARD, parallel to CARDINAL.
> > 
> > Note that this also affects network objects, which use pickles to transfer
> > values of the objects.
> > 
> > 
> >> 
> >> 
> >>> Can is use all 64-bits, or is it restricted to 63, like
> >>> the CARDINAL is only 31-bits.
> >>> 
> >> 
> >> 63 bits, since its underlying base type is LONGINT.
> >> 
> >> 
> >> 
> >>> 
> >>> 
> >>> 
> >>> +--------------------------------------------------------+
> >>> | Peter P. Eiserloh |
> >>> +--------------------------------------------------------+
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/4286c96a/attachment-0001.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:49:06 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
References: <20100115212846.B78742474001@birch.elegosoft.com>
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Can you explain why?

I haven't noticed this problem on Windows.

Perhaps are you suggesting that since cm3.exe is currently executing the -ship directive that Windows won't replace the .exe file while in use?  In general, for these type of problems I've always gotten a pop-up warning that file was in use.  I don't get such an error in this case though.

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3

In fact -ship never puts cm3.exe in the right place.

 - Jay



> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
>
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd
>
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b3ca8a42/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 22:53:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:53:00 +0000
Subject: [M3devel] installing cm3.exe.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115212846.B78742474001@birch.elegosoft.com>,
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W656107CB255BC695B02F6EE6690@phx.gbl>


Because it is likely to fail, we don't even try.

 

 

See m3-sys/cm3/src/m3makefile:

 

 

% Some platforms do not allow overwriting binaries that are currently
% executed, hence the default is not to install the cm3 binary in place.
% This also saves the user from accidentally overwriting the currently
% used compiler. To install the binary, you can either use the
% install-cm3-compiler script from the scripts/ directory or set the
% INSTALL_CM3_IN_BIN environment variable to "yes".
if equal($INSTALL_CM3_IN_BIN, "yes")
Program ("cm3")
else
program ("cm3")
end


 

You wouldn't get a popup for this, you'd just get an error.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: Re: [M3devel] [M3commit] CVS Update: cm3





Jay:
 
Can you explain why?
 
I haven?t noticed this problem on Windows.
 
Perhaps are you suggesting that since cm3.exe is currently executing the ?ship directive that Windows won?t replace the .exe file while in use?  In general, for these type of problems I?ve always gotten a pop-up warning that file was in use.  I don?t get such an error in this case though.
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3
 
In fact -ship never puts cm3.exe in the right place.
 
 - Jay


 
> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
> 
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd 
> 
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/d5965c5c/attachment-0001.html>

From Highjinks at gmx.com  Fri Jan 15 22:46:53 2010
From: Highjinks at gmx.com (Highjinks at gmx.com)
Date: Fri, 15 Jan 2010 16:46:53 -0500
Subject: [M3devel] Hello m3devel.
Message-ID: <20100115214653.129010@gmx.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/2ca36db1/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 22:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:56:19 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <20100115215118.A9F482474001@birch.elegosoft.com>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
Message-ID: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>


VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,

but I think what I had is the way to go.

The bootstrapping pain is otherwise novel.

The compiler doesn't otherwise use LONGINT.

 (My doing that it started using it.)

It ought not until after the current release?

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/f54804b0/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 22:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:50:50 +0000
Subject: [M3devel] [M3commit] WebFile/QScanner
	use	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W633584E529E074A2C2AEE6E6690@phx.gbl>


cm3.exe from a few days ago doesn't understand the VAL(LONGINT, INTEGER) used in Convert.m3.

 I had "fixed" Convert.m3 that but Tony put it back.

 

cm3/m3quake packages from a period this week only work with current libm3.

  That is fixed.

 

Normally you can either use an old cm3 and skip libm3/m3core or you can use a fairly recent cm3 and not stop skip them.

Neither was the case for a short time, but I restored the first option.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: Re: [M3devel] [M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)







Jay:
 
Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
 
I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
 
Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
 
We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 



From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)



On 15 Jan 2010, at 15:57, Jay K wrote:


 

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

 

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

 

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

 

Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?

 

Yes.

 

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

 

It very soon will not be.

 

 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/ddee77a0/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:08:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:08:08 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.

On 15 Jan 2010, at 16:34, Jay K wrote:

> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/af5911bb/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:09:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:09:10 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <E8BA8874-781B-48CC-8603-78B2B34E38C7@cs.purdue.edu>

You'll  need to bootstrap from old libs to new compiler+old libs to new libs to new compiler+new libs.

On 15 Jan 2010, at 16:45, Coleburn, Randy wrote:

> Jay:
>  
> Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
>  
> I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
>  
> Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
>  
> Regards,
> Randy Coleburn
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, January 15, 2010 4:34 PM
> To: Tony
> Cc: m3devel; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
>  
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
>  
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
>  
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
>  
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
>  
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
>  
> Yes.
>  
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
>  
> It very soon will not be.
>  
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/bf7e3125/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:13:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:13:38 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/c44cdc81/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 23:13:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:13:46 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
Message-ID: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>


That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?

They previously never used LONGINT, including converting LONGINT to INTEGER.

*I* changed that, not you.

But then I decided it was a mistake.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:08:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.






On 15 Jan 2010, at 16:34, Jay K wrote:

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/a8b5a71b/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 15 23:42:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:42:58 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
Message-ID: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>


The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.

 

I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.

(It's still in progress, but far long.)

 

m3core/libm3 can depend on current compiler, agreed.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:13:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.



On 15 Jan 2010, at 16:56, Jay K wrote:

VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
but I think what I had is the way to go.
The bootstrapping pain is otherwise novel.
The compiler doesn't otherwise use LONGINT.
 (My doing that it started using it.)
It ought not until after the current release?
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/64a7dd20/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:48:09 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, , ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
	<COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
Message-ID: <D4AC4183-1465-47E9-BD5B-DF879237640A@cs.purdue.edu>

My point is that you need to bootstrap a new compiler as follows:

Build new compiler against old libraries.
Compile new libraries using new compiler.
Recompile new compiler against new libraries.
Throw away old libraries.

On 15 Jan 2010, at 17:13, Jay K wrote:

> That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?
> They previously never used LONGINT, including converting LONGINT to INTEGER.
> *I* changed that, not you.
> But then I decided it was a mistake.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:08:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.
> 
> On 15 Jan 2010, at 16:34, Jay K wrote:
> 
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 
> 
> 



From hosking at cs.purdue.edu  Fri Jan 15 23:50:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:50:17 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.

The bootstrapping pain is now no more novel than when LONGINT was first introduced...

> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?

... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.

>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/9acc873c/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:51:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:51:47 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
Message-ID: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>

It's not the presence of LONGINT in the libraries or not.  It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.

On 15 Jan 2010, at 17:42, Jay K wrote:

> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>  
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>  
> m3core/libm3 can depend on current compiler, agreed.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
> 
> Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.
> 
> On 15 Jan 2010, at 16:56, Jay K wrote:
> 
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/f44cddfe/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 00:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:45:36 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
Message-ID: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>


I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
I'm not sure, but our regular builds might do that.
Not so now though.
I think you might be saying however that such a compiler might have bugs in it?
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:50:17 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>
>
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
>
> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 00:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:50:17 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
Message-ID: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>


Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.
 
 
Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?
 
 
One of us seems confused. I'm not sure who.
 
 
Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
5.2.6 works.
5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
 
 
I realize that it is grey and not clear how far to run this race.
You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
 
 
One metric has been that you can build with the previous "release".
I'm not sure which that is.
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:51:47 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
>
>
> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>
>
>
> On 15 Jan 2010, at 17:42, Jay K wrote:
>
> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>
> m3core/libm3 can depend on current compiler, agreed.
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
>
>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 00:57:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:57:30 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>
Message-ID: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>

You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:

Using old (release) cm3

m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.

m3core (new, with LONGINT/LONGCARD)
libm3 (new, with LONGINT/LONGCARD)
sysutils
m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses new run-time libraries.

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

> 
> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
> I'm not sure, but our regular builds might do that.
> Not so now though.
> I think you might be saying however that such a compiler might have bugs in it?
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> 
>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>> 
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Sat Jan 16 00:58:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:58:27 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
	<COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
Message-ID: <13D6BE0C-2B40-474D-8743-B4F95F7A1D1A@cs.purdue.edu>

On 15 Jan 2010, at 18:50, Jay K wrote:

> 
> Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.

Not easily.

> Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?

By old, you mean pre-LONGINT, right?

> One of us seems confused. I'm not sure who.

Not me!  ;-)

> Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
> 5.2.6 works.
> 5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
> 
> 
> I realize that it is grey and not clear how far to run this race.
> You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
> 
> 
> One metric has been that you can build with the previous "release".
> I'm not sure which that is.
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:51:47 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>> 
>> 
>> 
>> On 15 Jan 2010, at 17:42, Jay K wrote:
>> 
>> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>> 
>> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
>> (It's still in progress, but far long.)
>> 
>> m3core/libm3 can depend on current compiler, agreed.
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:13:38 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 
>> 
>> 		 	   		  



From Highjinks at gmx.com  Sat Jan 16 01:33:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 16 Jan 2010 01:33:22 +0100 (CET)
Subject: [M3devel] Hello m3devel. Fixed mailer.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <20100115203621.5ca71b4a.Highjinks@gmx.com>

On Fri, 15 Jan 2010 16:46:53 -0500
Highjinks at gmx.com wrote:

Sorry about the html attachment. Webmailers tend to do that. Sticking to my regular client program. 


--
Chris <Highjinks at gmx.com>


From rcolebur at SCIRES.COM  Sat Jan 16 02:09:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 20:09:02 -0500
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7F4@ATLEX02-SRV.SCIRES.LOCAL>

Chris:

Glad to have you on board.  Welcome!

We always seem to have a long list of to-do items and a shorter list of folks to help, so thanks for your offer.

As you become more familiar with Modula-3, don?t hesitate to reach out to me, or to the development group.

Glad to hear your learning experience so far has been good.  That is one of the primary goals of Modula-3.

I?ve been using Modula-3 for over 16 years now; and Modula-2 before that (among other languages).  Right now I?m primarily using Modula-3 on various Windows? platforms, so I won?t be much help with AMD64_LINUX issues, though I have and do use other Linux flavors.

The next major hurdle for the development team is to finish up the next release.  Maybe you can help test on your platform.

Regards,
Randy Coleburn

From: Highjinks at gmx.com [mailto:Highjinks at gmx.com]
Sent: Friday, January 15, 2010 4:47 PM
To: m3devel at elegosoft.com
Subject: [M3devel] Hello m3devel.

Just dropping in to say "Hi" and let you guys know what I'm up to.

Since I'm new to the list, and Modula 3, I wont clog up the list with novice questions. However, I do have fifteen years experience developing in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an order of magnitude faster than I picked up Ada.

My current platform is the AMD64_LINUX setup. And from the looks of it the development team here has been struggling a bit with 32bit/64bit issues. Is my observation correct? If so, what could I, an M3 newbie, do to assist?

I'm checking out the CM3 sources, anonymously, from the repository right now.

If there is anything I can do, just let me know.
--
Chris <Highjinks at gmx.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b95c54c4/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan 16 03:45:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 21:45:26 -0500
Subject: [M3devel] LONGINT and LONGCARD
Message-ID: <C101F91A-05C4-4FDA-84A8-A2A8BC13D043@cs.purdue.edu>

Support for these is now more complete.
More probably needs to be done w.r.to pickles, stable, sharedobj, netobj, etc. to handle variations in target implementations (NT386 using the integrated backend currently treats LONGINT/LONGCARD as 32 bits, whereas all other targets using the gcc-based backend treat LONGINT/LONGCARD as 64 bits).

For example:  there are no Longint/Longcard variants of In/OutInteger and In/OutCardinal in PickleStubs.m3.  Rodney?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/462d24e7/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 05:15:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 04:15:20 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
Message-ID: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>


I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 18:57:30 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>
> Using old (release) cm3
>
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>
> m3core (new, with LONGINT/LONGCARD)
> libm3 (new, with LONGINT/LONGCARD)
> sysutils
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses new run-time libraries.
>
> On 15 Jan 2010, at 18:45, Jay K wrote:
>
>>
>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>> I'm not sure, but our regular builds might do that.
>> Not so now though.
>> I think you might be saying however that such a compiler might have bugs in it?
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>>
>>>
>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>
>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>> but I think what I had is the way to go.
>>> The bootstrapping pain is otherwise novel.
>>>
>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>
>>> The compiler doesn't otherwise use LONGINT.
>>> (My doing that it started using it.)
>>> It ought not until after the current release?
>>>
>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>> To: m3commit at elegosoft.com
>>>> From: hosking at elego.de
>>>> Subject: [M3commit] CVS Update: cm3
>>>>
>>>> CVSROOT: /usr/cvs
>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>
>>>> Modified files:
>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>
>>>> Log message:
>>>> Revert to VAL.
>>>>
>>>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 05:29:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 23:29:27 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
Message-ID: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>

The old (release) libraries don't have the VAL stuff do they?

On 15 Jan 2010, at 23:15, Jay K wrote:

> 
> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>> 
>> Using old (release) cm3
>> 
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>> 
>> m3core (new, with LONGINT/LONGCARD)
>> libm3 (new, with LONGINT/LONGCARD)
>> sysutils
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses new run-time libraries.
>> 
>> On 15 Jan 2010, at 18:45, Jay K wrote:
>> 
>>> 
>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>> I'm not sure, but our regular builds might do that.
>>> Not so now though.
>>> I think you might be saying however that such a compiler might have bugs in it?
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> ________________________________
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> 
>>>> 
>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>> 
>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>> but I think what I had is the way to go.
>>>> The bootstrapping pain is otherwise novel.
>>>> 
>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>> 
>>>> The compiler doesn't otherwise use LONGINT.
>>>> (My doing that it started using it.)
>>>> It ought not until after the current release?
>>>> 
>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>> To: m3commit at elegosoft.com
>>>>> From: hosking at elego.de
>>>>> Subject: [M3commit] CVS Update: cm3
>>>>> 
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>> 
>>>>> Modified files:
>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>> 
>>>>> Log message:
>>>>> Revert to VAL.
>>>>> 
>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Sat Jan 16 06:14:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:14:16 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	,,<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	, , <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
Message-ID: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>


No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
It doesn't matter if x is INTEGER or not, right?
(In newer libraries, it is LONGINT).
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 23:29:27 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> The old (release) libraries don't have the VAL stuff do they?
>
> On 15 Jan 2010, at 23:15, Jay K wrote:
>
>>
>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>
>>> Using old (release) cm3
>>>
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>
>>> m3core (new, with LONGINT/LONGCARD)
>>> libm3 (new, with LONGINT/LONGCARD)
>>> sysutils
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses new run-time libraries.
>>>
>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>
>>>>
>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>> I'm not sure, but our regular builds might do that.
>>>> Not so now though.
>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>
>>>>>
>>>>>
>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>
>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>> but I think what I had is the way to go.
>>>>> The bootstrapping pain is otherwise novel.
>>>>>
>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>
>>>>> The compiler doesn't otherwise use LONGINT.
>>>>> (My doing that it started using it.)
>>>>> It ought not until after the current release?
>>>>>
>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>> To: m3commit at elegosoft.com
>>>>>> From: hosking at elego.de
>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>
>>>>>> Log message:
>>>>>> Revert to VAL.
>>>>>>
>>>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 06:16:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:16:11 +0000
Subject: [M3devel] release vs. head?
Message-ID: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>


Should we just make a new release branch?
Or I keep copying stuff over somewhat selectively?
  We do want LONGCARD in the release, I assume.
 
 
I'll diff the two trees again, see what varies.
Sometimes when I do that I find stuff to take.
 And take the LONGCARD changes.
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 06:20:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:20:22 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, , ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, , ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
	<COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
Message-ID: <DB076F7D-29E4-41E3-B0FA-1D02B33CD6C7@cs.purdue.edu>

That's fine.

On 16 Jan 2010, at 00:14, Jay K wrote:

> 
> No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
> It doesn't matter if x is INTEGER or not, right?
> (In newer libraries, it is LONGINT).
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 23:29:27 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> The old (release) libraries don't have the VAL stuff do they?
>> 
>> On 15 Jan 2010, at 23:15, Jay K wrote:
>> 
>>> 
>>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>> 
>>>> Using old (release) cm3
>>>> 
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>> 
>>>> m3core (new, with LONGINT/LONGCARD)
>>>> libm3 (new, with LONGINT/LONGCARD)
>>>> sysutils
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses new run-time libraries.
>>>> 
>>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>> 
>>>>> 
>>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>>> I'm not sure, but our regular builds might do that.
>>>>> Not so now though.
>>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>> 
>>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>>> but I think what I had is the way to go.
>>>>>> The bootstrapping pain is otherwise novel.
>>>>>> 
>>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>> 
>>>>>> The compiler doesn't otherwise use LONGINT.
>>>>>> (My doing that it started using it.)
>>>>>> It ought not until after the current release?
>>>>>> 
>>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: hosking at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>> 
>>>>>>> Log message:
>>>>>>> Revert to VAL.
>>>>>>> 
>>>>>> 
>>>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/42a67f46/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan 16 06:21:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:21:26 -0500
Subject: [M3devel] release vs. head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <99ACAE0F-41FB-4A46-A570-D10C9AA7C872@cs.purdue.edu>

At this point, what substantive differences are there between the release branch and the trunk other than LONGCARD?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 00:16, Jay K wrote:

> 
> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>  We do want LONGCARD in the release, I assume.
> 
> 
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
> And take the LONGCARD changes.
> 
> 
> - Jay 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/551dc9e1/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 12:11:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings
Message-ID: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>


Any of these worrisome?

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/654b4519/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 13:50:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 12:50:43 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>


Some of these are fixed in a newer version by adding parens.

The rest I just #pragma warning'ed away.

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings



Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/318612ae/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 14:45:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 13:45:22 +0000
Subject: [M3devel] longint/longcard/atomics copied from head to release
In-Reply-To: <20100116134209.79B3A2474001@birch.elegosoft.com>
References: <20100116134209.79B3A2474001@birch.elegosoft.com>
Message-ID: <COL101-W37005FD9263CE8B4674E89E6680@phx.gbl>


There's also more "val" reversion here.

Attached should match this. Pity no cvs command or web page can show it.

(I try to make up for CVS lameness just by remembering a lot...not a good technique..)

 

 - Jay

 
> Date: Sat, 16 Jan 2010 14:42:09 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/16 14:42:09
> 
> Modified files:
> cm3/m3-comm/events/src/: Tag: release_branch_cm3_5_8 
> EventStubLib.m3 
> cm3/m3-comm/sharedobjgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 
> Type.i3 Type.m3 Value.m3 
> cm3/m3-comm/stubgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 Type.i3 
> Type.m3 Value.m3 
> cm3/m3-db/stable/src/: Tag: release_branch_cm3_5_8 StableLog.i3 
> StableLog.m3 
> cm3/m3-db/stablegen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 GenModuleCode.m3 
> GenTypeCode.m3 Type.i3 Type.m3 
> Value.m3 
> cm3/m3-libs/libm3/src/pickle/ver2/: Tag: release_branch_cm3_5_8 
> ConvertPacking.m3 
> PickleStubs.i3 
> PickleStubs.m3 
> cm3/m3-libs/m3core/src/runtime/common/: Tag: 
> release_branch_cm3_5_8 
> RTBuiltin.mx 
> RTPacking.i3 
> RTPacking.m3 RTTipe.i3 
> RTTipe.m3 
> cm3/m3-sys/m3cggen/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> BuiltinTypes.m3 m3makefile 
> cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.i3 
> CG.m3 TipeDesc.i3 Token.m3 
> cm3/m3-sys/m3front/src/types/: Tag: release_branch_cm3_5_8 
> RecordType.i3 RecordType.m3 
> SubrangeType.m3 
> cm3/m3-sys/m3middle/src/: Tag: release_branch_cm3_5_8 M3CG.i3 
> M3CG.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 
> M3CG_Binary.i3 M3CG_Check.m3 
> M3CG_Ops.i3 M3CG_Rd.m3 M3CG_Wr.m3 
> cm3/m3-sys/m3quake/src/: Tag: release_branch_cm3_5_8 
> QCompiler.m3 QScanner.i3 
> cm3/m3-sys/m3tools/src/: Tag: release_branch_cm3_5_8 M3Const.m3 
> M3Type.i3 M3Type.m3 
> cm3/m3-tools/m3browser/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-tools/m3tk/src/fe/: Tag: release_branch_cm3_5_8 
> StandardAsText.m3 WiredStandard.m3 
> cm3/m3-tools/m3tk/src/pl/: Tag: release_branch_cm3_5_8 
> M3LTextToType.m3 M3LTypeEquiv.m3 
> M3LTypeToText.i3 M3LTypeToText.m3 
> cm3/m3-tools/m3tk/src/sem/: Tag: release_branch_cm3_5_8 
> M3CMkStd.m3 M3CStdTypes.i3 
> M3CStdTypes.m3 M3CTypeChkUtil.i3 
> M3CTypeChkUtil.m3 
> cm3/m3-tools/m3tk/src/syn/: Tag: release_branch_cm3_5_8 
> M3CLex.m3 M3CParse.m3 M3CToken.i3 
> Added files:
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> LCard.i3 LCard.m3 
> 
> Log message:
> copy from head: LONGINT, LONGCARD, and atomics come along for the ride
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment-0001.txt>

From rodney_bates at lcwb.coop  Sat Jan 16 18:49:12 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 16 Jan 2010 11:49:12 -0600
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <4B51FC18.1000104@lcwb.coop>



Highjinks at gmx.com wrote:
> Just dropping in to say "Hi" and let you guys know what I'm up to.
> 
> Since I'm new to the list, and Modula 3, I wont clog up the list with 
> novice questions. However, I do have fifteen years experience developing 
> in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an 
> order of magnitude faster than I picked up Ada.

As an old Ada refugee, I am glad to hear from someone making the same
transition, and glad to hear your estimate of learning time ratio.
It is the same as the ratio of language definition page counts!

> 
> My current platform is the AMD64_LINUX setup. And from the looks of it 
> the development team here has been struggling a bit with 32bit/64bit 
> issues. Is my observation correct? If so, what could I, an M3 newbie, do 
> to assist?
> 
> I'm checking out the CM3 sources, anonymously, from the repository right 
> now.
> 
> If there is anything I can do, just let me know.
> -- 
> Chris <Highjinks at gmx.com>
> 


From hosking at cs.purdue.edu  Sat Jan 16 19:48:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:12 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <2629BE63-3067-41FD-8A0F-E1F20C79C4FD@cs.purdue.edu>

Yes, those are potentially worrisome.  I've not seen them before.  dtoa has failed in the past because of warnings.  Which compiler?

On 16 Jan 2010, at 06:11, Jay K wrote:

> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/8ca33448/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan 16 19:48:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:49 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
Message-ID: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 07:50, Jay K wrote:

> Some of these are fixed in a newer version by adding parens.
> The rest I just #pragma warning'ed away.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sat, 16 Jan 2010 11:11:28 +0000
> Subject: [M3devel] dtoa warnings
> 
> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/d85e64eb/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 16 21:03:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 20:03:07 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>,
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>,
	<E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
Message-ID: <COL101-W15A68491F1F3F5ADA4096CE6680@phx.gbl>


A lot/all of the assignment within conditional you can see are ok because in the newer version they doubled the parens. That is the gcc convention for quashing them that unfortunately Microsoft C doesn't recognize.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>cl -c -W4 -Wall -DIEEE_8087 -TC dtoa.h | more

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.


...

 

These I can fix from current source.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>\cygwin\bin\gcc-4.exe -DIEEE_8087 -c -Wall dtoa.h
dtoa.h: In function 'Balloc':
dtoa.h:530: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'mult':
dtoa.h:809: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'pow5mult':
dtoa.h:891: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'lshift':
dtoa.h:972: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'd2b':
dtoa.h:1274: warning: suggest parentheses around assignment used as truth value
dtoa.h:1278: warning: suggest parentheses around assignment used as truth value
dtoa.h:1279: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'match':
dtoa.h:1473: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'hexnan':
dtoa.h:1505: warning: suggest parentheses around assignment used as truth value
dtoa.h:1533: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_strtod':
dtoa.h:1857: warning: suggest parentheses around assignment used as truth value
dtoa.h:1917: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'nrv_alloc':
dtoa.h:2600: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_dtoa':
dtoa.h:2780: warning: suggest parentheses around assignment used as truth value
dtoa.h:2934: warning: suggest parentheses around assignment used as truth value
dtoa.h:3095: warning: suggest parentheses around assignment used as truth value
dtoa.h:3133: warning: suggest parentheses around assignment used as truth value


 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 16 Jan 2010 13:48:49 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] dtoa warnings

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.




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 16 Jan 2010, at 07:50, Jay K wrote:

Some of these are fixed in a newer version by adding parens.
The rest I just #pragma warning'ed away.
 
 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings

Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression







 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/18a42382/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 00:39:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 23:39:09 +0000
Subject: [M3devel] signed overflow warnings in hand.c
Message-ID: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>


In C signed overflow is not defined.

Sometimes compilers take advantage of that and make optimizations assuming there is no overflow.

 

 

$ gcc-4 -O2 -Wstrict-overflow=4 -c hand.c
hand.c: In function `m3_div':
hand.c:244: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:245: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c: In function `m3_divL':
hand.c:256: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:257: warning: assuming signed overflow does not occur when distributing n
egation across division

jay at jay1 /cygdrive/c/dev2/cm3/m3-libs/m3core/src/Csupport/Common

 

 

Is there a way to write this using unsigned math only?

 

I was expecting warnings on the new functions unused functions I added.

 

 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/8526917b/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 06:10:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
Message-ID: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>


The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/5881e0f4/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 06:46:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
Message-ID: <COL101-W30215B137331232907B941E6670@phx.gbl>


The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/0e1628c2/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 06:48:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W30215B137331232907B941E6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	<COL101-W30215B137331232907B941E6670@phx.gbl>
Message-ID: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>


(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/daa44195/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 06:57:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>


The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/ca1bbea2/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 07:04:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 06:04:39 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <COL101-W63EE738E1345D2DACEFC08E6670@phx.gbl>


Actually there is also a problem passing 64 bit integers to K&R functions.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: Re: [M3devel] bugs in hand.c division








The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/c7bd059e/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 08:19:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>


Visual C++ and Sun cc also had problems here.

Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.

  -1 vs 1.

Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.

Anyone feel free to confirm my findings, please. :)

(likewise with INT64_MIN)

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/d4d102c2/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 08:28:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:28:47 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
Message-ID: <COL101-W22756264B636CB0F28608E6670@phx.gbl>


sorry, that wasn't right. But there were problems with Microsoft Visual C++ and Sun cc, and gcc.

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: Re: [M3devel] bugs in hand.c division



Visual C++ and Sun cc also had problems here.
Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.
  -1 vs 1.
Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.
Anyone feel free to confirm my findings, please. :)
(likewise with INT64_MIN)
 
 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/b3a3f1fa/attachment-0001.html>

From roland.illig at gmx.de  Sun Jan 17 08:49:45 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Sun, 17 Jan 2010 08:49:45 +0100
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, , ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <4B52C119.7080808@gmx.de>

Jay K schrieb:
> The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> What is that supposed to equal?
> For any version that doesn't "crash", the result is LONG_MIN.

That's the best result one can get besides throwing an exception. With 
unlimited integers, the result would be LONG_MAX + 1, which equals 
LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
arithmetics.

Roland


From jay.krell at cornell.edu  Sun Jan 17 09:56:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 08:56:59 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <4B52C119.7080808@gmx.de>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	,,<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>,
	<4B52C119.7080808@gmx.de>
Message-ID: <COL101-W162860C88378BBA3019641E6670@phx.gbl>


Understood. I put that back -- depending on C compiler flags,
LONG_MIN / -1 will either be LONG_MIN or trap.
Trap seems reasonable.
Though Modula-3 might mandate the consistent LONG_MIN?
Or leave it implementation defined?


The real bugs here were:
  LONG_MIN / negative (other than -1) was returning positive 
  possibly long long problem with K&R style, I'm pretty sure 
  possibly slightly fragile code wrt signed overflow. 


   funny thing is though, the reason I went looking into this
   was because mailing list threads lead me to believe my
   functions that are meant to look for overflow might be
   broken by the optimizer; it doesn't seem to notice them 
   but the funny stuff m3_div was doing, the optimizer 
   sees opportunity in and warns..so I started writing
   something using unsigned math, which isn't subject
   to such fragility, started testing it by comparison
   to the existing..found the existing to be wrong 


  I didn't really understand the code that was there.
  
But from the spec and behavior I could see -- round down negative results.
   Which you can do by roughly - ((abs(a) + abs(b) - 1) / abs(b))
   Round up the positive result.

 - Jay


> Date: Sun, 17 Jan 2010 08:49:45 +0100
> From: roland.illig at gmx.de
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] bugs in hand.c division
> 
> Jay K schrieb:
> > The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> > What is that supposed to equal?
> > For any version that doesn't "crash", the result is LONG_MIN.
> 
> That's the best result one can get besides throwing an exception. With 
> unlimited integers, the result would be LONG_MAX + 1, which equals 
> LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
> arithmetics.
> 
> Roland
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/644bba0e/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 10:38:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:38:46 +0000
Subject: [M3devel] in favor of mixed operators..
Message-ID: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>


http://python-history.blogspot.com/2009/03/problem-with-integer-division.html


He argues that for a "high level" language, of course
I should be able to add int to long, int to float, etc.
And that int / int should not be int.
At least Modula-3 spells them differently, / vs. MOD.


Of course, "high level" vs. "systems" vs. "one size to fit all"...


Anyway, I give up here.


 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/3f7a2e00/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 10:36:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:36:55 +0000
Subject: [M3devel] integer division rounding?
Message-ID: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>


Modula-3 apparently specifies integer division as rounding down.
http://www.modula3.com/cm3/doc/reference/arithmetic.html

C used to leave it unspecified. So it could be fast.
Fortran rounded to zero.
C's ldiv function rounds to zero.
C now rounds to zero with C99.
  The rationale was that nobody using Fortran seemed to mind.
Java apparently rounds toward zero.
C# apparently rounds toward zero.


I'm assuming we are stuck being different here?

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/f4cdb077/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 10:41:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:41:26 +0000
Subject: [M3devel] rd/wr beyond 2GB on 32bit?
Message-ID: <COL101-W501F667E0F501DC8B6E0C1E6670@phx.gbl>


Anyone have ideas or time to think about or work on fixing rd/wr to support going past 2GB on 32bit platforms?
Well, it's easy to get to 64bits.
  - is that enough? Probably. How many rd/wr are "infinite" and long enough lived to exceed 64bits?
  - at what cost to breaking existing code? I sent approximate diffs. A little gnarly.
   Maybe add SeekL, LengthL, etc.?

 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/6d98f794/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 11:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:44:53 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>


-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/065bb5f7/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 11:50:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:50:18 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>


I think I missed a sign.




-2147483648 - 2147483647  * -2
 actually -2147483648 + 2 * 2147483647

  actually 2147483646

which agrees.

so 




-2147483648 div 2147483647 = -2 
-2147483648 mod 2147483647 = 2147483646 

-2 * 2147483647 + 2147483646  = -2147483648

I'll make sure m3_mod works this way if it doesn't already.
Presumably we are stuck with these rules.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: integer division/mod questions?
Date: Sun, 17 Jan 2010 10:44:53 +0000








-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/7702d6cc/attachment-0001.html>

From wagner at elegosoft.com  Sun Jan 17 12:38:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 12:38:16 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>   We do want LONGCARD in the release, I assume.
>
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
>  And take the LONGCARD changes.

 From a release engineering point of view this is more or less
a nightmare. We cannot make incompatible extensions to the feature
set after the fourth release candidate.

The only clean way I'd see to even get the LONGINT changes into the
next release would be to start anew. Meaning declaring 5.8.4 as
the latest release and develop 5.9 on the trunk. Of course we'd
have to carefully merge back any fixes that might be missing on the
trunk right now.

That said, I have currently neither the time nor the energy to do all
that cleanly. I didn't even get round to set up release builds
on new.elego.de via Hudson in order to cover the FreeBSD4 target
platform we recently lost in the release due to my home machine's
complete crash in December. So the release engineering support is not
in the best of states I must admit.

I could live with declaring 5.8.RC4 as an intermediate release,
but somebody really needs to do all the housekeeping of comparing
and merging branches. And we shouldn't start a new release branch
until things have settled down.

Is anybody interested in taking over some of the release engineering
tasks (including Hudson management and re-targeting to the new release)?

Please keep in mind that we haven't managed to get out a stable release
for several years now.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Sun Jan 17 14:21:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 14:21:37 +0100
Subject: [M3devel] Hudson RELENG builds broken
Message-ID: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>

Several Hudson builds are currently broken due to

new source -> compiling ProcessPosixCommon.m3
"../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
qualification '.' (sleep)
1 error encountered
new source -> compiling ProcessPosix.m3

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
for example.

I'm really not sure that we should copy the incompatible
LONGINT and LONGCARD changes to this release branch...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Sun Jan 17 14:33:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:33:42 +0000
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <COL101-W3172F677C46972D488A4F8E6670@phx.gbl>


Sorry, my fault, should be ok now.
Nothing to do with LONGINT/LONGCARD.

 - Jay


> Date: Sun, 17 Jan 2010 14:21:37 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Hudson RELENG builds broken
> 
> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
> qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/d601908b/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 14:42:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:42:57 +0000
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>


We can stick with the current release branch if that is indeed much easier.



I thought there was some agreement we shouldn't release LONGINT as it was.
I can undo the changes if we want.
It's not easy with cvs (not much is) but I can do it.
It's easy for me to diff the trees, just using windiff or diff (again, cvs
seems not to help).



Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
but diff tells us better.


I'm still planning on setting up some more machines and can do FreeBSD4.
(I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
I have to check if Modula-3 actually works on them first...)


Does anyone have the missing steps for the cvsup bug report, like the configuration file,
can show the callstacks, try it with user threads..etc..?


 - Jay


> Date: Sun, 17 Jan 2010 12:38:16 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > Should we just make a new release branch?
> > Or I keep copying stuff over somewhat selectively?
> >   We do want LONGCARD in the release, I assume.
> >
> > I'll diff the two trees again, see what varies.
> > Sometimes when I do that I find stuff to take.
> >  And take the LONGCARD changes.
> 
>  From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/dfa99ae5/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 17 14:55:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:55:34 +0000
Subject: [M3devel] how division and modulo work in hand.c?
Message-ID: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>


I have to admit I don't fully understand
the division and modulo code in hand.c.


I don't understand the old division code,
but the documenation and behavior are
clear: round down. I understand
why my version works, though it might
depend on non-guaranteed behavior in C division
for the same sign cases. An earlier version
was clearer since it avoided doing anything
with negative numbers execpt negating them
(and carefully at that).


Modulo is much less clear to me.
>From testing vs. the documentation, I know the
old code was wrong, though close.
I made some guesses based on the old code and
ran a variety of inputs through it.
My version matches the old version, except
where the old version is wrong.
I could write a clearly correct version, but it
would be perhaps much less efficient, just
computing a - b * div(a, b).


I tried running all 32bit inputs through some of it but it was
going to take too long.
I could maybe leave that running a few days if needed.

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/cb1223c4/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:05:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:05:44 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>

What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

On 17 Jan 2010, at 04:36, Jay K wrote:

> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> C used to leave it unspecified. So it could be fast.
> Fortran rounded to zero.
> C's ldiv function rounds to zero.
> C now rounds to zero with C99.
>   The rationale was that nobody using Fortran seemed to mind.
> Java apparently rounds toward zero.
> C# apparently rounds toward zero.
> 
> 
> I'm assuming we are stuck being different here?
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/5d8ecb47/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:08:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:08:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
Message-ID: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>

On 17 Jan 2010, at 05:50, Jay K wrote:

> I think I missed a sign.
> 
> -2147483648 - 2147483647  * -2
>  actually -2147483648 + 2 * 2147483647
>   actually 2147483646
> 
> which agrees.
> 
> so 
> 
> -2147483648 div 2147483647 = -2 
> -2147483648 mod 2147483647 = 2147483646 
> 
> -2 * 2147483647 + 2147483646  = -2147483648
> 
> I'll make sure m3_mod works this way if it doesn't already.
> Presumably we are stuck with these rules.

Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: integer division/mod questions?
> Date: Sun, 17 Jan 2010 10:44:53 +0000
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 
> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of the quotient of x and y; that is, the maximum integer not exceeding the real number z such that z * y = x. For integers x and y, the value of x MOD y is defined to be x - y * (x DIV y). This means that for positive y, the value of x MOD y lies in the interval [0 .. y-1], regardless of the sign of x. For negative y, the value of x MOD y lies in the interval [y+1 .. 0], regardless of the sign of x. 
> 
> -2147483648 - 2147483647  * -2
> -2147483648 +2  (due to overflow)
> -2147483646
> 
> which contradicts the second part.
> 
> Maybe I'm confused? I should work this all through again?
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/e8249050/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:10:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:10:18 -0500
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <A15FF600-B5FD-4A12-9F35-3BA91BC69B4D@cs.purdue.edu>

On 17 Jan 2010, at 08:21, Olaf Wagner wrote:

> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...

I think we definitely should.  There were some rough edges in the implementation of LONGINT/LONGCARD that needed tidying.  This is our first release with them and we should make sure to have it right for the release.  The problem you see above is something we can fix!

> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Sun Jan 17 17:12:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:12:13 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>

I think that we are closest now to a release we can be happy with than for some time.  It would be a huge shame not to push this out the door.

On 17 Jan 2010, at 06:38, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Should we just make a new release branch?
>> Or I keep copying stuff over somewhat selectively?
>>  We do want LONGCARD in the release, I assume.
>> 
>> I'll diff the two trees again, see what varies.
>> Sometimes when I do that I find stuff to take.
>> And take the LONGCARD changes.
> 
> From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/f5384813/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:13:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:13:39 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
Message-ID: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>

On 17 Jan 2010, at 08:42, Jay K wrote:

> We can stick with the current release branch if that is indeed much easier.
> 
> 
> I thought there was some agreement we shouldn't release LONGINT as it was.

Indeed!

> I can undo the changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff or diff (again, cvs
> seems not to help).

Surely we can move forward on this.

> Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
> but diff tells us better.

I agree.

> I'm still planning on setting up some more machines and can do FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them first...)

Let's not worry about additional targets. 

> Does anyone have the missing steps for the cvsup bug report, like the configuration file,
> can show the callstacks, try it with user threads..etc..?

Maybe cvsup should not be part of the release?

> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more or less
> > a nightmare. We cannot make incompatible extensions to the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT changes into the
> > next release would be to start anew. Meaning declaring 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of course we'd
> > have to carefully merge back any fixes that might be missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the energy to do all
> > that cleanly. I didn't even get round to set up release builds
> > on new.elego.de via Hudson in order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my home machine's
> > complete crash in December. So the release engineering support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate release,
> > but somebody really needs to do all the housekeeping of comparing
> > and merging branches. And we shouldn't start a new release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the release engineering
> > tasks (including Hudson management and re-targeting to the new release)?
> > 
> > Please keep in mind that we haven't managed to get out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/cae01ca8/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 17 17:39:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:39:03 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
Message-ID: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>

TRUNC_DIV_EXPR
FLOOR_DIV_EXPR
CEIL_DIV_EXPR
ROUND_DIV_EXPR
These nodes represent integer division operations that return an integer result. TRUNC_DIV_EXPR rounds towards zero, FLOOR_DIV_EXPRrounds towards negative infinity, CEIL_DIV_EXPR rounds towards positive infinity and ROUND_DIV_EXPR rounds to the closest integer. Integer division in C and C++ is truncating, i.e. TRUNC_DIV_EXPR.
The behavior of these operations on signed arithmetic overflow, when dividing the minimum signed integer by minus one, is controlled by the flag_wrapv and flag_trapv variables. 

TRUNC_MOD_EXPR
FLOOR_MOD_EXPR
CEIL_MOD_EXPR
ROUND_MOD_EXPR
These nodes represent the integer remainder or modulus operation. The integer modulus of two operands a and b is defined as a - (a/b)*b where the division calculated using the corresponding division operator. Hence for TRUNC_MOD_EXPR this definition assumes division using truncation towards zero, i.e. TRUNC_DIV_EXPR. Integer remainder in C and C++ uses truncating division, i.e.TRUNC_MOD_EXPR. 

This is a quote from the gcc internals manual.  I've always wondered why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for known positive operands.  What would be wrong about using them also for negative operands?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 17 Jan 2010, at 08:55, Jay K wrote:

> I have to admit I don't fully understand
> the division and modulo code in hand.c.
> 
> 
> I don't understand the old division code,
> but the documenation and behavior are
> clear: round down. I understand
> why my version works, though it might
> depend on non-guaranteed behavior in C division
> for the same sign cases. An earlier version
> was clearer since it avoided doing anything
> with negative numbers execpt negating them
> (and carefully at that).
> 
> 
> Modulo is much less clear to me.
> From testing vs. the documentation, I know the
> old code was wrong, though close.
> I made some guesses based on the old code and
> ran a variety of inputs through it.
> My version matches the old version, except
> where the old version is wrong.
> I could write a clearly correct version, but it
> would be perhaps much less efficient, just
> computing a - b * div(a, b).
> 
> 
> I tried running all 32bit inputs through some of it but it was
> going to take too long.
> I could maybe leave that running a few days if needed.
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/91a3145d/attachment-0001.html>

From rodney_bates at lcwb.coop  Sun Jan 17 18:29:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 17 Jan 2010 11:29:28 -0600
Subject: [M3devel] integer division rounding?
In-Reply-To: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
	<9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
Message-ID: <4B5348F8.6070605@lcwb.coop>



Tony Hosking wrote:
> What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

For all of these, it is not so easy to decide what is the authoritative
definition.  They all suffer from worse dialect proliferation than Modula-3.
----------------------------------------------------------------------------
Original  Pascal report "The programming Language Pascal", Acta
Informatica, 1, 35-6 (1971) just says div is "division with truncation"
and the usual relationship: "m mod n = m-((m div n)*n)"

Does "truncate" mean towards zero or towards minus infinity?  Read on.
----------------------------------------------------------------------------
"An Axiomatic Definition of the Programming Langauge Pascal",
by C. A. R. Hoare and N. Wirth (apparently a tech report from
Eidgenoessische Technische Hochschule Zuerich (November 1972) says only:

"3.10. (m>=0) ^ ((n>0) => m-n < (m div n)*n <= m"

leaving div undefined for either operand negative.  It does give the
usual relationship.

----------------------------------------------------------------------------
"A Draft Proposal for Pascal", by A.M.Addyman (I have no citation
info for this, except the heading "technical contributions"--maybe
this was SIGPLAN?) says:

"It shall be an error if j is zero, otherwise the value of i div j
shall be such that
abs(i) - abs(j) < abs((i div j) * j) <= abs(i)
where the value shall be zero if abs(i)<abs(j), otherwise the sign
of the value shall be positive if i and j have the same sign and
negative if i and j have different signs.

This is truncating toward zero, which agrees with my memory about Pascal.
------------------------------------------------------------------------------
A "Draft ISO Standard for Pascal" that I have, dated 1982-08-12,
says the same thing about div, but adds:

"A term of the form i mod j shall be an error if j is zero or negative, otherwise the
value of i mod j shall be that value of (i-(k*j)) for integral k such that
0 <= i mod j < j."

disallowing negative j.
-----------------------------------------------------------------------------------
"Programming in Modula-2", Niklaus Wirth, 4th edition, Springer-Verlag, 1988, says:

"x DIV y is equal to the truncated quotient of x/y
  x MOD y is equal to the remainder of the division x DIV y
  x = (x DIV y) * y + (x MOD y), 0 <= (x MOD y) < y"

the last condition implying that MOD is either undefined or an error
for negative y.
-----------------------------------------------------------------------------------

I don't have any Oberon variant definitions quickly accessible.

I recall disliking the Pascal/M2 habit of truncating towards zero as both
inconsistent with traditional mathematics and not want you need as a programmer,
at least in the application of doing subscript arithmetic in circular buffers.
I was glad to see Modula-3 fix that.

> 
> On 17 Jan 2010, at 04:36, Jay K wrote:
> 
>> Modula-3 apparently specifies integer division as rounding down.
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> C used to leave it unspecified. So it could be fast.
>> Fortran rounded to zero.
>> C's ldiv function rounds to zero.
>> C now rounds to zero with C99.
>>   The rationale was that nobody using Fortran seemed to mind.
>> Java apparently rounds toward zero.
>> C# apparently rounds toward zero.
>>
>>
>> I'm assuming we are stuck being different here?
>>
>>  - Jay
>>
> 


From wagner at elegosoft.com  Sun Jan 17 19:44:29 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 19:44:29 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs. head?
In-Reply-To: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
Message-ID: <20100117194429.pvmnaij280s4gck0@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> I think that we are closest now to a release we can be happy with   
> than for some time.  It would be a huge shame not to push this out   
> the door.

OK, I doubt there is very much interest from other users how we do this,
so let's be unorthodox again ;-) Let's just stick to the existing
release branch and let RC 5.8.5 be somewhat incompatible with RC 5.8.4.
Everything else would be too much hassle for too few users
(at least I think so). As I doubt there's anybody who wants to start
the release engineering again, we will just use the existing branch
and move forward.

Any objections?

Olaf

> On 17 Jan 2010, at 06:38, Olaf Wagner wrote:
>
>> Quoting Jay K <jay.krell at cornell.edu>:
>>
>>> Should we just make a new release branch?
>>> Or I keep copying stuff over somewhat selectively?
>>>  We do want LONGCARD in the release, I assume.
>>>
>>> I'll diff the two trees again, see what varies.
>>> Sometimes when I do that I find stuff to take.
>>> And take the LONGCARD changes.
>>
>> From a release engineering point of view this is more or less
>> a nightmare. We cannot make incompatible extensions to the feature
>> set after the fourth release candidate.
>>
>> The only clean way I'd see to even get the LONGINT changes into the
>> next release would be to start anew. Meaning declaring 5.8.4 as
>> the latest release and develop 5.9 on the trunk. Of course we'd
>> have to carefully merge back any fixes that might be missing on the
>> trunk right now.
>>
>> That said, I have currently neither the time nor the energy to do all
>> that cleanly. I didn't even get round to set up release builds
>> on new.elego.de via Hudson in order to cover the FreeBSD4 target
>> platform we recently lost in the release due to my home machine's
>> complete crash in December. So the release engineering support is not
>> in the best of states I must admit.
>>
>> I could live with declaring 5.8.RC4 as an intermediate release,
>> but somebody really needs to do all the housekeeping of comparing
>> and merging branches. And we shouldn't start a new release branch
>> until things have settled down.
>>
>> Is anybody interested in taking over some of the release engineering
>> tasks (including Hudson management and re-targeting to the new release)?
>>
>> Please keep in mind that we haven't managed to get out a stable release
>> for several years now.
>>
>> Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Sun Jan 17 21:19:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:19:14 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100117201914.GD11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 09:36:55AM +0000, Jay K wrote:
> 
> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html

In my experience, the rounding direction on division as supported by 
hardware seems is correlated with whether the processor uses one's 
complement or two's complement arithmetic.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:34:06 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:34:06 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
Message-ID: <20100117203406.GE11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 

There are two kinds of binary integer arithmetic -- two's complement 
and one's complement.  In my experience, two's complement machines tend 
to have the remainder being the same sign as the dividend; one's 
complement machines semm to have a remainder the same sign as the 
divisor.

One's complement machines are all but extinct these days.

> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of 
> the quotient of x and y; that is, the maximum integer 
> not exceeding the real number z such that z * y = x.
> For integers x and y, the value of x MOD y is 
> defined to be x - y * (x DIV y).
> 
> 
> This means that for positive y, the value of x MOD y
> lies in the interval [0 .. y-1], regardless of 
> the sign of x.  For negative y, the value of
> x MOD y lies in the interval [y+1 .. 0], regardless 
> of the sign of x.

And this is consistent with MOD producing a canonical representative of 
an equivalence class modulo y.  It's what's wanted for a lot of 
algorithms.  What it returns for negative y isn't as important, but 
it is important to have positive MODuli for positive y no matter what 
the sign of x is.

But it's not what most two's-complement processors produce naturally.  
Having a MODulo operation that is mathematically well-behaved takes 
extra effort on these machines.

And it's also important to have a remainder that corresponds to the 
division operator.  On two's complement machines you have to either
  * use extra instructions to correct the result of the divide 
    instruction to correspond to the mathematically desirable MOD 
    operator, or
  * Have a separate remainder operation that does correspond to 
    division.

On one's complement machines MOD will have the same effect as remainder.
On two's complement, different.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:39:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:39:42 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
Message-ID: <20100117203942.GF11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> On 17 Jan 2010, at 05:50, Jay K wrote:
> 
> > I think I missed a sign.
> > 
> > -2147483648 - 2147483647  * -2
> >  actually -2147483648 + 2 * 2147483647
> >   actually 2147483646
> > 
> > which agrees.
> > 
> > so 
> > 
> > -2147483648 div 2147483647 = -2 
> > -2147483648 mod 2147483647 = 2147483646 
> > 
> > -2 * 2147483647 + 2147483646  = -2147483648
> > 
> > I'll make sure m3_mod works this way if it doesn't already.
> > Presumably we are stuck with these rules.
> 
> Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

It gives results that satisfy important mathematical identities, such as

     (a + m) MOD m = a MOD m

which makes it easier to reason about the correctness of algorithms and 
program  transformations.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:48:30 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:48:30 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
Message-ID: <20100117204830.GG11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> 
> This is a quote from the gcc internals manual.  I've always wondered 
> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for 
> known positive operands.  What would be wrong about using them also 
> for negative operands?

What does cm3cg use for operands that are not known to be positive?

-- hendrik


From hosking at cs.purdue.edu  Sun Jan 17 22:19:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 15:19:21 -0600
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <20100117204830.GG11416@topoi.pooq.com>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
	<20100117204830.GG11416@topoi.pooq.com>
Message-ID: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>

It calls the C routines in hand.c.

Sent from my iPhone

On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
>>
>> This is a quote from the gcc internals manual.  I've always wondered
>> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
>> known positive operands.  What would be wrong about using them also
>> for negative operands?
>
> What does cm3cg use for operands that are not known to be positive?
>
> -- hendrik


From jay.krell at cornell.edu  Mon Jan 18 02:01:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:01:39 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203942.GF11416@topoi.pooq.com>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>,
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>,
	<20100117203942.GF11416@topoi.pooq.com>
Message-ID: <COL101-W61AE85464E81AF91D50FA3E6660@phx.gbl>


Thanks Hendrik. I didn't realize the relationship to one's complement.

In my little experimentation:

 C modulo, which I assume is machine modulo, returns the sign of the first parameter.

 Modula-3 specifies it to have the sign of the second parameter.

 The "formula" appears to hold either way.

  But I'd have to double check.

 

 

Hand.c used "tricks" to implement div and mod.

My replacement functions are clear for div but still tricky for mod.

I don't understand the tricks.

In fact I just guessed and wrote something similar to the original, but different.

 

 

One goal was to avoid dependency on signed arithmetic overflow, though

 I compromised somewhat, I think. That is, I'm not sure if negative / negative

  and negative mod negative in C depend on overflow.

  What gcc was telling me is the "trick" in the old div function did depend

  on modulo. Ultimately I'm not sure if this dependency was even a problem or not,

  as the bug at least for div tended to occur more with unoptimized compilation.

  Optimization actually tended to fix the bug. But it did vary with compilers.

  Specifically dividing and moding LONG_MIN (or INT64_MIN) by negative numbers

  produced a result with the wrong sign. There was probably also a problem

  with K&R style. The "crash" or "trap" was appropriate.

 

 

I was *actually* wondering if depency on overflow would be a problem

for the other functions I added, but apparently not.

Still I might consider writing them to use only unsigned, or deleting them.

 

 

One of my implied questions is:
  Do people believe my changes are correct?

  Please look at them.

  Esp. mod.

 

 

 - Jay

 
> Date: Sun, 17 Jan 2010 15:39:42 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> > On 17 Jan 2010, at 05:50, Jay K wrote:
> > 
> > > I think I missed a sign.
> > > 
> > > -2147483648 - 2147483647 * -2
> > > actually -2147483648 + 2 * 2147483647
> > > actually 2147483646
> > > 
> > > which agrees.
> > > 
> > > so 
> > > 
> > > -2147483648 div 2147483647 = -2 
> > > -2147483648 mod 2147483647 = 2147483646 
> > > 
> > > -2 * 2147483647 + 2147483646 = -2147483648
> > > 
> > > I'll make sure m3_mod works this way if it doesn't already.
> > > Presumably we are stuck with these rules.
> > 
> > Yep. I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how. Anyone?
> 
> It gives results that satisfy important mathematical identities, such as
> 
> (a + m) MOD m = a MOD m
> 
> which makes it easier to reason about the correctness of algorithms and 
> program transformations.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/0791186c/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jan 18 02:06:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:06:32 +0000
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
Message-ID: <COL101-W4203E93E82A73319794582E6660@phx.gbl>


I *speculate*:

   If the inputs to div or mod are known to have the same sign: don't bother calling the functions.

      Certainly that is clear for two positive inputs in the old functions.

   If either input to div is known to be zero, ditto. Presumably not a common case.

      And *maybe* we want to alter how divide by zero works to reliably trap or not trap.

 

  For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.

    (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)

 

 

 - Jay


 
> From: hosking at cs.purdue.edu
> To: hendrik at topoi.pooq.com
> Date: Sun, 17 Jan 2010 15:19:21 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how division and modulo work in hand.c?
> 
> It calls the C routines in hand.c.
> 
> Sent from my iPhone
> 
> On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> >>
> >> This is a quote from the gcc internals manual. I've always wondered
> >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> >> known positive operands. What would be wrong about using them also
> >> for negative operands?
> >
> > What does cm3cg use for operands that are not known to be positive?
> >
> > -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/95985a3a/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jan 18 02:11:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:11:20 +0000
Subject: [M3devel] another change in hand.c
Message-ID: <COL101-W46DA48ECED7FEDC4F05B82E6660@phx.gbl>


Also I changed set_eq and set_ne to just use memcmp.

 

 

That certainly appears correct.

I believe I added some tests to m3-sys/m3tests.

I also changed the integrated backend to call memcmp directly.

Given the input is known to be ulongs not just bytes, this

might be a deoptimization. However hand.c isn't necessarily

compiled with optimizations.

 

 

You know, memcmp generally handles any alignment.

First it often has to handle a leading unaligned part before

proceeding to compare data in larger chunks.

Whereas if you know the alignment you can be faster.

 

 

I believe m3front inlines for small sets anyway.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/71288892/attachment-0001.html>

From mika at async.async.caltech.edu  Mon Jan 18 02:58:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:58:33 -0800
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl> 
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <20100118015833.708F71A207C@async.async.caltech.edu>


Jay I think the following paragraph is important and demonstrates why
this article is perhaps less relevant to Modula-3:

When you write a function implementing a numeric algorithm (for example,
calculating the phase of the moon) you typically expect the arguments
to be specified as floating point numbers. However, since Python doesnt
have type declarations, nothing is there to stop a caller from providing
you with integer arguments. In a statically typed language, like C,
the compiler will coerce the arguments to floats, but Python does no
such thing  the algorithm is run with integer values until the wonders
of mixed-mode arithmetic produce intermediate results that are floats.

     Mika

Jay K writes:
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml
>
>
>He argues that for a "high level" language=2C of course
>I should be able to add int to long=2C int to float=2C etc.
>And that int / int should not be int.
>At least Modula-3 spells them differently=2C / vs. MOD.
>
>
>Of course=2C "high level" vs. "systems" vs. "one size to fit all"...
>
>
>Anyway=2C I give up here.
>
>
> - Jay
>
>
>
>
> 		 	   		  =
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml<br><br><br>He argues that for a "high level" language=2C of course<br>I =
>should be able to add int to long=2C int to float=2C etc.<br>And that int /=
> int should not be int.<br>At least Modula-3 spells them differently=2C / v=
>s. MOD.<br><br><br>Of course=2C "high level" vs. "systems" vs. "one size to=
> fit all"...<br><br><br>Anyway=2C I give up here.<br><br><br>&nbsp=3B- Jay<=
>br><br><br><br><br> 		 	   		  </body>
></html>=
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_--


From mika at async.async.caltech.edu  Mon Jan 18 02:59:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:59:59 -0800
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl> 
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100118015959.BB9911A207C@async.async.caltech.edu>

Jay K writes:
>--_80188ab7-0cb8-4a34-8b91-f5a76ee2640e_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Modula-3 apparently specifies integer division as rounding down.
>http://www.modula3.com/cm3/doc/reference/arithmetic.html
>
>C used to leave it unspecified. So it could be fast.
>Fortran rounded to zero.
>C's ldiv function rounds to zero.
>C now rounds to zero with C99.
>  The rationale was that nobody using Fortran seemed to mind.
>Java apparently rounds toward zero.
>C# apparently rounds toward zero.
>
>
>I'm assuming we are stuck being different here?
>
> - Jay
>

This is because Modula-3 has MOD while C has "remainder" (%).

If you use the normal definition of MOD you're stuck with making
DIV match it I think...

    Mika


From hendrik at topoi.pooq.com  Mon Jan 18 03:21:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 21:21:35 -0500
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118015833.708F71A207C@async.async.caltech.edu>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
	<20100118015833.708F71A207C@async.async.caltech.edu>
Message-ID: <20100118022134.GA23436@topoi.pooq.com>

On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> 
> Jay I think the following paragraph is important and demonstrates why
> this article is perhaps less relevant to Modula-3:
> 
> When you write a function implementing a numeric algorithm (for example,
> calculating the phase of the moon) you typically expect the arguments
> to be specified as floating point numbers. However, since Python doesnt
> have type declarations, nothing is there to stop a caller from providing
> you with integer arguments. In a statically typed language, like C,
> the compiler will coerce the arguments to floats, but Python does no
> such thing  the algorithm is run with integer values until the wonders
> of mixed-mode arithmetic produce intermediate results that are floats.
> 
>      Mika
> 
> Jay K writes:
> >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> >ml
> >
> >
> >He argues that for a "high level" language=2C of course

He identifies python as a high-level language.  His arguments about what 
a high-level language should do are based on python's absence of static 
typing.  Thus he comes to his conclusion, having identified the concept 
of "high level" with "no static typing".  Presumably he thinls that 
types are an inconvenience inflicted by the desire for run-time 
efficiency.  Many people believe this, failing entirely to notice that 
static typing is a powerful tool in the pursuit of correctness.

-- hendrik


From jay.krell at cornell.edu  Mon Jan 18 04:37:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 03:37:30 +0000
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118022134.GA23436@topoi.pooq.com>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>,
	<20100118015833.708F71A207C@async.async.caltech.edu>,
	<20100118022134.GA23436@topoi.pooq.com>
Message-ID: <COL101-W38145B37DE6AD23BE9C563E6660@phx.gbl>


I am mostly a believer in static types.

 

Though there sure is an interesting place in

languages like C#, C++, ML, where the compiler

is *obligated* in many contexts to deduce static

type and in which it really isn't very controversial.

 

This leads to, for example, qsort that can "easily"

inline the comparison function and beat C.

 

C# has this nifty "LINQ" stuff where to actually

have the programmer state the static types

would be quite onerous.

 

 

A similar scenario is "expression templates" in C++.

Where you have a + b * c / d and the types

of a, b, c, d are a variety of vectors/matrices,

and there are no actual intermediate computations done,

just one inner loop, because the type of the overloads

doesn't hold an intermediate result but rather sort of "directions"

on how to proceed. See Todd Veldhuzien's fascinating work.

http://en.wikipedia.org/wiki/Expression_templates

 

 

The dynamic type proponents do have strong arguments in some situations:

 - You are going to throw out the code soon anyway, sometimes.

 - You have to run it, test it, and that somewhat substitutes for whatever checks the "compiler" makes.

 

 - Jay





 
> Date: Sun, 17 Jan 2010 21:21:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] in favor of mixed operators..
> 
> On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> > 
> > Jay I think the following paragraph is important and demonstrates why
> > this article is perhaps less relevant to Modula-3:
> > 
> > When you write a function implementing a numeric algorithm (for example,
> > calculating the phase of the moon) you typically expect the arguments
> > to be specified as floating point numbers. However, since Python doesnt
> > have type declarations, nothing is there to stop a caller from providing
> > you with integer arguments. In a statically typed language, like C,
> > the compiler will coerce the arguments to floats, but Python does no
> > such thing the algorithm is run with integer values until the wonders
> > of mixed-mode arithmetic produce intermediate results that are floats.
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> > >ml
> > >
> > >
> > >He argues that for a "high level" language=2C of course
> 
> He identifies python as a high-level language. His arguments about what 
> a high-level language should do are based on python's absence of static 
> typing. Thus he comes to his conclusion, having identified the concept 
> of "high level" with "no static typing". Presumably he thinls that 
> types are an inconvenience inflicted by the desire for run-time 
> efficiency. Many people believe this, failing entirely to notice that 
> static typing is a powerful tool in the pursuit of correctness.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/3ce6d925/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jan 18 14:05:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 13:05:58 +0000
Subject: [M3devel] FW: __int128 coming to gcc
In-Reply-To: <1263819673.24181.ezmlm@gcc.gnu.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
Message-ID: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>


gcc 4.6 apparently will have __int128.

How long until we have LONGLONGINT or INT128?

Presumably we should have LONGLONGINT or INT128 to expose it?

:)

 

 

Or, again, I should look at the arithemetic library...

 

 

 - Jay

 

 

Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
 
... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  	review
	255919 by: Kai Tietz <ktietz70@>
 
...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
.... 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/9e165e65/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 18 14:47:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 08:47:41 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W4203E93E82A73319794582E6660@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
	<COL101-W4203E93E82A73319794582E6660@phx.gbl>
Message-ID: <533DD3F9-B74D-4796-AD6D-CA3986A610C1@cs.purdue.edu>

cm3cg currently only uses FLOOR_DIV_EXPR for known positive integers.  For anything else it calls out to the library.

On 17 Jan 2010, at 20:06, Jay K wrote:

> I *speculate*:
>    If the inputs to div or mod are known to have the same sign: don't bother calling the functions.
>       Certainly that is clear for two positive inputs in the old functions.
>    If either input to div is known to be zero, ditto. Presumably not a common case.
>       And *maybe* we want to alter how divide by zero works to reliably trap or not trap.
>  
>   For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.
>     (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > To: hendrik at topoi.pooq.com
> > Date: Sun, 17 Jan 2010 15:19:21 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] how division and modulo work in hand.c?
> > 
> > It calls the C routines in hand.c.
> > 
> > Sent from my iPhone
> > 
> > On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> > 
> > > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> > >>
> > >> This is a quote from the gcc internals manual. I've always wondered
> > >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> > >> known positive operands. What would be wrong about using them also
> > >> for negative operands?
> > >
> > > What does cm3cg use for operands that are not known to be positive?
> > >
> > > -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/0b0f15fd/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Jan 18 15:03:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 09:03:21 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
Message-ID: <298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>

On 18 Jan 2010, at 08:05, Jay K wrote:

> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)

Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as

BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]

>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/53e93722/attachment-0001.html>

From Highjinks at gmx.com  Mon Jan 18 23:11:15 2010
From: Highjinks at gmx.com (Chris)
Date: Mon, 18 Jan 2010 23:11:15 +0100 (CET)
Subject: [M3devel] Explicit types.
Message-ID: <20100118181413.6aaac7d6.Highjinks@gmx.com>

I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.

I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
	
	TYPE UnsignedInt64 ...
	TYPE SignedInt64 ...
	TYPE UnsignedInt32 ...
	TYPE SignedInt32 ...

etc...

Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.

Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.

I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.

I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.

-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Mon Jan 18 23:17:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 17:17:54 -0500
Subject: [M3devel] Explicit types.
In-Reply-To: <20100118181413.6aaac7d6.Highjinks@gmx.com>
References: <20100118181413.6aaac7d6.Highjinks@gmx.com>
Message-ID: <1F367F97-CA3E-4EE4-A103-C446A21BF339@cs.purdue.edu>

Hi Chris,

I think we gave settled on a good fit for long integer types for Modula-3.  Things are unlikely to change further.

--  Tony

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 18 Jan 2010, at 17:11, Chris wrote:

> I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.
> 
> I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
> 	
> 	TYPE UnsignedInt64 ...
> 	TYPE SignedInt64 ...
> 	TYPE UnsignedInt32 ...
> 	TYPE SignedInt32 ...
> 
> etc...
> 
> Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.
> 
> Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.
> 
> I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.
> 
> I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.
> 
> -- 
> Chris <Highjinks at gmx.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/646b47c4/attachment-0001.html>

From rodney_bates at lcwb.coop  Wed Jan 20 01:39:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 19 Jan 2010 18:39:22 -0600
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203406.GE11416@topoi.pooq.com>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
Message-ID: <4B5650BA.6030601@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>> -2147483648 div 2147483647 ?
>> -2147483648 mod 2147483647 ?
>>
>> quotient = -1, remainer = -1 seems reasonable.
>> 2147483647 * -1 + -1 == -2147483648
>>
> 
> There are two kinds of binary integer arithmetic -- two's complement 
> and one's complement.  In my experience, two's complement machines tend 
> to have the remainder being the same sign as the dividend; one's 
> complement machines semm to have a remainder the same sign as the 
> divisor.
> 
> One's complement machines are all but extinct these days.

Tony, you were concerned about showing your age, but 20 years is but an
evening past.  I remember programming ones-complement arithmetic
in assembly language, definitely more decades ago than two.
And that was not my first job.

There is a positive zero and a negative zero, and which one you get
can depend on the operation and operand values that produced the
result, so you have to check for both of them, often with two
separate conditional branches.

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?


> 
>> However, Modula-3 specifies div as rounding down, so
>>
>> -2147483648 div 2147483647  == -2
>>
>> and then
>>
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> The value x DIV y is the floor of 
>> the quotient of x and y; that is, the maximum integer 
>> not exceeding the real number z such that z * y = x.
>> For integers x and y, the value of x MOD y is 
>> defined to be x - y * (x DIV y).
>>
>>
>> This means that for positive y, the value of x MOD y
>> lies in the interval [0 .. y-1], regardless of 
>> the sign of x.  For negative y, the value of
>> x MOD y lies in the interval [y+1 .. 0], regardless 
>> of the sign of x.
> 
> And this is consistent with MOD producing a canonical representative of 
> an equivalence class modulo y.  It's what's wanted for a lot of 
> algorithms.  What it returns for negative y isn't as important, but 
> it is important to have positive MODuli for positive y no matter what 
> the sign of x is.
> 
> But it's not what most two's-complement processors produce naturally.  
> Having a MODulo operation that is mathematically well-behaved takes 
> extra effort on these machines.
> 
> And it's also important to have a remainder that corresponds to the 
> division operator.  On two's complement machines you have to either
>   * use extra instructions to correct the result of the divide 
>     instruction to correspond to the mathematically desirable MOD 
>     operator, or
>   * Have a separate remainder operation that does correspond to 
>     division.
> 
> On one's complement machines MOD will have the same effect as remainder.
> On two's complement, different.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed Jan 20 03:45:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:45:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <COL101-W5066919E7799495954BF25E6640@phx.gbl>


> There is a positive zero and a negative zero, and which one you get 

 
 Rodney you reminded me of something I forgot to ask: 
 
 
Is 0 div -1 = 0 or -1?
 
 
In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
If 0> -0, then 0 div -1 should equal -1 instead of 0.
 
 
My current code I believe returns 0 for 0 div anything.
  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
 
 
The previous code probably also but I'll have to double check.
  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
 
 
  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
 
 
  Nice if anyone can reproduce the problem with K&R + long long as well.
  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
 
 
  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
 
 
  In particular, LONG_MIN div or mod -1 can trap.
 
 
  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
 
 
(anywhere I say "LONG_MIN", INT64_MIN has similar problem)
 
 
 
 - Jay


----------------------------------------
> Date: Tue, 19 Jan 2010 18:39:22 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>
> hendrik at topoi.pooq.com wrote:
>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>> -2147483648 div 2147483647 ?
>>> -2147483648 mod 2147483647 ?
>>>
>>> quotient = -1, remainer = -1 seems reasonable.
>>> 2147483647 * -1 + -1 == -2147483648
>>>
>>
>> There are two kinds of binary integer arithmetic -- two's complement
>> and one's complement. In my experience, two's complement machines tend
>> to have the remainder being the same sign as the dividend; one's
>> complement machines semm to have a remainder the same sign as the
>> divisor.
>>
>> One's complement machines are all but extinct these days.
>
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past. I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
>
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
>
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines? Electromechanical accounting machines?
>
>
>>
>>> However, Modula-3 specifies div as rounding down, so
>>>
>>> -2147483648 div 2147483647 == -2
>>>
>>> and then
>>>
>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>
>>> The value x DIV y is the floor of
>>> the quotient of x and y; that is, the maximum integer
>>> not exceeding the real number z such that z * y = x.
>>> For integers x and y, the value of x MOD y is
>>> defined to be x - y * (x DIV y).
>>>
>>>
>>> This means that for positive y, the value of x MOD y
>>> lies in the interval [0 .. y-1], regardless of
>>> the sign of x. For negative y, the value of
>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>> of the sign of x.
>>
>> And this is consistent with MOD producing a canonical representative of
>> an equivalence class modulo y. It's what's wanted for a lot of
>> algorithms. What it returns for negative y isn't as important, but
>> it is important to have positive MODuli for positive y no matter what
>> the sign of x is.
>>
>> But it's not what most two's-complement processors produce naturally.
>> Having a MODulo operation that is mathematically well-behaved takes
>> extra effort on these machines.
>>
>> And it's also important to have a remainder that corresponds to the
>> division operator. On two's complement machines you have to either
>> * use extra instructions to correct the result of the divide
>> instruction to correspond to the mathematically desirable MOD
>> operator, or
>> * Have a separate remainder operation that does correspond to
>> division.
>>
>> On one's complement machines MOD will have the same effect as remainder.
>> On two's complement, different.
>>
>> -- hendrik
>> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 20 03:59:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:59:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>


That paper also suggests a more efficient algorithm we should probably adopt:
 
 
/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}

 
long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}
 
 
Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)

 
We'd probably want to be sure the / followed by % got optimized into just one divide though.
 
 
or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.
 
 
Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Date: Wed, 20 Jan 2010 02:45:43 +0000
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>> There is a positive zero and a negative zero, and which one you get
>
>
> Rodney you reminded me of something I forgot to ask:
>
>
> Is 0 div -1 = 0 or -1?
>
>
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>
>
> My current code I believe returns 0 for 0 div anything.
> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>
>
> The previous code probably also but I'll have to double check.
> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>
>
> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>
>
> Nice if anyone can reproduce the problem with K&R + long long as well.
> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>
>
> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>
>
> In particular, LONG_MIN div or mod -1 can trap.
>
>
> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>
>
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>
>
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>>
>>
>>
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>>
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>>
>>>
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>>
>>> One's complement machines are all but extinct these days.
>>
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>>
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>>
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>>
>>
>>>
>>>> However, Modula-3 specifies div as rounding down, so
>>>>
>>>> -2147483648 div 2147483647 == -2
>>>>
>>>> and then
>>>>
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>>
>>>>
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>>
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>>
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>>
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>>
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>>
>>> -- hendrik
>>> 		 	   		  

From hosking at cs.purdue.edu  Wed Jan 20 11:07:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:07:45 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>

These are all overflow examples correct?  In which case the meaning is undefined?

But certainly, 0 DIV -1 should be 0.

I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy.  In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations?  I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.

On 19 Jan 2010, at 21:45, Jay K wrote:

> 
>> There is a positive zero and a negative zero, and which one you get 
> 
> 
> Rodney you reminded me of something I forgot to ask: 
> 
> 
> Is 0 div -1 = 0 or -1?
> 
> 
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
> 
> 
> My current code I believe returns 0 for 0 div anything.
>  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> 
> 
> The previous code probably also but I'll have to double check.
>  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> 
> 
>  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> 
> 
>  Nice if anyone can reproduce the problem with K&R + long long as well.
>  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> 
> 
>  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> 
> 
>  In particular, LONG_MIN div or mod -1 can trap.
> 
> 
>  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> 
> 
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>> 
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>> 
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>> 
>>> 
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>> 
>>> One's complement machines are all but extinct these days.
>> 
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>> 
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>> 
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>> 
>> 
>>> 
>>>> However, Modula-3 specifies div as rounding down, so
>>>> 
>>>> -2147483648 div 2147483647 == -2
>>>> 
>>>> and then
>>>> 
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>> 
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>> 
>>>> 
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>> 
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>> 
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>> 
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>> 
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>> 
>>> -- hendrik
>>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 20 11:09:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:09:33 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>

C specifies truncated division.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 19 Jan 2010, at 21:59, Jay K wrote:

> 
> That paper also suggests a more efficient algorithm we should probably adopt:
> 
> 
> /* Floored division */
> long divF( long D, long d )
> {
> long q = D/d;
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
> return q;
> }
> 
> 
> long modF( long D, long d )
> {
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
> return r;
> }
> 
> 
> Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
> or (r < 0) ^ (d < 0)
> 
> 
> We'd probably want to be sure the / followed by % got optimized into just one divide though.
> 
> 
> or maybe what I have is fine.
> As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
> I am assuming C never "rounds", but either truncates or "floors".
> e.g. 1/2 in the face of rounding is 1.
> 
> 
> Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
>> Date: Wed, 20 Jan 2010 02:45:43 +0000
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>>> There is a positive zero and a negative zero, and which one you get
>> 
>> 
>> Rodney you reminded me of something I forgot to ask:
>> 
>> 
>> Is 0 div -1 = 0 or -1?
>> 
>> 
>> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
>> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>> 
>> 
>> My current code I believe returns 0 for 0 div anything.
>> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>> 
>> 
>> The previous code probably also but I'll have to double check.
>> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>> 
>> 
>> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>> 
>> 
>> Nice if anyone can reproduce the problem with K&R + long long as well.
>> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>> 
>> 
>> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>> 
>> 
>> In particular, LONG_MIN div or mod -1 can trap.
>> 
>> 
>> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>> 
>> 
>> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] integer division/mod questions?
>>> 
>>> 
>>> 
>>> hendrik at topoi.pooq.com wrote:
>>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>>> -2147483648 div 2147483647 ?
>>>>> -2147483648 mod 2147483647 ?
>>>>> 
>>>>> quotient = -1, remainer = -1 seems reasonable.
>>>>> 2147483647 * -1 + -1 == -2147483648
>>>>> 
>>>> 
>>>> There are two kinds of binary integer arithmetic -- two's complement
>>>> and one's complement. In my experience, two's complement machines tend
>>>> to have the remainder being the same sign as the dividend; one's
>>>> complement machines semm to have a remainder the same sign as the
>>>> divisor.
>>>> 
>>>> One's complement machines are all but extinct these days.
>>> 
>>> Tony, you were concerned about showing your age, but 20 years is but an
>>> evening past. I remember programming ones-complement arithmetic
>>> in assembly language, definitely more decades ago than two.
>>> And that was not my first job.
>>> 
>>> There is a positive zero and a negative zero, and which one you get
>>> can depend on the operation and operand values that produced the
>>> result, so you have to check for both of them, often with two
>>> separate conditional branches.
>>> 
>>> Anyone remember nines- or tens-complement arithmetic on decimal
>>> machines? Electromechanical accounting machines?
>>> 
>>> 
>>>> 
>>>>> However, Modula-3 specifies div as rounding down, so
>>>>> 
>>>>> -2147483648 div 2147483647 == -2
>>>>> 
>>>>> and then
>>>>> 
>>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>> 
>>>>> The value x DIV y is the floor of
>>>>> the quotient of x and y; that is, the maximum integer
>>>>> not exceeding the real number z such that z * y = x.
>>>>> For integers x and y, the value of x MOD y is
>>>>> defined to be x - y * (x DIV y).
>>>>> 
>>>>> 
>>>>> This means that for positive y, the value of x MOD y
>>>>> lies in the interval [0 .. y-1], regardless of
>>>>> the sign of x. For negative y, the value of
>>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>>> of the sign of x.
>>>> 
>>>> And this is consistent with MOD producing a canonical representative of
>>>> an equivalence class modulo y. It's what's wanted for a lot of
>>>> algorithms. What it returns for negative y isn't as important, but
>>>> it is important to have positive MODuli for positive y no matter what
>>>> the sign of x is.
>>>> 
>>>> But it's not what most two's-complement processors produce naturally.
>>>> Having a MODulo operation that is mathematically well-behaved takes
>>>> extra effort on these machines.
>>>> 
>>>> And it's also important to have a remainder that corresponds to the
>>>> division operator. On two's complement machines you have to either
>>>> * use extra instructions to correct the result of the divide
>>>> instruction to correspond to the mathematically desirable MOD
>>>> operator, or
>>>> * Have a separate remainder operation that does correspond to
>>>> division.
>>>> 
>>>> On one's complement machines MOD will have the same effect as remainder.
>>>> On two's complement, different.
>>>> 
>>>> -- hendrik
>>>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/8fa44102/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:20:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:20:03 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
Message-ID: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>


Ok with changing LONGINT to be __int128, *but*

you really should not change it with a compiler flag.

For any given platform, "basics" like this should not change meaning.

It makes it such that you can't link code safely.

 

 

Basically, "platform" or "target" should map to one "ABI".

 

 

I really kind of like what I proposed earlier.

  Let the user define things.

  TYPE INT64 = BITS 64 FOR INTEGER;

  TYPE INT128 = BITS 128 FOR INTEGER;

 

TYPE INT256 = BITS 256 FOR INTEGER;

  (* either an error, or the compiler generates calls to multi-precision library *)

 

 

This is btw why the user thread stuff should be either 1) a runtime alterable decision

or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).

So that there aren't multiple ABIs and you can link together any code for

a given platform.

With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.

That forces recompilation of everything affected.

 

 

 - Jay

 


Subject: Re: [M3devel] __int128 coming to gcc
From: darko at darko.org
Date: Wed, 20 Jan 2010 14:23:32 +1100
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.




On 19/01/2010, at 1:03 AM, Tony Hosking wrote:



On 18 Jan 2010, at 08:05, Jay K wrote:


gcc 4.6 apparently will have __int128.
How long until we have LONGLONGINT or INT128?
Presumably we should have LONGLONGINT or INT128 to expose it?
:)



Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as


BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]



 Or, again, I should look at the arithemetic library...
 
 
 - Jay
 
 
Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091

... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
255919 by: Kai Tietz <ktietz70@>

...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
....

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/c918cc3b/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:21:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:21:00 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>,
	<D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
Message-ID: <COL101-W557F59387EF941814B75F4E6640@phx.gbl>


Only lately with C99.

Prior to that it was unspecified.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 05:09:33 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

C specifies truncated division.




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 19 Jan 2010, at 21:59, Jay K wrote:


That paper also suggests a more efficient algorithm we should probably adopt:


/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}


long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}


Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)


We'd probably want to be sure the / followed by % got optimized into just one divide though.


or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.


Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)


- Jay


----------------------------------------

From: jay.krell at cornell.edu

To: rodney_bates at lcwb.coop; m3devel at elegosoft.com

Date: Wed, 20 Jan 2010 02:45:43 +0000

Subject: Re: [M3devel] integer division/mod questions?






There is a positive zero and a negative zero, and which one you get





Rodney you reminded me of something I forgot to ask:





Is 0 div -1 = 0 or -1?





In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.

If 0> -0, then 0 div -1 should equal -1 instead of 0.





My current code I believe returns 0 for 0 div anything.

And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.





The previous code probably also but I'll have to double check.

The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.





Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.





Nice if anyone can reproduce the problem with K&R + long long as well.

I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.





The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.





In particular, LONG_MIN div or mod -1 can trap.





div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.





(anywhere I say "LONG_MIN", INT64_MIN has similar problem)







- Jay





----------------------------------------


Date: Tue, 19 Jan 2010 18:39:22 -0600


From: rodney_bates at lcwb.coop


To: m3devel at elegosoft.com


Subject: Re: [M3devel] integer division/mod questions?











hendrik at topoi.pooq.com wrote:



On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:




-2147483648 div 2147483647 ?




-2147483648 mod 2147483647 ?









quotient = -1, remainer = -1 seems reasonable.




2147483647 * -1 + -1 == -2147483648












There are two kinds of binary integer arithmetic -- two's complement



and one's complement. In my experience, two's complement machines tend



to have the remainder being the same sign as the dividend; one's



complement machines semm to have a remainder the same sign as the



divisor.







One's complement machines are all but extinct these days.





Tony, you were concerned about showing your age, but 20 years is but an


evening past. I remember programming ones-complement arithmetic


in assembly language, definitely more decades ago than two.


And that was not my first job.





There is a positive zero and a negative zero, and which one you get


can depend on the operation and operand values that produced the


result, so you have to check for both of them, often with two


separate conditional branches.





Anyone remember nines- or tens-complement arithmetic on decimal


machines? Electromechanical accounting machines?














However, Modula-3 specifies div as rounding down, so









-2147483648 div 2147483647 == -2









and then









http://www.modula3.com/cm3/doc/reference/arithmetic.html









The value x DIV y is the floor of




the quotient of x and y; that is, the maximum integer




not exceeding the real number z such that z * y = x.




For integers x and y, the value of x MOD y is




defined to be x - y * (x DIV y).














This means that for positive y, the value of x MOD y




lies in the interval [0 .. y-1], regardless of




the sign of x. For negative y, the value of




x MOD y lies in the interval [y+1 .. 0], regardless




of the sign of x.







And this is consistent with MOD producing a canonical representative of



an equivalence class modulo y. It's what's wanted for a lot of



algorithms. What it returns for negative y isn't as important, but



it is important to have positive MODuli for positive y no matter what



the sign of x is.







But it's not what most two's-complement processors produce naturally.



Having a MODulo operation that is mathematically well-behaved takes



extra effort on these machines.







And it's also important to have a remainder that corresponds to the



division operator. On two's complement machines you have to either



* use extra instructions to correct the result of the divide



instruction to correspond to the mathematically desirable MOD



operator, or



* Have a separate remainder operation that does correspond to



division.







On one's complement machines MOD will have the same effect as remainder.



On two's complement, different.







-- hendrik



    

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5060991a/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:27:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:27:17 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
Message-ID: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>


No, not overflow examples.

 

 

LONG_MIN divided by any negative number was a negative number.

  But I believe it should be positive.

  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.

    The result is representable.

  LONG_MIN mod negative numbers also had the wrong sign.

 

 

You don't really have to view a diff.

I left the old functions m3_mod, m3_div, present, renamed

to m3_mod_old, m3_div_old.

 

 

So you can see both versions.

The new versions don't look particularly like the old ones.

The "proof" to me is the behavior per testing.

There is test code in there as well, under #if 0.

I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.

Mostly on Darwin/x86 though.

Both with gcc (4.0.1) and gcc-4.2.

 

 

Old:

 

static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}


 

long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}


 

"new" or "current":

 

long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}


 

long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}


 

In the case of div, I believe my code is clear and I understand it.

But perhaps could be more efficient.

 

 

In the case of mod, I don't know what is going on actually.

I just made it look something like old and tested it.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5cd68a5d/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:31:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:31:18 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>, ,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>,
	<COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
Message-ID: <COL101-W22FDCE853B21D87623183FE6640@phx.gbl>


Actually I think the new mod/div functions are still a little

risky for negative div or mod negative.

They'd more reliable/predictable/portable if if they used unsigned

numbers.

 

 

The reason I started looking at this stuff is because I was

reading about gcc assuming signed overflow won't occur

and then making optimizations with that assumption.

You can ask it to warn when it does so.
I thought this might break the new but unused m3_add and

such. The warning triggered for the existing div (but not mod) functions.

So I set about rewriting them to use unsigned math, which

is the recommendation here -- because its overflow is

well defined by the C standard -- and then comparing

mine with the previous/current code..and noticed wrong behavior

in the previous/current.

 

 - Jay



 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 11:27:17 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?



No, not overflow examples.
 
 
LONG_MIN divided by any negative number was a negative number.
  But I believe it should be positive.
  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.
    The result is representable.
  LONG_MIN mod negative numbers also had the wrong sign.
 
 
You don't really have to view a diff.
I left the old functions m3_mod, m3_div, present, renamed
to m3_mod_old, m3_div_old.
 
 
So you can see both versions.
The new versions don't look particularly like the old ones.
The "proof" to me is the behavior per testing.
There is test code in there as well, under #if 0.
I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.
Mostly on Darwin/x86 though.
Both with gcc (4.0.1) and gcc-4.2.
 
 
Old:
 
static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}

 
long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}

 
"new" or "current":
 
long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}

 
long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}

 
In the case of div, I believe my code is clear and I understand it.
But perhaps could be more efficient.
 
 
In the case of mod, I don't know what is going on actually.
I just made it look something like old and tested it.
 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5a443bbb/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:40:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:40:03 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
Message-ID: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>


So..I have m3back using Target.Int a bunch.

And converting back and forth some between Target.Int and

INTEGER and doing match with Target.Int.

And various operations can fail.

 

 

And my current diff results in:

 

 

  new source -> compiling Lex.m3  
  "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed  
  "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed  
  2 errors encountered  
  new source -> compiling Scan.i3  

 

 

  which is nice to see, it means my code is actually running.  

 

 

  So I look at the code in question:  

 

 

  PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN): Word.T  
  VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN 
...

    IF signed AND
       ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
        (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
      RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
....

 

 

-FIRST(INTEGER).

 

 

What is that supposed to do?

 

 

I mean, I kind of know, I'm slightly playing stupid, partly not.

Does the compiler know what is an INTEGER vs. what is a "Word"?

Or it is just obligated to assume everything is a Word?

 To do the negation at compile time and ignore the overflow?

 

 

Does the language need work here?

I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

 

 

 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/70e3767e/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 12:55:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:55:14 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
Message-ID: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>


I propose we add WarningHandler, set_warning_handler.

The signatures are either identical to the existing ErrorHandler, set_error_handler.

Or possibly there is a warning "level".

For now I'm implementing it such that the warning level

is hardcoded as 2.

 

 

This is so I can report but ignore the overflows when I use TInt in m3back.

 

 

 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/61d4067c/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 20 16:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 15:05:23 +0000
Subject: [M3devel] m3back using Target.Int in place of INTEGER a lot now
In-Reply-To: <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
Message-ID: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>


This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.

I did look through pretty much every single line in search of the one bug I saw working on it.

It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.

Which broke INC, it was adding 0 instead 1.

You could see the bug in RTIO.PutString where it just kept outputing the first character.

So I use TInt.Multiply instead.

 

 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3



diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/2a2f079c/attachment-0001.html>

From hendrik at topoi.pooq.com  Wed Jan 20 17:23:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:23:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <20100120162315.GA18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 02:59:43AM +0000, Jay K wrote:
>  
> Integer division probably not a big concern anyway, esp. with any 
> negative numbers. The main place I ever see division/mod used is hash 
> tables, and the numbers are always positive

And that's where it's important that the remainder has the same sign as 
the divisor.

> (I rarely see negative numbers used anywhere in "systems" programming 
> actually -- file sizes, array indices, array sizes..all positive; 
> "math" needs floating point often...)

You can get negative numbers in the subscripting calculations for an 
array whose subscripts are in the range like 10000..10345.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:26:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:26:20 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <20100120162620.GB18214@topoi.pooq.com>

On Tue, Jan 19, 2010 at 06:39:22PM -0600, Rodney M. Bates wrote:
> 
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past.  I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
> 
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
> 
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines?

Conputers, no.  The decimal computer I used has signed-magnitude 
representation.  And it did addition by looking pairs of digits up in an 
array in RAM.  YOu could get interesting effects by replacing the 
addition tables.

>  Electromechanical accounting machines?

Yes.  I remember using these when studying statistics.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:30:39 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:30:39 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <20100120163039.GC18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> 
> you really should not change it with a compiler flag.
> 
> For any given platform, "basics" like this should not change meaning.
> 
> It makes it such that you can't link code safely.
> 
>  
> 
>  
> 
> Basically, "platform" or "target" should map to one "ABI".
> 
>  
> 
>  
> 
> I really kind of like what I proposed earlier.
> 
>   Let the user define things.
>
>   TYPE INT64 = BITS 64 FOR INTEGER;
> 
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> 
> TYPE INT256 = BITS 256 FOR INTEGER;
> 
> 
>   (* either an error, or the compiler generates calls to multi-precision library *)

Well, with INTEGER being defined as the type for efficient integer 
arithmetic, you's have to say

  TYPE INT64 = BITS 64 FOR LONGINT;

  TYPE INT128 = BITS 128 FOR LONGINT;

 

TYPE INT256 = BITS 256 FOR LONGINT;

and on many current machines, file offset should then be defined as 
BITS64 instead of LONGINT.

-- hendrik

> This is btw why the user thread stuff should be either 1) a runtime alterable decision


From rcolebur at SCIRES.COM  Wed Jan 20 21:02:11 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 20 Jan 2010 15:02:11 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com> <4B5650BA.6030601@lcwb.coop>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6ED53@ATLEX02-SRV.SCIRES.LOCAL>

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Tuesday, January 19, 2010 7:39 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?

[Randy Coleburn] 
[Randy Coleburn] My first "programming" experience dates back to the old IBM tabulating machine where you had to plug up the wires to form the tabulating logic.  Also, the old keypunch machines, card sorters, etc.  My first real computer had core memory and we used the old teletype machines with canary yellow paper and paper tape.  But, given where we are today, I don't think any of us would remember these as "the good ol' days" of computing, though I do have some fond memories.

Regards,
Randy


From hosking at cs.purdue.edu  Thu Jan 21 00:50:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:50:08 -0500
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
Message-ID: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>

I don't understand why you need this.
Why would you have overflows in m3back?
Are you constant folding or something?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:55, Jay K wrote:

> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>  
>  
> This is so I can report but ignore the overflows when I use TInt in m3back.
>  
>  
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/56075883/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 00:59:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:59:30 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
Message-ID: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 10:05, Jay K wrote:

> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/b7df3b34/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 01:02:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:02:33 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>

But INTEGER is the natural integer size.  Not the maximum (perhaps less efficient) integer size supported by the compiler.
What's wrong with:

BITS 64 FOR LONGINT

?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:20, Jay K wrote:

> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/7f1a3a17/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 01:03:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:03:01 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100120163039.GC18214@topoi.pooq.com>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<20100120163039.GC18214@topoi.pooq.com>
Message-ID: <2EF1DA6A-281F-49EA-8612-AD30CE6D7EBB@cs.purdue.edu>

Yes, exactly.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 11:30, hendrik at topoi.pooq.com wrote:

> On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> 
>> you really should not change it with a compiler flag.
>> 
>> For any given platform, "basics" like this should not change meaning.
>> 
>> It makes it such that you can't link code safely.
>> 
>> 
>> 
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> 
>> 
>> 
>> I really kind of like what I proposed earlier.
>> 
>>  Let the user define things.
>> 
>>  TYPE INT64 = BITS 64 FOR INTEGER;
>> 
>>  TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> 
>> 
>>  (* either an error, or the compiler generates calls to multi-precision library *)
> 
> Well, with INTEGER being defined as the type for efficient integer 
> arithmetic, you's have to say
> 
>  TYPE INT64 = BITS 64 FOR LONGINT;
> 
>  TYPE INT128 = BITS 128 FOR LONGINT;
> 
> 
> 
> TYPE INT256 = BITS 256 FOR LONGINT;
> 
> and on many current machines, file offset should then be defined as 
> BITS64 instead of LONGINT.
> 
> -- hendrik
> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/db678408/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 01:35:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:35:17 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
Message-ID: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>

On 20 Jan 2010, at 19:29, Darko wrote:

> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.

M3 defines all arithmetic as operating on the base type.  It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.

> You're using the syntax for packed types in your example, but I think they'd have to be subranges.

Sorry, yes. [Jet-lag]

> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.

Agreed!

> 
> 
> 
> On 20/01/2010, at 10:20 PM, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/09ea7216/attachment-0001.html>

From Highjinks at gmx.com  Thu Jan 21 01:50:20 2010
From: Highjinks at gmx.com (Chris)
Date: Thu, 21 Jan 2010 01:50:20 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
Message-ID: <20100120205327.e8547d50.Highjinks@gmx.com>

It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.

Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
Trestle is easy to write for, but it really is butt ugly.

Is anyone else looking at this area of the system?


-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Thu Jan 21 01:58:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:58:44 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <D04D87A0-B24A-4EE3-95AE-90D4F3A78938@cs.purdue.edu>

That would be a great idea.  Given that we are linking with X11R6 anyway...  :-)

On 20 Jan 2010, at 19:50, Chris wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
> 
> Is anyone else looking at this area of the system?
> 
> 
> -- 
> Chris <Highjinks at gmx.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/e1c1b144/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 02:00:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 20:00:39 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
Message-ID: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>

Jay, I don't know what you are talking about there being a bug in TWord.Multiply.

This little program prints out 2, as would be expected:

MODULE Main;
IMPORT RTIO, TInt, TWord, Target;

VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.


On 20 Jan 2010, at 18:59, Tony Hosking wrote:

> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 20 Jan 2010, at 10:05, Jay K wrote:
> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>>  
>>  - Jay
>>  
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>>  
>> > Date: Wed, 20 Jan 2010 16:01:32 +0000
>> > To: m3commit at elegosoft.com
>> > From: jkrell at elego.de
>> > Subject: [M3commit] CVS Update: cm3
>> > 
>> > CVSROOT: /usr/cvs
>> > Changes by: jkrell at birch. 10/01/20 16:01:32
>> > 
>> > Modified files:
>> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
>> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
>> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
>> > 
>> > Log message:
>> > convert much of m3back to use Target.Int instead of INTEGER
>> > This should at least allow it to propagate constant LONGINTs
>> > as well as perhaps otherwise help with implementing LONGINT,
>> > since the virtual stack is now of Target.Int instead of INTEGER
>> > 
>> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>> > 
>> > Also note that there's still a lot of "INTEGER" used.
>> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/2107472c/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 03:49:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:49:15 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
Message-ID: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>


That would be fine too.
Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
 
  - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:02:33 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; darko at darko.org
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
> What's wrong with:
>
> BITS 64 FOR LONGINT
>
> ?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:20, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:50:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:50:05 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>,
	<87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
Message-ID: <COL101-W1693D675BA116E2C556EF9E6630@phx.gbl>


> Are you constant folding or something?

Exactly.
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 18:50:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] proposed addition m3cg_ops: set_warning_handler
>
>
>
> I don't understand why you need this.
> Why would you have overflows in m3back?
> Are you constant folding or something?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:55, Jay K wrote:
>
> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>
>
> This is so I can report but ignore the overflows when I use TInt in m3back.
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:52:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:52:13 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>


I'll look into it again.
There's definitely a problem somewhere.
 Maybe in my change. Maybe.
 
 
Using TInt.Multiply vs. TWord.Multiply made the difference
between INC() incrementing by zero or the correct amount.
I had some number, I multiplied it by a variable
that also happened to be 1, and I got zero.
This was the only problem I ran into in changing
from INTEGER to Target.Int.
 
 
 - Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>
>
>
>
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>
> This little program prints out 2, as would be expected:
>
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
>
> VAR i := TInt.Two;
> j: Target.Int;
> buf: ARRAY[0..10] OF CHAR;
> BEGIN
> TWord.Multiply (i, TInt.One, j);
> FOR k := 0 TO TInt.ToChars (i, buf) DO
> RTIO.PutChar(buf[k]);
> END;
> RTIO.PutChar('\n');
> RTIO.Flush();
> END Main.
>
>
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 10:05, Jay K wrote:
>
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>
> - Jay
>
> ________________________________
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
>
> diff attached
>
>
>
>
>
>
>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>> To: m3commit at elegosoft.com
>> From: jkrell at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>
>> Modified files:
>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>
>> Log message:
>> convert much of m3back to use Target.Int instead of INTEGER
>> This should at least allow it to propagate constant LONGINTs
>> as well as perhaps otherwise help with implementing LONGINT,
>> since the virtual stack is now of Target.Int instead of INTEGER
>>
>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>
>> Also note that there's still a lot of "INTEGER" used.
>>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:54:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:54:10 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
Message-ID: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>


> I think the idea that "basics" don't change
> meaning doesn't wash because you can't
> make assumptions about what hardware you're
> running on and therefore might be condemning
> the language to inefficiency on certain hardware.
>
> Agreed!

 
The "basics" *for a given target*.
LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
Some other future platform can use 56 bits or 128 bits or whatever.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:35:17 -0500
> To: darko at darko.org
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> On 20 Jan 2010, at 19:29, Darko wrote:
>
> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>
> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>
> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>
> Sorry, yes. [Jet-lag]
>
> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>
> Agreed!
>
>
>
>
> On 20/01/2010, at 10:20 PM, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 04:57:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 03:57:45 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>,
	<5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
Message-ID: <COL101-W404F04F00E1BF980DD7075E6630@phx.gbl>


But you need certain things to not change *per platform* if you expect to be able to link code together and not crash.
Different platforms of course can use different sizes and such.
 
 
It should not be possible to compile one module with one size INTEGER and nother with another size, if they can be linked together.
 
 
Various systems do allow that sort of thing and it is imho a bad idea.
It leads to "ABI bifurcation".
Like, let's say you want to provide a library for use by "anyone".
You end up having to compile it multiple times with various options, so that no matter what your user uses, there is a variant that matches.
Sometimes this stuff gets checked at link time, sometimes not.
 
 
Again this is why the way user threads is an "option" isn't great.
You have to recompile everything if you switch the option.
(I believe there are incrementality bugs here as well; basically many sorts of m3makefile edits are not handled correctly by cm3; for example moving a source file from one package to another..)
 
 
Having [0L .. Long.Shift(1L, 129)] work and use a 128bit LONGINT is a fine idea, agreed. "LONGINT" can indicate "possibly less efficient.
 
 
However, this is again a dangerous change *on preexisting platforms*, because it leads to LAST(LONGINT) changing.
 
 
 - Jay


----------------------------------------
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Thu, 21 Jan 2010 14:34:26 +1100
> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I think you want to get away from concrete representations on particular platforms. All you need to know is that INTEGER is a good, efficient size for the platform, and LONGINT is possibly bigger size but still reasonably efficient. That way the code will compile on any platform and you don't care what size INTEGER or LONGINT is. If this were a Star Wars movie Obiwan would be saying "Use Abstraction, Jay".
>
>
> On 21/01/2010, at 1:54 PM, Jay K wrote:
>
>
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>>
>> Agreed!
>
>
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
>
>
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>>
>>
>>
>> On 20 Jan 2010, at 19:29, Darko wrote:
>>
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>>
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>>
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>>
>> Sorry, yes. [Jet-lag]
>>
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>>
>> Agreed!
>>
>>
>>
>>
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>>
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>>
>>
>> Basically, "platform" or "target" should map to one "ABI".
>>
>>
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>>
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>>
>>
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>>
>>
>> - Jay
>>
>>
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>>
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>>
>>
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>>
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>>
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>>
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>>
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>>
>> Or, again, I should look at the arithemetic library...
>>
>>
>> - Jay
>>
>>
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>>
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>>
>> ...
>>
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>>
>>
>>
>> Hello,
>>
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>>
>> ChangeLog gcc/
>> ....
>>
>>
>>
>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 08:02:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:02:41 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>


Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.

 

 

MODULE Main;
IMPORT RTIO, Target, TInt, TWord;

VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.


 

prints 0.

 

The code in m3back:

 

 

PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...

        (* Beware TWord.Multiply: x * 1 = 0 *)

        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;


 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/c4c36c89/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 08:14:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:14:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <COL101-W2749C76BB19D4AA0997E77E6630@phx.gbl>


TInt.Multiply is reasonable anyway, since the code wasn't using Word.Multiply but just INTEGER *.

 

 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 07:02:41 +0000
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now



Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply? 
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/a4fbddf8/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 09:36:24 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:36:24 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
Message-ID: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>

Subranges have a memory size that depends on the size of the subrange.  All arithmetic is performed using the precision of the base type however.

These things are all documented in the language spec.

On 20 Jan 2010, at 21:49, Jay K wrote:

> 
> That would be fine too.
> Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
> 
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:02:33 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; darko at darko.org
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
>> What's wrong with:
>> 
>> BITS 64 FOR LONGINT
>> 
>> ?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 06:20, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Thu Jan 21 09:37:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:37:00 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
Message-ID: <B4981016-C75D-468E-9506-87C48506C00F@cs.purdue.edu>

Agreed, yes, the sizes are in the target definition.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:54, Jay K wrote:

> 
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>> 
>> Agreed!
> 
> 
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> On 20 Jan 2010, at 19:29, Darko wrote:
>> 
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>> 
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>> 
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>> 
>> Sorry, yes. [Jet-lag]
>> 
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>> 
>> Agreed!
>> 
>> 
>> 
>> 
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/8ee49afc/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 09:38:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:38:45 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W236A596B7446D4793B7590E6630@phx.gbl>
Message-ID: <1DFF961A-09C7-4BAF-8593-D8128577786D@cs.purdue.edu>

INC is defined on INTEGER values, not Word.T.

I think your problem is somewhere else.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:52, Jay K wrote:

> 
> I'll look into it again.
> There's definitely a problem somewhere.
> Maybe in my change. Maybe.
> 
> 
> Using TInt.Multiply vs. TWord.Multiply made the difference
> between INC() incrementing by zero or the correct amount.
> I had some number, I multiplied it by a variable
> that also happened to be 1, and I got zero.
> This was the only problem I ran into in changing
> from INTEGER to Target.Int.
> 
> 
> - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 20:00:39 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>> 
>> 
>> 
>> 
>> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>> 
>> This little program prints out 2, as would be expected:
>> 
>> MODULE Main;
>> IMPORT RTIO, TInt, TWord, Target;
>> 
>> VAR i := TInt.Two;
>> j: Target.Int;
>> buf: ARRAY[0..10] OF CHAR;
>> BEGIN
>> TWord.Multiply (i, TInt.One, j);
>> FOR k := 0 TO TInt.ToChars (i, buf) DO
>> RTIO.PutChar(buf[k]);
>> END;
>> RTIO.PutChar('\n');
>> RTIO.Flush();
>> END Main.
>> 
>> 
>> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>> 
>> Where's the bug in TWord.Multiply?
>> If there were a bug we would have seen it by now surely?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 10:05, Jay K wrote:
>> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>> 
>> - Jay
>> 
>> ________________________________
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>> 
>>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>>> To: m3commit at elegosoft.com
>>> From: jkrell at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>> 
>>> Log message:
>>> convert much of m3back to use Target.Int instead of INTEGER
>>> This should at least allow it to propagate constant LONGINTs
>>> as well as perhaps otherwise help with implementing LONGINT,
>>> since the virtual stack is now of Target.Int instead of INTEGER
>>> 
>>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>> 
>>> Also note that there's still a lot of "INTEGER" used.
>>> 
>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/a8542917/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 09:40:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:40:36 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>

You should not assume that aliasing works for any of these operations.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 02:02, Jay K wrote:

> Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
>  
>  
> MODULE Main;
> IMPORT RTIO, Target, TInt, TWord;
> VAR a,b:Target.Int;
> BEGIN
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
> TWord.Multiply(a, b, a);
> RTIO.PutText(TInt.ToText(a));
> RTIO.Flush();
> END Main.
> 
>  
> prints 0.
>  
> The code in m3back:
>  
>  
> PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
> ...
>         (* Beware TWord.Multiply: x * 1 = 0 *)
>         IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
>           t.Err("doindex_address: multiply overflowed");
>         END;
> 
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
> 
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
> 
> This little program prints out 2, as would be expected:
> 
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
> 
> VAR i := TInt.Two;
>     j: Target.Int;
>     buf: ARRAY[0..10] OF CHAR;
> BEGIN
>   TWord.Multiply (i, TInt.One, j);
>   FOR k := 0 TO TInt.ToChars (i, buf) DO
>     RTIO.PutChar(buf[k]);
>   END;
>   RTIO.PutChar('\n');
>   RTIO.Flush();
> END Main.
> 
> 
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
> 
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> 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 20 Jan 2010, at 10:05, Jay K wrote:
> 
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/90bb8142/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 09:42:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 08:42:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>,
	<8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
Message-ID: <COL101-W366A4B875AA2D047EF4DE9E6630@phx.gbl>


I changed it to no longer:

 

        IF NOT TInt.Multiply(stop0.imm, tsize, tint) THEN
          t.Err("doindex_address: multiply overflowed");
        END;
        stop0.imm := tint;


 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 03:40:36 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now


You should not assume that aliasing works for any of these operations.



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 21 Jan 2010, at 02:02, Jay K wrote:

Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/f704db55/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 10:11:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 09:11:24 +0000
Subject: [M3devel] atomics addressing modes, it looks like none needed
Message-ID: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>


I tried a few differnt switches.

They always seem to get the actual address into a register.


C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod


long __cdecl _InterlockedExchange(long volatile*, long);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedIncrement(long volatile*);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedExchangeAdd(long volatile*, long);
#pragma intrinsic(_InterlockedExchangeAdd)

 

 

long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
#pragma intrinsic(_InterlockedCompareExchange)

 

 

long F1(volatile long* a)
{
return _InterlockedIncrement(&a[10]);
}

 


typedef struct S1 { int a; long b; } S1;

long F2(volatile S1* a)
{
return _InterlockedExchangeAdd(&a->b, 123);
}

 


long F3(volatile S1* a)
{
return _InterlockedCompareExchange(&a->b, 1, 2);
}

 


long F4(volatile S1* a)
{
return _InterlockedExchange(&a->b, 1);
}


 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08


        TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
        .686P
        .XMM
        include listing.inc
        .model  flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC  _F1
; Function compile flags: /Ogtpy
; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F1     PROC

; 15   : return _InterlockedIncrement(&a[10]);

  00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
  00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
  00007 b8 01 00 00 00   mov     eax, 1
  0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
  00010 40               inc     eax

; 16   : }

  00011 c3               ret     0
_F1     ENDP
_TEXT   ENDS
PUBLIC  _F2
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F2     PROC

; 23   : return _InterlockedExchangeAdd(&a->b, 123);

  00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
  00029 83 c1 04         add     ecx, 4
  0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax

; 24   : }

  00030 c3               ret     0
_F2     ENDP
_TEXT   ENDS
PUBLIC  _F3
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F3     PROC

; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);

  00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
  00044 b9 01 00 00 00   mov     ecx, 1
  00049 83 c2 04         add     edx, 4
  0004c b8 02 00 00 00   mov     eax, 2
  00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx

; 30   : }

  00055 c3               ret     0
_F3     ENDP
_TEXT   ENDS
PUBLIC  _F4
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F4     PROC

; 35   : return _InterlockedExchange(&a->b, 1);

  00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00064 b8 01 00 00 00   mov     eax, 1
  00069 83 c1 04         add     ecx, 4
  0006c 87 01            xchg    DWORD PTR [ecx], eax

; 36   : }

  0006e c3               ret     0
_F4     ENDP
_TEXT   ENDS
END

C:\dev2\cm3.2\m3-sys\m3back\src>



probably should try IA64 though.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/282ae614/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 14:29:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 13:29:12 +0000
Subject: [M3devel] fetch_and_op?
Message-ID: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>


(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)



Tony, are you sure you want to return the old value, not the new value?

That's not great on x86.

I believe for "or" and "and", you end up having to do a compare exchange loops.

 

 

For xor, add, sub, you can compute the old value, ok.

But if caller wanted the old value, he can do that himself also.

Caller can also write a compare_exchange loop.

 

 

Therefore, I think it should be:

 

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)


There is of course value in storing the value in mem and stack, since mem

can change right away.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/5268cabb/attachment-0001.html>

From dabenavidesd at yahoo.es  Thu Jan 21 14:57:31 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 13:57:31 +0000 (GMT)
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <512318.52973.qm@web23601.mail.ird.yahoo.com>

Hi all:
I think you could research some deep into gcc lists
http://gcc.gnu.org/ml/gcc/2006-12/msg00467.html 
>From what I read you are getting different results depending of optimization with overflowing

I hope this helps a bit.

El dom, 17/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] in favor of mixed operators..
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 04:38
> 
> 
> 
> 
>  
> http://python-history.blogspot.com/2009/03/problem-with-integer-division.html
> 
> 
> He argues that for a "high level" language, of
> course
> I should be able to add int to long, int to float, etc.
> And that int / int should not be int.
> At least Modula-3 spells them differently, / vs. MOD.
> 
> 
> Of course, "high level" vs. "systems"
> vs. "one size to fit all"...
> 
> 
> Anyway, I give up here.
> 
> 
>  - Jay
> 
> 
> 
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Thu Jan 21 15:21:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:21:22 -0500
Subject: [M3devel] atomics addressing modes, it looks like none needed
In-Reply-To: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
References: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
Message-ID: <1A39E99D-F8A7-4D8A-B1E6-AC9D4A53651E@cs.purdue.edu>

OK, so no indexed mode?  gcc may generate it differently.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 04:11, Jay K wrote:

> I tried a few differnt switches.
> They always seem to get the actual address into a register.
> 
> C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod
> 
> long __cdecl _InterlockedExchange(long volatile*, long);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedIncrement(long volatile*);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedExchangeAdd(long volatile*, long);
> #pragma intrinsic(_InterlockedExchangeAdd)
>  
>  
> long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
> #pragma intrinsic(_InterlockedCompareExchange)
>  
>  
> long F1(volatile long* a)
> {
> return _InterlockedIncrement(&a[10]);
> }
>  
> 
> typedef struct S1 { int a; long b; } S1;
> long F2(volatile S1* a)
> {
> return _InterlockedExchangeAdd(&a->b, 123);
> }
>  
> 
> long F3(volatile S1* a)
> {
> return _InterlockedCompareExchange(&a->b, 1, 2);
> }
>  
> 
> long F4(volatile S1* a)
> {
> return _InterlockedExchange(&a->b, 1);
> }
> 
>  
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
> t.c
> ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08
> 
>         TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
>         .686P
>         .XMM
>         include listing.inc
>         .model  flat
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
> PUBLIC  _F1
> ; Function compile flags: /Ogtpy
> ; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F1     PROC
> ; 15   : return _InterlockedIncrement(&a[10]);
>   00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
>   00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
>   00007 b8 01 00 00 00   mov     eax, 1
>   0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
>   00010 40               inc     eax
> ; 16   : }
>   00011 c3               ret     0
> _F1     ENDP
> _TEXT   ENDS
> PUBLIC  _F2
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F2     PROC
> ; 23   : return _InterlockedExchangeAdd(&a->b, 123);
>   00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
>   00029 83 c1 04         add     ecx, 4
>   0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
> ; 24   : }
>   00030 c3               ret     0
> _F2     ENDP
> _TEXT   ENDS
> PUBLIC  _F3
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F3     PROC
> ; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);
>   00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
>   00044 b9 01 00 00 00   mov     ecx, 1
>   00049 83 c2 04         add     edx, 4
>   0004c b8 02 00 00 00   mov     eax, 2
>   00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx
> ; 30   : }
>   00055 c3               ret     0
> _F3     ENDP
> _TEXT   ENDS
> PUBLIC  _F4
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F4     PROC
> ; 35   : return _InterlockedExchange(&a->b, 1);
>   00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00064 b8 01 00 00 00   mov     eax, 1
>   00069 83 c1 04         add     ecx, 4
>   0006c 87 01            xchg    DWORD PTR [ecx], eax
> ; 36   : }
>   0006e c3               ret     0
> _F4     ENDP
> _TEXT   ENDS
> END
> C:\dev2\cm3.2\m3-sys\m3back\src>
> 
> 
> probably should try IA64 though.
>  
>  
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/9a2587ee/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Jan 21 15:23:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:23:59 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
Message-ID: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 08:29, Jay K wrote:

> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/f0359ad5/attachment-0001.html>

From dabenavidesd at yahoo.es  Thu Jan 21 15:28:50 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 14:28:50 +0000 (GMT)
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs. head?
In-Reply-To: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>
Message-ID: <1444.87625.qm@web23608.mail.ird.yahoo.com>

Hi:
this problem was present in the code since some time ago, even before merge original cvsup sources in cm3 tree. You could see a how to repeat detailed here:
http://aivwiki.alma.cl/index.php/Installing_CVSup
This wiki entry has more than a year of existence.
I couldn't deep more because because some time ago I repeated the sequence and got the same result (first try works, and background doesn't). But not too long ago I repeated and got even worse the first attempt (non-background process didn't work) neither background so I just guessed something could be wrong on both cases with LINUXLIBC6 systems.

Please could you give me some pointers to build CM3 system with user threads on AMD64_LINUX or LINUXLIBC6 to see if this repeats 

Thanks in advance

--- El dom, 17/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release vs. head?
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 11:13
> On 17 Jan
> 2010, at 08:42, Jay K
> wrote:
> We can stick
> with the current release branch if that is indeed much
> easier.
> 
> 
> I thought there was some agreement we shouldn't release
> LONGINT as it was.
> 
> Indeed!
> I can undo the
> changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff
> or diff (again, cvs
> seems not to help).
> 
> Surely we can move forward on this.
> Many/most/all of
> the fixes went first into head, so there's
> "nothing" to merge back,
> but diff tells us better.
> 
> I agree.
> I'm still
> planning on setting up some more machines and can do
> FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them
> first...)
> 
> Let's not worry about additional
> targets. 
> Does anyone have
> the missing steps for the cvsup bug report, like the
> configuration file,
> can show the callstacks, try it with user threads..etc..?
> 
> Maybe cvsup should not be part of the
> release?
> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 -->
> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat
> selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what
> varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more
> or less
> > a nightmare. We cannot make incompatible extensions to
> the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT
> changes into the
> > next release would be to start anew. Meaning declaring
> 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of
> course we'd
> > have to carefully merge back any fixes that might be
> missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the
> energy to do all
> > that cleanly. I didn't even get round to set up
> release builds
> > on new.elego.de via Hudson in
> order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my
> home machine's
> > complete crash in December. So the release engineering
> support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate
> release,
> > but somebody really needs to do all the housekeeping
> of comparing
> > and merging branches. And we shouldn't start a new
> release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the
> release engineering
> > tasks (including Hudson management and re-targeting to
> the new release)?
> > 
> > Please keep in mind that we haven't managed to get
> out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869
> fax: +49 30 23 45 86 95
> > http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> > 
> 
> 


      


From hendrik at topoi.pooq.com  Thu Jan 21 19:02:29 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:02:29 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
Message-ID: <20100121180229.GA13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
> Subranges have a memory size that depends on the size of the subrange.  
> All arithmetic is performed using the precision of the base type 
> however.

If the compiler can prove it makes no difference, shorter arithmetic is 
sometimes possible.

-- hendrik


From hendrik at topoi.pooq.com  Thu Jan 21 19:14:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:14:56 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <20100121181456.GC13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. 
> Bring the X interface up to date(X11R6) and support things like DRM, 
> XRandr, etc... And update OpenGL for NURBS, VBOs, etc...

I hear the OpenGL itself is undergoing massive change at the moment.  We 
may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
told, no longer deals in individual triangles, squares, and the like, 
but only in arrays of same, to better use graphic card parallelism.

-- hendrik


From peter.mckinna at gmail.com  Thu Jan 21 20:33:54 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 22 Jan 2010 06:33:54 +1100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>

I've been looking at this area a bit. I have just completed the interface to
GLUT which should be ready to commit in a few weeks as soon as i get a few
more examples tested. This gives you the conventional opengl/X linking. Its
taken a while to get my head around swig which seems a better way to feed
into the C world. I have also nearly completed a new interface for mysql
giving it a safe M3 interface and gives the complete mysql.h api. I was
thinking of using swig for the gtk bindings but not sure how well the c++
mappings are handled

regards Peter

On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui
> haven't been touched or updated since the early 90s.
>
> Seems like modernising it might attract some more developers. i.e. Bring
> the X interface up to date(X11R6) and support things like DRM, XRandr,
> etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
>
> Is anyone else looking at this area of the system?
>
>
> --
> Chris <Highjinks at gmx.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/fe7d8419/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jan 21 23:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 22:30:00 +0000
Subject: [M3devel] fetch_and_op?
In-Reply-To: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
Message-ID: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>


ok.

 

But notice that they offer both forms really since they also have "modifying asignment operators".
Is that useful/possible to expose?

 


http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html

 


"The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "

 


For now I'll probably just expose add, sub, xor, but not or and and.
We can do them later via a compareexchange loop (see winbase.h which
does something similar for different reasons: lack of intrinsics).

 


Still a ways away from calling this done, because modifying
m3x86.m3 so far requires a lot of guessing/patternmatching.
I don't understand e.g. what "locked" means (not the
one I introduced, what was there).

 


 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 09:23:59 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] fetch_and_op?

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.




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 21 Jan 2010, at 08:29, Jay K wrote:

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)


Tony, are you sure you want to return the old value, not the new value?
That's not great on x86.
I believe for "or" and "and", you end up having to do a compare exchange loops.
 
 
For xor, add, sub, you can compute the old value, ok.
But if caller wanted the old value, he can do that himself also.
Caller can also write a compare_exchange loop.
 
 
Therefore, I think it should be:
 
(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)

There is of course value in storing the value in mem and stack, since mem
can change right away.
 
 
 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/0f3714c0/attachment-0001.html>

From dragisha at m3w.org  Thu Jan 21 23:27:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 21 Jan 2010 23:27:12 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
Message-ID: <1264112832.3531.22.camel@faramir.m3w.org>

Modernizing of GUI is not so big a problem - lots of C(++) libraries
around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
- there's nothing like a manual touch! And I've wrapped pthreads, mysql,
sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.

Modula-3 philosophy (at least it looks to me sometimes) is to think
about Modula-3 legacy libraries/project like it's something carved in
stone... To be kosher we must use right (legacy of course and
all-platforms of coursier :)) libraries for every job.... Nice idea, esp
when we whink longer term maintenance... But what made projects like,
for example, Linux desktop successful is not single solution path - it's
diversity of possible solutions.

Main problem with diversity of solutions is multi-platform nature of
Modula-3 - solutions not multi-platform are not likely to be accepted...
And while it's relatively easy to wrte your Modula-3 code multiplatfom,
taking care of C(++) libraries can be real pain....

Thus said - I can tell you one thing - JUST DO IT :). I don't see a
problem if my projects work only on Linux - once I have incentive to go
through a hassle to make it work on Windows, I'll synchronize. But it's
important to to many things with Modula-3 - more will come a lot easier.

On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> I've been looking at this area a bit. I have just completed the
> interface to GLUT which should be ready to commit in a few weeks as
> soon as i get a few more examples tested. This gives you the
> conventional opengl/X linking. Its taken a while to get my head around
> swig which seems a better way to feed into the C world. I have also
> nearly completed a new interface for mysql giving it a safe M3
> interface and gives the complete mysql.h api. I was thinking of using
> swig for the gtk bindings but not sure how well the c++ mappings are
> handled 
>  
> regards Peter 
> 
> 
> On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
>         It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
>         in m3-ui haven't been touched or updated since the early 90s.
>         
>         Seems like modernising it might attract some more developers.
>         i.e. Bring the X interface up to date(X11R6) and support
>         things like DRM, XRandr, etc... And update OpenGL for NURBS,
>         VBOs, etc...
>         Trestle is easy to write for, but it really is butt ugly.
>         
>         Is anyone else looking at this area of the system?
>         
>         
>         --
>         Chris <Highjinks at gmx.com>
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Fri Jan 22 00:23:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 18:23:52 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100121180229.GA13592@topoi.pooq.com>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
Message-ID: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>

Possibly, but it would require some fairly strong type analysis in the compiler.  And of course it is not fully general.

On 21 Jan 2010, at 13:02, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
>> Subranges have a memory size that depends on the size of the subrange.  
>> All arithmetic is performed using the precision of the base type 
>> however.
> 
> If the compiler can prove it makes no difference, shorter arithmetic is 
> sometimes possible.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/ecefed11/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 22 01:02:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 19:02:25 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
	<COL101-W444844DDB04656E4B49275E6630@phx.gbl>
Message-ID: <433C7056-D71E-4A01-8C82-7B3F44FC363F@cs.purdue.edu>

Wrong link.  I'm talking C not C++.

Here's the C link:

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf

PS I am shortly about to change the specs on compare exchange in M3CG_Ops.i3.  Stay tuned.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 17:30, Jay K wrote:

> ok.
>  
> But notice that they offer both forms really since they also have "modifying asignment operators".
> Is that useful/possible to expose?
>  
> 
> http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html
>  
> 
> "The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "
>  
> 
> For now I'll probably just expose add, sub, xor, but not or and and.
> We can do them later via a compareexchange loop (see winbase.h which
> does something similar for different reasons: lack of intrinsics).
>  
> 
> Still a ways away from calling this done, because modifying
> m3x86.m3 so far requires a lot of guessing/patternmatching.
> I don't understand e.g. what "locked" means (not the
> one I introduced, what was there).
>  
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 21 Jan 2010 09:23:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] fetch_and_op?
> 
> I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.
> 
> 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 21 Jan 2010, at 08:29, Jay K wrote:
> 
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/b17f3a47/attachment-0001.html>

From Highjinks at gmx.com  Fri Jan 22 01:29:35 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 01:29:35 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100121181456.GC13592@topoi.pooq.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<20100121181456.GC13592@topoi.pooq.com>
Message-ID: <20100121203246.25046ad5.Highjinks@gmx.com>

On Thu, 21 Jan 2010 13:14:56 -0500
hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers. i.e. 
> > Bring the X interface up to date(X11R6) and support things like DRM, 
> > XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> 
> I hear the OpenGL itself is undergoing massive change at the moment.  We 
> may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
> told, no longer deals in individual triangles, squares, and the like, 
> but only in arrays of same, to better use graphic card parallelism.
> 
> -- hendrik

Definitely a chore. As an excercise I plan to start porting the NeHe tutorials over to Modula 3. However, a big question for me is where to begin.

Idealy an application written to the older standards should still be able to compile and run on new cards, which MIGHT mean mapping the current bindings over top a set bindings to the new standards. We'll see how the standards board deals with that issue.

Also upgrading the X bindings will also be a challenge. The nice thing about the current X window system is that it's far more modular than the X11R4 in the current library. That should make it easier to upgrade the interface systematically, one piece at a time.
-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 12:55:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 11:55:29 +0000
Subject: [M3devel] NT386 div/mod
Message-ID: <COL101-W5358CF13F1BCC0A6C02A8DE6620@phx.gbl>


It is interesting to note that NT386 doesn't use the m3_mod/div functions, but generates inline code:

 

PROCEDURE diffdivOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>
    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*   MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*   XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*   JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*   XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*   CDQ               *)
    END;
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*   JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab        *)
    noargOp(t, Op.oCDQ);                              (*   CDQ               *)
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*   CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*   JE  endlab        *)
    decOp(t, t.reg[EAX]);                             (*   DEC EAX           *)
    set_label(t, endlab);                             (* .endlab             *)
  END diffdivOp;

 

PROCEDURE diffmodOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>

    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*    MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*    XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*    JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*    XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*    CDQ               *)
    END;
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*    JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab         *)
    noargOp(t, Op.oCDQ);                              (*    CDQ               *)
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*    CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*    JE  endlab        *)
    binOp(t, Op.oADD, t.reg[EDX], divisor);           (*    ADD EDX, divisor  *)
    set_label(t, endlab);                             (* .endlab              *)
  END diffmodOp;


 

I haven't tested it yet, but of course you can see that same signed inputs are simpler, like with the code in hand.c.

I'm really starting to like CARDINAL and not INTEGER. :)

(Plus the subtlety that CARDINAL has a default initialization to 0 that Tony told me about.)

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/5bf37fec/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 22 13:05:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:05:10 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>


 > Linux desktop successful 

 

Haha. Military intelligence.

 

 

 > it's diversity of possible solutions.

 

Chaos! Lack of interop. Duplicated effort.

Granted, Darwinism/Capitalism, but very wasteful.

 


 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 


 

I'm sure we can win here, if we do anything.

  (I'm not volunteering. The idea of using Swig is good.)

Just wrap Qt or FLTK or Tk or wxWidgets or such.

Qt is my preferred.

  It seems to have the most active resources spent on it and

  is in the best condition already.

GTk on Windows doesn't seem to get enough attention.

Tk has a seemingly good track record in that

 people have successfully used it already from several

 languages: Python, Perl, Tcl (blech!), C.

wxWidgets also has Python bindings at least.

 

 

Things only get less clear if you worry about non Win32/64/XWindows

platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.

And Trestle doesn't support any of those anyway, and they are all

"obsolete" except non-X Mac (see also: iPhone!)

I'm surprised I haven't see that Qt supports iPhone.

If a library does support Carbon/Cocoa that is a point in favor imho.

 


 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/ad0b88a8/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 22 13:11:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:11:47 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W10C5CCBC345BFB0C3AF22DE6620@phx.gbl>


> > Trestle is easy to write for, but it really is butt ugly.


 

I should point that making Trestle not look ugly is perhaps

a much smaller task than wrapping any other library.

 

 

Randy's Win32 changes to Trestle definitely make it look better for example.

 

 

It was previously asserted that X Trestle shall not look like Win32.

However, X Trestle doesn't look like anything except itself, right?

So I figure Win32 is among the good choices.

Besides, given that there is no "standard X look", even if X Trestle

does look like *something*, Win32 would still be preferable.

(This would remove the forking we have where only one fork

or another has a bug, X vs. Win32..really need to merge/refactor

that code, no matter the decision and the resulting look..)

 

 - Jay

 


From: jay.krell at cornell.edu
To: dragisha at m3w.org; peter.mckinna at gmail.com
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Modernising m3-ui?
Date: Fri, 22 Jan 2010 12:05:10 +0000



 > Linux desktop successful 
 
Haha. Military intelligence.
 
 
 > it's diversity of possible solutions.
 
Chaos! Lack of interop. Duplicated effort.
Granted, Darwinism/Capitalism, but very wasteful.
 

 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 

 
I'm sure we can win here, if we do anything.
  (I'm not volunteering. The idea of using Swig is good.)
Just wrap Qt or FLTK or Tk or wxWidgets or such.
Qt is my preferred.
  It seems to have the most active resources spent on it and
  is in the best condition already.
GTk on Windows doesn't seem to get enough attention.
Tk has a seemingly good track record in that
 people have successfully used it already from several
 languages: Python, Perl, Tcl (blech!), C.
wxWidgets also has Python bindings at least.
 
 
Things only get less clear if you worry about non Win32/64/XWindows
platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.
And Trestle doesn't support any of those anyway, and they are all
"obsolete" except non-X Mac (see also: iPhone!)
I'm surprised I haven't see that Qt supports iPhone.
If a library does support Carbon/Cocoa that is a point in favor imho.
 

 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/9a1ddafa/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 22 13:39:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:39:21 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
Message-ID: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>


Anyone have any thoughts on how to implement LONGINT on NT386?

 


The code is setup to do pretty good constant folding and enregistration.

 


I did the work so that constant folding should work for LONGINT.

 


However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 

In particular, there is still this notion of an "operand"
that might be held in one register.


 

I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.

 


96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.


 

Returning LONGINT from a function also needs separate attention.

Maybe I really should go ahead and use an array of registers?

 


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/5c313ffc/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Jan 22 15:49:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 09:49:28 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
Message-ID: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>

That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.

On 22 Jan 2010, at 07:39, Jay K wrote:

> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/191742a5/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri Jan 22 20:13:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 22 Jan 2010 14:13:14 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
	<DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
Message-ID: <20100122191314.GA6271@topoi.pooq.com>

On Thu, Jan 21, 2010 at 06:23:52PM -0500, Tony Hosking wrote:
> Possibly, but it would require some fairly strong type analysis in the 
compiler.

Analysis that could be done during code generation.

>  And of course it is not fully general.

Of course.  Optimisations only work when they can be proved to.  But 
when they do work, they can make a lot of difference.

-- hendrik


From rodney_bates at lcwb.coop  Fri Jan 22 20:56:37 2010
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Fri, 22 Jan 2010 19:56:37 -0000 (GMT)
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
Message-ID: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>

>
> So..I have m3back using Target.Int a bunch.
>
> And converting back and forth some between Target.Int and
>
> INTEGER and doing match with Target.Int.
>
> And various operations can fail.
>
>
>
>
>
> And my current diff results in:
>
>
>
>
>
>   new source -> compiling Lex.m3
>   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
>   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
>   2 errors encountered
>   new source -> compiling Scan.i3
>
>
>
>
>
>   which is nice to see, it means my code is actually running.
>
>
>
>
>
>   So I look at the code in question:
>
>
>
>
>
>   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> Word.T
>   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> ...
>
>     IF signed AND
>        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
>         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
>       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> ....
>
>
>
>
>
> -FIRST(INTEGER).
>
>
>
>
>
> What is that supposed to do?
>
>
>
>
>
> I mean, I kind of know, I'm slightly playing stupid, partly not.
>
> Does the compiler know what is an INTEGER vs. what is a "Word"?
  ---------------------------------------------------------Word.T?

No, they are the same type.

> Or it is just obligated to assume everything is a Word?

It is obligated to do the builtin operators (unary - being one
of these) using signed interpretation of the value and functions
in Word using unsigned interpretation.

The signed operators don't assume anything about the machine
representation.  The functions in Word do assume two-s complement
binary, in order to be defined.  This is a low-level facility.

>  To do the negation at compile time and ignore the overflow?

This may be poorly specified.  The code sample you cite clearly assumes
this is what it does.  The compile errors indicate the assumption
has become wrong.

> Does the language need work here?

Overflow detection wars!  But surely, we could agree that compile time
arithmetic should do the same thing as runtime would, for a given
implementation.

> I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

Yes, it's a statically unconditional overflow, and the language doesn't
specify what happens.

As long as we are assuming two-s complement binary, I would just remove
the - in front of FIRST(INTEGER). If the compiler does not consider it
and overflow error and wraps around, in this particular case, the - is
an identity operation on the bits.  Maybe the writer intended the -
to hint to a human reader that unsigned interpretation is about to be
applied to this value.

>
>
>
>
>  - Jay
>
>
>




From Highjinks at gmx.com  Fri Jan 22 22:09:53 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 22:09:53 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
Message-ID: <20100122171259.f8cdc16c.Highjinks@gmx.com>

My opinion on what to do as far as these libs are concerned...

First, we should just stick to updating what's already there, right? Add bindings to Xrandr, XCBlib, Cairo, etc.. in a new X11R6 directory. Break down that X.i3 file into several smaller modules. Major changes should wait till later. Bindings to QT, GTK, etc.. are good ideas, but should be OPTIONAL, not required. Undoubtedly many platforms that will be running Modula 3 applications will not have one or either of these libraries installed.
Theres also the possibility of building our own Windowing toolkit. We already have Trestle. Maybe call it "Beam"?

The same with OpenGL. Point in case, MiniGLX. Theres a good chance that any platform using MiniGLX will not have X Windows, or any other Windowing environment installed. 

Consider embedded and kiosk environments. Modula 3 is well suited to these sorts of applications, but these environments are usually limited in the size and scope of the libraries and code they can run.

Later on, we could extend Trestle and even create our own Scenegraph library for OpenGL, if it makes sense to do so.  Hrrrmmm...Call the Scenegraph lib "Ray"?

I have a little free time coming up this weekend. I'll be porting some of the demos I have over to OpenGL, and doing a little M3/XCBlib hacking. Anyone want me to post these up somewhere, for the "lulz" as it were?

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 23:51:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:51:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
Message-ID: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>


I think there is a language hole here.The language should perhaps allow forunsigned literals and unsigned constantexpressions.

Something I don't quite have my head around as well,maybe a language/library hole, is how to doe.g. the below, without assuming two's complementrepresentation of signed integers.

Can we maybe add Word.AbsoluteValueOfInteger?The implementation would, roughly:  IF i < 0 THEN     i := -i;  END;  RETURN i;  END;
with the extra qualification that overflow is silent

 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.
Uh huh. This is why you need *different types* (or interfaces)for the variety of integer overflow behavior and not a runtimesetting. Otherwise the compiler can't know what theruntime behavior is.

As well, using static typing instead of a runtime setting,allows for efficiency. Imagine, say, if x86 does requireextra code to check for overflow.Well, if using "integer-with-silent-overflow", thatwould be omitted. If using "integer-with-overflow"the code would be included.

I introduce the error. It used to be silent.I changed it to a warning, for thevery specific case of negating FIRST(INTEGER).Any other overflow here, which is probably notpossible, will still error.
 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> >   new source -> compiling Lex.m3
> >   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> >   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> >   2 errors encountered
> >   new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> >   which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> >   So I look at the code in question:
> >
> >
> >
> >
> >
> >   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> >   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> >     IF signed AND
> >        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> >         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> >       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
>   ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation.  The functions in Word do assume two-s complement
> binary, in order to be defined.  This is a low-level facility.
> 
> >  To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified.  The code sample you cite clearly assumes
> this is what it does.  The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars!  But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits.  Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> >  - Jay
> >
> >
> >
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/e3ab2126/attachment-0001.html>

From jay.krell at cornell.edu  Fri Jan 22 23:53:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:53:41 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W56A6FF0AF064BA0D485D6DE6620@phx.gbl>


I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/14d9d0fe/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Jan 23 00:52:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 18:52:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
Message-ID: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>

There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.

Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.

Constant expressions:

CONST x = Word.Plus(16_FFFF, 1)


On 22 Jan 2010, at 17:51, Jay K wrote:

> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/2b9bcb0a/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 23 06:00:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 05:00:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W286ECA1F5DDC64BBA034F7E6610@phx.gbl>


Sorry, not literals.

 

How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?

 

How do I express -FIRST(INTEGER)? Without incurring signed overflow

while evaluating the constant expression?

 

For a one's complement system, nothing wrong with -FIRST(INTEGER).

  It equals LAST(INTEGER).

 

But for a two's complement system, evaluating -FIRST(INTEGER)

 incurs overflow.

 

Maybe:

 Word.Add(-(FIRST(INTEGER) + 1)), 1)

 

?

 

Probably. I'll try that.

 

You know, C has the same dilemna and similar solution.

not a great idea to write

unsigned u = (unsigned)-INT_MIN;

 

nor

 

unsigned u = -(unsigned)INT_MIN;

 

though the second is maybe ok.

The first incurs signed overflow in C as well.

Which isn't defined. The first also gets a warning

with some compilers: "negating unsigned is still unsigned".

 

An idiom is

unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;

 

derivation:

INT_MIN + 1 yields a negative number that can be safely negated.

Which yields a positive number one less than the desired value.

 

 

 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here.
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100123/8dcb02d6/attachment-0001.html>

From dragisha at m3w.org  Sat Jan 23 11:53:28 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 11:53:28 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244008.3883.777.camel@faramir.m3w.org>

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
>  > Linux desktop successful 
>  
> Haha. Military intelligence.

Orders of magnitude more than yours and mine favorite project.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sat Jan 23 12:06:04 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 12:06:04 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244764.3883.803.camel@faramir.m3w.org>

What SWiG does is only tiniest possible piece of work. Modula-3's way is
not about accepting somebody's (especially C-world's) ideas on
modularity/API's/... and mappping variables/procedures/functions/... to
Modula-3 ones. C world  API's are more or less nightmare, my "favourite"
being pthreads which is full of compromises made to get (mainly) Sun's
signature on standard... sqlite3 is another one not too away from....

But, of course, it's everybody's right to spend her time SWiG-ging
around :)... Me, after tons of experience with it, I'll continue to work
mostly by hand. Automated solutions we need aren't in SWiG... To make,
for example, proper Modula-3 objects from Gtk gobjects, we need custom
conversions...

I've already dipped into this with Gtk and it's enlightening... It's
customary in Python/Perl (h2def, gtkdoc) world to use regexps for
parsing.... When I saw it first I smiled, but when I tried two different
tools and got same buggy output, it became more serious :). 

What we need to exploit widely available C libraries is good and
proper .h parser, and then some tools to rewrite them into Modula-3...
What SWiG offers is one posibility, but we need someone proficient with
Modula-3 to join them - first guy who tried it went Haskell some time
ago.

dd

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
> > Main problem with diversity of solutions is multi-platform nature
> of 
>  > Modula-3 - solutions not multi-platform are not likely to be
> accepted... 
> 
>  
> I'm sure we can win here, if we do anything.
>   (I'm not volunteering. The idea of using Swig is good.)
> Just wrap Qt or FLTK or Tk or wxWidgets or such.
> Qt is my preferred.
-- 
Dragi?a Duri? <dragisha at m3w.org>



From m3 at sol42.com  Sat Jan 23 12:17:07 2010
From: m3 at sol42.com (Daniel Solaz)
Date: Sat, 23 Jan 2010 12:17:07 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
Message-ID: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>

I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.

Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.

Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.

Regards.
-Daniel

From jay.krell at cornell.edu  Sat Jan 23 16:31:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 15:31:38 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>


 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000








I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100123/f126f399/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jan 23 20:30:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 19:30:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>


Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?

As well, should we go the extra bit and disallow it even if it doesn't overflow?
  ie: on one's complement?

 

 

I already disallow it in some code -- depending on which code gets

hit in the backend. But this disallowing is new.

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
Date: Sat, 23 Jan 2010 05:00:34 +0000



Sorry, not literals.
 
How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
 
How do I express -FIRST(INTEGER)? Without incurring signed overflow
while evaluating the constant expression?
 
For a one's complement system, nothing wrong with -FIRST(INTEGER).
  It equals LAST(INTEGER).
 
But for a two's complement system, evaluating -FIRST(INTEGER)
 incurs overflow.
 
Maybe:
 Word.Add(-(FIRST(INTEGER) + 1)), 1)
 
?
 
Probably. I'll try that.
 
You know, C has the same dilemna and similar solution.
not a great idea to write
unsigned u = (unsigned)-INT_MIN;
 
nor
 
unsigned u = -(unsigned)INT_MIN;
 
though the second is maybe ok.
The first incurs signed overflow in C as well.
Which isn't defined. The first also gets a warning
with some compilers: "negating unsigned is still unsigned".
 
An idiom is
unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
 
derivation:
INT_MIN + 1 yields a negative number that can be safely negated.
Which yields a positive number one less than the desired value.
 
 
 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here. 
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100123/8d175afb/attachment-0001.html>

From Highjinks at gmx.com  Sat Jan 23 23:02:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 23 Jan 2010 23:02:22 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
Message-ID: <20100123180535.9ee26d0e.Highjinks@gmx.com>

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hendrik at topoi.pooq.com  Sat Jan 23 23:13:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:13:35 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <20100123221335.GC6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> 
> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> 
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?

The only reason for disallowing it is overflow, and then only for an 
implementation that checks overflow.  But if it doesn't overflow, 
it doesn't overflow, and it's valid.

-- hendrik

> I already disallow it in some code -- depending on which code gets
> 
> hit in the backend. But this disallowing is new.

It might warrant a portability warning, if we issue such.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan 23 23:15:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:15:03 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <20100123221503.GD6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
> 
> > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> > 
> > Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > 
> > Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> > 
> > Regards.
> > -Daniel
> 
> Good points.
> 
> I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> 
> Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> 
> So, bindings are the way to start at least. Alright then. Time to get hacking.

Especially bindings to subsystems and toolkits that are available in a 
variety fo platforms.

-- hendrik

> -- 
> Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Sun Jan 24 01:35:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:35:18 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123221503.GD6033@topoi.pooq.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>,
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<20100123221503.GD6033@topoi.pooq.com>
Message-ID: <COL101-W45BB63A36E65A8F0A9421E6600@phx.gbl>


 > wraps the native toolkit on each platform

 

I don't think wrapping native is the way to go.

Too much work to then have a common interface.


> Especially bindings to subsystems and toolkits that are available in a variety fo platforms.

 

 

Yes.

E.g. Qt, FLTK, Tk, etc.

I think Qt is the best, based on highly non-scientific data.

 

 

- Jay
 
> Date: Sat, 23 Jan 2010 17:15:03 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> > On Sat, 23 Jan 2010 12:17:07 +0100
> > Daniel Solaz <m3 at sol42.com> wrote:
> > 
> > > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets. Where there is no single native toolkit, choose the best or most used. Portability, full interoperability and looking/feeling native are the key points here.
> > > 
> > > Developing a new toolkit in pure Modula-3 is a waste of effort. Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on. Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect. SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > > 
> > > Making Trestle look good will only get us so far. I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts. Text handling comes to mind, and scrollbars too.
> > > 
> > > Regards.
> > > -Daniel
> > 
> > Good points.
> > 
> > I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> > 
> > Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> > 
> > So, bindings are the way to start at least. Alright then. Time to get hacking.
> 
> Especially bindings to subsystems and toolkits that are available in a 
> variety fo platforms.
> 
> -- hendrik
> 
> > -- 
> > Chris <Highjinks at gmx.com>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/9217803c/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 24 01:45:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:45:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>,
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>,
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <COL101-W78609AC77B82C715B3289E6600@phx.gbl>


What I meant was..like..hypothetically..if we had a one's complement

target, would we error for -FIRST(INTEGER), since it would

overflow on other systems. Nevermind.

 

 

 - Jay 

 

> Date: Sat, 23 Jan 2010 17:13:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> CC: hendrik at topoi.pooq.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> > 
> > Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> > 
> > As well, should we go the extra bit and disallow it even if it doesn't overflow?
> > ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow. But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
> > I already disallow it in some code -- depending on which code gets
> > 
> > hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/563207ef/attachment-0001.html>

From darko at darko.org  Sun Jan 24 02:59:26 2010
From: darko at darko.org (Darko)
Date: Sun, 24 Jan 2010 12:59:26 +1100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <3E4F467C-0634-4566-9248-CC1D1F79EC64@darko.org>

Here is the Cairo API done in M3 and I have a few others. I'd like to promote this style of naming, where prefixes matching the interface name are removed, so CairoSave in C becomes Cairo.Save in M3.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cairo.i3
Type: application/octet-stream
Size: 21401 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/51166a02/attachment-0001.obj>
-------------- next part --------------



On 24/01/2010, at 9:02 AM, Chris wrote:

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Sun Jan 24 10:23:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:23:29 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <6F19D0A2-AAE4-4268-AACE-7F24E348A122@cs.purdue.edu>

I still don't understand what is broken here...

On 23 Jan 2010, at 14:30, Jay K wrote:

> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?
>  
>  
> I already disallow it in some code -- depending on which code gets
> hit in the backend. But this disallowing is new.
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
> Date: Sat, 23 Jan 2010 05:00:34 +0000
> 
> Sorry, not literals.
>  
> How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
>  
> How do I express -FIRST(INTEGER)? Without incurring signed overflow
> while evaluating the constant expression?
>  
> For a one's complement system, nothing wrong with -FIRST(INTEGER).
>   It equals LAST(INTEGER).
>  
> But for a two's complement system, evaluating -FIRST(INTEGER)
>  incurs overflow.
>  
> Maybe:
>  Word.Add(-(FIRST(INTEGER) + 1)), 1)
>  
> ?
>  
> Probably. I'll try that.
>  
> You know, C has the same dilemna and similar solution.
> not a great idea to write
> unsigned u = (unsigned)-INT_MIN;
>  
> nor
>  
> unsigned u = -(unsigned)INT_MIN;
>  
> though the second is maybe ok.
> The first incurs signed overflow in C as well.
> Which isn't defined. The first also gets a warning
> with some compilers: "negating unsigned is still unsigned".
>  
> An idiom is
> unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
>  
> derivation:
> INT_MIN + 1 yields a negative number that can be safely negated.
> Which yields a positive number one less than the desired value.
>  
>  
>  - Jay
> 
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 18:52:05 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.
> 
> Literals:
> 
> If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.
> 
> Constant expressions:
> 
> CONST x = Word.Plus(16_FFFF, 1)
> 
> 
> On 22 Jan 2010, at 17:51, Jay K wrote:
> 
> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/1c654099/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 24 10:24:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:24:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>

Agreed.  If we allow overflow at run-time we should at compile-time.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 17:13, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
>> 
>> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
>> 
>> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>>  ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow.  But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
>> I already disallow it in some code -- depending on which code gets
>> 
>> hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/001d7332/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 24 10:25:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:25:07 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
	<COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
Message-ID: <283D5C6F-607F-47E1-A53A-BFE01EA3018D@cs.purdue.edu>

Yes, I meant the machine stack for LONGINT values.  Regs only for INTEGER.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 10:31, Jay K wrote:

>  > You might easily just push/pop operands and return values on the stack
> 
> I don't think I understood you.
> My "worst case" was to store everything in temporaries.
> But I think I see now.
> Some sort of stack is required.
> There is the "virtual stack" already in use. (I assume "v" = "virtual").
>    It should already handle constant folding, but its register manipulation isn't right for 64bit values.
> I think what I see now -- just use the machine stack.
> Even to push immediate values.
> And, to be really lame, most/all operations can be function calls.
>  And not even in the "normal" way, but like:
> 
> 
> #ifdef _WIN32
> 
> 
> void __stdcall m3_add64(__int64 a)
> {
>     (&a)[1] += a;
> }
> 
> 
> void __cdecl m3_neg64(__int64 a)
> {
>     a = -a;
> }
> 
> 
> where we convince the C compiler to do the right stack maintenance.
> We'd just generate parameter-less calls.
> For actually passing longint parameters to real Modula-3 functions,
> I'd have to look, but, like, pop_param would do nothing.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] thoughts on NT386/LONGINT?
> Date: Fri, 22 Jan 2010 22:53:41 +0000
> 
> I'll see what I can figure out.
> 
> 
> I considered pushings pairs of operands in m3x86.m3 but I think
> that won't work.
> 
> 
> Noticing how integer vs. floating point is handled
> is perhaps useful, as this is another way in which m3cg
> is "homogenous" but backends have to act differently
> based on type.
> 
> 
>  - Jay
> 
> 
> 
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 09:49:28 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] thoughts on NT386/LONGINT?
> 
> That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
> 
> On 22 Jan 2010, at 07:39, Jay K wrote:
> 
> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/4a9b00f9/attachment-0001.html>

From dmuysers at hotmail.com  Sun Jan 24 10:32:13 2010
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Sun, 24 Jan 2010 10:32:13 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>

What about IUP ?
It's the one with the narrowest interface...

--------------------------------------------------
From: "Chris" <Highjinks at gmx.com>
Sent: Saturday, January 23, 2010 11:02 PM
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] On Trestle, OpenGL, etc...

> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
>
>> I think the only way to go is a single Modula-3 API that wraps the native 
>> toolkit on each platform, sort of like wxwidgets.  Where there is no 
>> single native toolkit, choose the best or most used.  Portability, full 
>> interoperability and looking/feeling native are the key points here.
>>
>> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has 
>> spent years and billions in Swing, and it still sucks in a different way 
>> every platform it works on.  Worst of all (for me at least) is how it 
>> incorrectly and incompletely mimics the native look and feel, mainly 
>> Motif and GTK, but Mac OS X too; on Windows it looks way better but is 
>> still far from perfect.  SWT is a bit more difficult to use, and not 
>> available (yet?) on every platform, but to me it is the right way to go.
>>
>> Making Trestle look good will only get us so far.  I haven't looked at it 
>> for years, but unless it has changed quite a bit it would require 
>> rewriting significant parts.  Text handling comes to mind, and scrollbars 
>> too.
>>
>> Regards.
>> -Daniel
>
> Good points.
>
> I think your correct that creating bindings to some toolkits are the way 
> to go, for now. Of course the lower level X and OpenGL bindings will still 
> need to be upgraded, just so that thier available for those who want to 
> use them.(I know I will.)
>
> Right now, as far as toolkits go, I'm looking at bindings to 
> Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are 
> good. Maybe bindings to Clutter(http://clutter-project.org/) and 
> Amanith(http://www.amanith.org/) would be useful.
>
> So, bindings are the way to start at least. Alright then. Time to get 
> hacking.
> -- 
> Chris <Highjinks at gmx.com>
> 


From jay.krell at cornell.edu  Sun Jan 24 12:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 11:13:07 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <COL101-W19EFB4F971A68D816BA2D9E6600@phx.gbl>


I had never heard of it. Looks good.

 

 - Jay
 
> From: dmuysers@
> To: Highjinks@; m3devel@
> Date: Sun, 24 Jan 2010 10:32:13 +0100
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> What about IUP ?
> It's the one with the narrowest interface...
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/f570b384/attachment-0001.html>

From hendrik at topoi.pooq.com  Sun Jan 24 14:00:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:00:33 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <20100124130032.GA27093@topoi.pooq.com>

On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> What about IUP ?
> It's the one with the narrowest interface...

Does it run on OS X?  With or without X?

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 24 14:16:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:16:51 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
Message-ID: <20100124131650.GB16928@topoi.pooq.com>

On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> Agreed.  If we allow overflow at run-time we should at compile-time.

But perhaps a compile-time warning is in order for overflow -- in cases 
where we do the arithmetic at compile-time, anyway.  We may avoid 
run-time checks for speed reasons, but there's no such constraint 
on compile-time checks.

-- hendrik


From jay.krell at cornell.edu  Sun Jan 24 14:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 13:50:17 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100124130032.GA27093@topoi.pooq.com>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>,
	<20100124130032.GA27093@topoi.pooq.com>
Message-ID: <COL101-W14D28108FC156C65A1F4BDE6600@phx.gbl>


Mac support unclear.

That's maybe a reason to favor e.g. Qt, Tk, wxWidgets.

 

http://www.tecgraf.puc-rio.br/iup/

http://www.tecgraf.puc-rio.br/iup/en/to_do.html

 

They don't clearly list that they have any currently, but they

do list that they want to..even using Carbon (not sure

Carbon is viable going forward, to AMD64_DARWIN).

 

 - Jay

 
> Date: Sun, 24 Jan 2010 08:00:33 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> > What about IUP ?
> > It's the one with the narrowest interface...
> 
> Does it run on OS X? With or without X?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/b40de143/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Jan 24 23:38:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 17:38:30 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100124131650.GB16928@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
Message-ID: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>

But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
>> Agreed.  If we allow overflow at run-time we should at compile-time.
> 
> But perhaps a compile-time warning is in order for overflow -- in cases 
> where we do the arithmetic at compile-time, anyway.  We may avoid 
> run-time checks for speed reasons, but there's no such constraint 
> on compile-time checks.
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/cbecd54e/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jan 25 12:14:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Jan 2010 11:14:57 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W41670ACD92514D9933EF99E65F0@phx.gbl>


 >> I think what I see now -- just use the machine stack.


I'm not sure this works so easily if you consider function calls.

  Taking a mix of LONGINT and non-LONGINT parameters.

 

There'd be a series of load_integer and pop_param calls.

Normally all the machine stack pushes are in pop_param.

Now they'd be in a mix of load_integer and pop_param.

If pop_param is called as each parameter is computed, ok.

If they are all computed and then all popped, not ok.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out.




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100125/ba87074b/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 26 13:15:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 12:15:21 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W25B5537DA495533A5E563EE65E0@phx.gbl>


I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.

 

In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.

And also double (LONGFLOAT, whatever).

 

This would help with atomic compare exchange on 64 bit values on x86.

It would probably let us drop the m3cg x86 -mno-align-double switch.

  That would have saved me quite some debugging time a while ago....

Not sure about -munaligned-doubles though on Linux/sparc.

 

I'd have to check what the language allows, but if there is "adequate" and

"ideal" alignment, then users should maybe be able to ask for "adequate"

if they have large arrays and want to optimize for memory.

 

Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.

Though max_align doesn't appear to be applied to jmpbufs.

 

Notice that the language doesn't let you declare such high alignment.

 

- Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/6742ac38/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 26 14:04:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:04:38 +0000
Subject: [M3devel] doextract_mn, doextract_n, insert_mn, insert_n
Message-ID: <COL101-W350F45564A26EDD4ADECADE65E0@phx.gbl>


doextract_mn, doextract_n, insert_mn, insert_n

 


We don't *really* need any of these in M3CG.i3.
They make it easier for the backend to optimize,
but the integrated backend *always* optimizes
as well as these allow for.

 


I noticed in the frontend that its helper function Insert_mn (capital I)
is never used, because GenInsert.mg fails to do the
optimizations that GenExtract.mg does.

 


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/c9f2d54e/attachment-0001.html>

From jay.krell at cornell.edu  Tue Jan 26 14:21:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:21:44 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W344C1DE585165E3C53E644E65E0@phx.gbl>


Visual C++/x86:

 

 

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(__int64));
 return 0;
}

gcc/Linux/x86:

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(long long));
 return 0;
}

 

 

both print "8 8".

 

 

Fixing this would break some pickles that contain LONGINT and/or LONGREAL, depending on if they needed padding to align.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: max_align
Date: Tue, 26 Jan 2010 12:15:21 +0000



I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.
 
In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.
And also double (LONGFLOAT, whatever).
 
This would help with atomic compare exchange on 64 bit values on x86.
It would probably let us drop the m3cg x86 -mno-align-double switch.
  That would have saved me quite some debugging time a while ago....
Not sure about -munaligned-doubles though on Linux/sparc.
 
I'd have to check what the language allows, but if there is "adequate" and
"ideal" alignment, then users should maybe be able to ask for "adequate"
if they have large arrays and want to optimize for memory.
 
Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.
Though max_align doesn't appear to be applied to jmpbufs.
 
Notice that the language doesn't let you declare such high alignment.
 
- Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100126/495e228a/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 27 15:01:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 14:01:04 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
Message-ID: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>


MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.

 

 

 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked


 

 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.



 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/383d90a1/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan 27 16:57:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 10:57:09 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
Message-ID: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>

If we declare it as a 32-bit subrange it should just work, right?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 27 Jan 2010, at 09:01, Jay K wrote:

> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>   the closure marker being a 4 byte -1 instead of an INTEGER.
>  
>  
>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
> 
>  
>  That is, we should probably make their be a per-target variable "closure marker size"
>   that is 4 for all current targets (IA64 should probably be 16 though),
>   though one would have to look into the various instruction encodings.
> 
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/1f8764ec/attachment-0001.html>

From jay.krell at cornell.edu  Wed Jan 27 17:17:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 16:17:50 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>


yes, but I think it is target-specific. IA64 would use 16 bytes.

It isn't even in library code, but generated code.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 27 Jan 2010 10:57:09 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"

If we declare it as a 32-bit subrange it should just work, right?




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 27 Jan 2010, at 09:01, Jay K wrote:

MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.
 
 
 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked

 
 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/fb38ff98/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Jan 27 17:19:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 11:19:54 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <EE6487AA-9BA1-4D9A-BFCA-053FC6B8487C@cs.purdue.edu>

Sorry.  Just realised this is deeply embedded in the Target files.


On 27 Jan 2010, at 10:57, Tony Hosking wrote:

> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>>   the closure marker being a 4 byte -1 instead of an INTEGER.
>>  
>>  
>>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
>> 
>>  
>>  That is, we should probably make their be a per-target variable "closure marker size"
>>   that is 4 for all current targets (IA64 should probably be 16 though),
>>   though one would have to look into the various instruction encodings.
>> 
>> 
>>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/41b44d37/attachment-0001.html>

From rodney_bates at lcwb.coop  Wed Jan 27 23:19:21 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 27 Jan 2010 16:19:21 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
Message-ID: <4B60BBE9.7020401@lcwb.coop>

Before anybody fiddles with closure markers, *please* do *both* the following:

1)  Let me know.  M3gdb needs to both recognize and construct closures
     (and it currently does.)  Changing them will break it, unless it is
     modified accordingly.

2)  Make sure there is some reasonable way m3gdb can tell by looking at
     the object code being debugged, whether it was generated by a
     compiler version that uses the old or the new closure marker
     representation.

I have worked hard to make m3gdb able to adapt to the various compilers
and versions, but periodically I get undermined on 1) and/or 2) above
by some quiet change somebody makes without thinking about m3gdb.

Also, think about the implications on linking together code produced
by different compiler versions.  I am quite sure changing the closure
representation would mean *all* linked-in libraries would have to be
recompiled, along with the main program, by the same compiler version.

Right now, closure markers are always the same size as pointers, and I think
there are multiple places in the compiler and runtime, in addition to m3gdb,
that rely on this.  They would all have to be located and fixed.  And I
don't think they all key off any single declaration, e.g. closure_marker_size.

Jay K wrote:
> yes, but I think it is target-specific. IA64 would use 16 bytes.
> It isn't even in library code, but generated code.
>  
>  - Jay
> 
>  
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 27 Jan 2010 10:57:09 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
> 
> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>     MIPS64, SPARC64 and maybe others could probably all benefit slightly
>     from
>       the closure marker being a 4 byte -1 instead of an INTEGER.
>      
>      
>      That is: 64bit architectures with a fixed size 4 byte instruction
>     where alignment is checked
> 
>      
>      That is, we should probably make their be a per-target variable
>     "closure marker size"
>       that is 4 for all current targets (IA64 should probably be 16 though),
>       though one would have to look into the various instruction encodings.
> 
> 
>      - Jay
> 
> 


From jay.krell at cornell.edu  Thu Jan 28 02:30:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 28 Jan 2010 01:30:21 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>, ,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>,
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>,
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <COL101-W28BF8C4DD648F3633CB288E65C0@phx.gbl>


Thanks, understood.
No "mainstream" target would be affected -- no x86 target (32bit or 64bit), probably not any 32bit target.
 
 
For IA64 either we we probably want a 128 bit marker, since that is the instruction size, sort of (multiple instructions packed into 128 bit chunks).
 
 
Basically any architecture that has a fixed size 4 byte instruction, 4 byte aligned instructions, where alignment is checked, where pointer is 8 bytes, would be a little more efficient with a 4 byte marker instead of an 8 byte marker. Like, probably any MIPS64 or SPARC64 platform, and maybe some others (HPPA, Alpha, PPC64). Not any x86 or AMD64 though.
 
 
The closure would be smaller and the alignment would naturally be ok. Currently such architectures have to fiddle around with the pointer since it might not be 8 byte aligned. Any call through a function pointer would save a few instructions.
 
 
Really what bugs me most about this area is the time I have wasted in the past learning about it bringing up new platforms!
 
 
It bugs me otherwise -- the assumption that -1 is invalid code. The lack of a good solution here in general -- gcc has nested functions, but it doesn't do it in a good way either -- they generate code on the stack, on some platforms use mprotect to make the page executable, and on some platforms just fail completely (I think iPhone for example).
 
 
I suppose another improvement would be to make the value (-1) configurable per target. I haven't gone to the trouble of disasm'ing -1 on various platforms yet. Probably it is ok. It doesn't even have to be invalid, it just has to not to be the first instruction of a function.
 
 
 - Jay


----------------------------------------
> Date: Wed, 27 Jan 2010 16:19:21 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>
> Before anybody fiddles with closure markers, *please* do *both* the following:
>
> 1) Let me know. M3gdb needs to both recognize and construct closures
> (and it currently does.) Changing them will break it, unless it is
> modified accordingly.
>
> 2) Make sure there is some reasonable way m3gdb can tell by looking at
> the object code being debugged, whether it was generated by a
> compiler version that uses the old or the new closure marker
> representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions. I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this. They would all have to be located and fixed. And I
> don't think they all key off any single declaration, e.g. closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>
>> - Jay
>>
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly
>> from
>> the closure marker being a 4 byte -1 instead of an INTEGER.
>>
>>
>> That is: 64bit architectures with a fixed size 4 byte instruction
>> where alignment is checked
>>
>>
>> That is, we should probably make their be a per-target variable
>> "closure marker size"
>> that is 4 for all current targets (IA64 should probably be 16 though),
>> though one would have to look into the various instruction encodings.
>>
>>
>> - Jay
>>
>> 		 	   		  

From wagner at elegosoft.com  Thu Jan 28 11:31:56 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 28 Jan 2010 11:31:56 +0100
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>

Shouldn't we insert a short version of this warning into the source
code? Or is there no central location where it could be placed and
will be noticed?

This is a non-obvious dependency, and though Jay and Tony will remember
now, there may be others in a few years who don't.

Olaf

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Before anybody fiddles with closure markers, *please* do *both* the   
> following:
>
> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>     (and it currently does.)  Changing them will break it, unless it is
>     modified accordingly.
>
> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>     the object code being debugged, whether it was generated by a
>     compiler version that uses the old or the new closure marker
>     representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions.  I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this.  They would all have to be located and fixed.  And I
> don't think they all key off any single declaration, e.g.   
> closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>  - Jay
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>    from
>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>               That is: 64bit architectures with a fixed size 4 byte  
>>  instruction
>>    where alignment is checked
>>
>>          That is, we should probably make their be a per-target variable
>>    "closure marker size"
>>      that is 4 for all current targets (IA64 should probably be 16 though),
>>      though one would have to look into the various instruction encodings.
>>
>>
>>     - Jay
>>
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Jan 28 17:55:53 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 28 Jan 2010 10:55:53 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>	<4B60BBE9.7020401@lcwb.coop>
	<20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
Message-ID: <4B61C199.2040000@lcwb.coop>

Well, there are many aspects of the runtime organization that affect
m3gdb, and I am afraid they are scattered far and wide in the source
code, so it might be hard to do this systematically.  I have, on
one or two occasions in the past, put a comment in the compiler
or runtime source code, regarding some specific matter that affects
m3gdb.

Maybe I'll look for a good place to note about closure markers.

Olaf Wagner wrote:
> Shouldn't we insert a short version of this warning into the source
> code? Or is there no central location where it could be placed and
> will be noticed?
> 
> This is a non-obvious dependency, and though Jay and Tony will remember
> now, there may be others in a few years who don't.
> 
> Olaf
> 
> Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:
> 
>> Before anybody fiddles with closure markers, *please* do *both* the  
>> following:
>>
>> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>>     (and it currently does.)  Changing them will break it, unless it is
>>     modified accordingly.
>>
>> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>>     the object code being debugged, whether it was generated by a
>>     compiler version that uses the old or the new closure marker
>>     representation.
>>
>> I have worked hard to make m3gdb able to adapt to the various compilers
>> and versions, but periodically I get undermined on 1) and/or 2) above
>> by some quiet change somebody makes without thinking about m3gdb.
>>
>> Also, think about the implications on linking together code produced
>> by different compiler versions.  I am quite sure changing the closure
>> representation would mean *all* linked-in libraries would have to be
>> recompiled, along with the main program, by the same compiler version.
>>
>> Right now, closure markers are always the same size as pointers, and I 
>> think
>> there are multiple places in the compiler and runtime, in addition to 
>> m3gdb,
>> that rely on this.  They would all have to be located and fixed.  And I
>> don't think they all key off any single declaration, e.g.  
>> closure_marker_size.
>>
>> Jay K wrote:
>>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>>> It isn't even in library code, but generated code.
>>>  - Jay
>>>
>>> ------------------------------------------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>>
>>> If we declare it as a 32-bit subrange it should just work, right?
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>>
>>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>>    from
>>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>>               That is: 64bit architectures with a fixed size 4 byte 
>>>  instruction
>>>    where alignment is checked
>>>
>>>          That is, we should probably make their be a per-target variable
>>>    "closure marker size"
>>>      that is 4 for all current targets (IA64 should probably be 16 
>>> though),
>>>      though one would have to look into the various instruction 
>>> encodings.
>>>
>>>
>>>     - Jay
>>>
>>>
> 
> 
> 


From Highjinks at gmx.com  Fri Jan 29 00:23:55 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 29 Jan 2010 00:23:55 +0100 (CET)
Subject: [M3devel] Which libraries to use?
Message-ID: <20100128192638.03b7590e.Highjinks@gmx.com>

Or better yet, should I just write my own.

Getting started writing bindings from the header files in ../include/X11/extensions

However, some of those depend on ../include/X11/Xmd.h and ../include/X11/Xfuncproto.h

Writing bindings for these probably shouldn't be necessary. However, I just want to make sure.

Does anyone forsee a problem if I just stick the values defined in the CM3 libs?
 
It's also looking fairly certain that I'm going to break off Xlib and XUtil into thier own .i3 files.

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 29 11:09:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 10:09:46 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W35838671ED7CF50D3D70D5E65B0@phx.gbl>


So I looked again -- how is floating point dealt with?
Well, it has its own stack. That helps here (even if it is otherwise lame).

 

 

The "easy" way would be to have M3x86.m3 

do stuff "directly", but each function would have

a little local array of __int64 that push/pop/add/sub/mult

used. It would be very inefficient but would work.

Passing parameters would pop from the local array

and push onto the machine stack. 

 

 

You can see this approach if you watch the

talk on the "XMLVM" where they implement Java for iPhone.

They disassemble .class files into a direct xml representation,

then use XSL style sheets to translate to Objective-C,

or JavaScript, or almost anything.

They give each function a little array to model the Java VM stack.

 

 

I'm still spinning on an efficient approach.

I can actually generate a *little* bit of correct reasonable

code, but not much yet.

Just 64bit moves of constants into variables.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Mon, 25 Jan 2010 11:14:57 +0000



 >> I think what I see now -- just use the machine stack.

I'm not sure this works so easily if you consider function calls.
  Taking a mix of LONGINT and non-LONGINT parameters.
 
There'd be a series of load_integer and pop_param calls.
Normally all the machine stack pushes are in pop_param.
Now they'd be in a mix of load_integer and pop_param.
If pop_param is called as each parameter is computed, ok.
If they are all computed and then all popped, not ok.
 
 
 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out. 




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/1c964751/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri Jan 29 15:32:50 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 29 Jan 2010 09:32:50 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
	<2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
Message-ID: <20100129143250.GA9515@topoi.pooq.com>

On Sun, Jan 24, 2010 at 05:38:30PM -0500, Tony Hosking wrote:
> But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

If the compiler can determine statically that an overflow will happen, 
and the overflow cause incorrect behaviour of the program, it just 
might be helpful to inform him.

But I wouldn't go so far as to say it's a problem.  It would be a 
problem for him to be unable to get overflow checking even if he's 
willing to pay the run-time cost.  But that wasn't what I was talking 
about.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> >> Agreed.  If we allow overflow at run-time we should at compile-time.
> > 
> > But perhaps a compile-time warning is in order for overflow -- in cases 
> > where we do the arithmetic at compile-time, anyway.  We may avoid 
> > run-time checks for speed reasons, but there's no such constraint 
> > on compile-time checks.
> > 
> > -- hendrik
> 


From hosking at cs.purdue.edu  Fri Jan 29 18:40:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 29 Jan 2010 12:40:51 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
Message-ID: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>

Note that the front-end refuses to do any constant folding that results in overflow.  Instead, it generates code that will execute at run-time.  If that causes a run-time error then fine.  Similarly, the back-end should never do constant folding for things that overflow.


On 29 Jan 2010, at 11:48, Jay K wrote:

> For now I'm treating the error as a warning and continuing on.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 29 Jan 2010 10:31:35 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Why do you need that?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/29 09:57:33
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.m3 
> 
> Log message:
> in ToInt and IntI, do the conversion even if there is overflow (still returning FALSE for overflow)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/389af581/attachment-0001.html>

From rodney_bates at lcwb.coop  Fri Jan 29 19:11:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 29 Jan 2010 12:11:39 -0600
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
Message-ID: <4B6324DB.7040809@lcwb.coop>



Tony Hosking wrote:
> Note that the front-end refuses to do any constant folding that results 
> in overflow.  Instead, it generates code that will execute at run-time. 
>  If that causes a run-time error then fine.  Similarly, the back-end 
> should never do constant folding for things that overflow.

Hmm, I didn't know that.  I think that is a very good idea.  It really
preserves language semantics, while gaining efficiency where possible.


> 
> On 29 Jan 2010, at 11:48, Jay K wrote:
> 
>> For now I'm treating the error as a warning and continuing on.
>>  
>>  - Jay
>>
>>  
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>> Date: Fri, 29 Jan 2010 10:31:35 -0500
>> To: jkrell at elego.de <mailto:jkrell at elego.de>
>> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> Why do you need that?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>> University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 29 Jan 2010, at 09:57, Jay Krell wrote:
>>
>>     CVSROOT: /usr/cvs
>>     Changes by: jkrell at birch. 10/01/29 09:57:33
>>
>>     Modified files:
>>     cm3/m3-sys/m3middle/src/: Target.m3 
>>
>>     Log message:
>>     in ToInt and IntI, do the conversion even if there is overflow
>>     (still returning FALSE for overflow)
>>
>>
>>
> 


From jay.krell at cornell.edu  Fri Jan 29 22:02:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 21:02:01 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <4B6324DB.7040809@lcwb.coop>
References: <20100129085733.63129CC308@birch.elegosoft.com>, ,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>,
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>,
	<4B6324DB.7040809@lcwb.coop>
Message-ID: <COL101-W63294B6BEEF06B0124FA1E65B0@phx.gbl>


There isn't really overflow here, just having trouble implementing longint.

For example 

  ToInt(FIRST(INTEGER) & MAXU32)) overflows, though it shouldn't matter.

 

 - Jay
 
> Date: Fri, 29 Jan 2010 12:11:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> 
> 
> Tony Hosking wrote:
> > Note that the front-end refuses to do any constant folding that results 
> > in overflow. Instead, it generates code that will execute at run-time. 
> > If that causes a run-time error then fine. Similarly, the back-end 
> > should never do constant folding for things that overflow.
> 
> Hmm, I didn't know that. I think that is a very good idea. It really
> preserves language semantics, while gaining efficiency where possible.
> 
> 
> > 
> > On 29 Jan 2010, at 11:48, Jay K wrote:
> > 
> >> For now I'm treating the error as a warning and continuing on.
> >> 
> >> - Jay
> >>
> >> 
> >> ------------------------------------------------------------------------
> >> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >> Date: Fri, 29 Jan 2010 10:31:35 -0500
> >> To: jkrell at elego.de <mailto:jkrell at elego.de>
> >> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
> >> Subject: Re: [M3commit] CVS Update: cm3
> >>
> >> Why do you need that?
> >>
> >> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >> University
> >> 305 N. University Street | West Lafayette | IN 47907 | USA
> >> Office +1 765 494 6001 | Mobile +1 765 427 5484
> >>
> >>
> >>
> >>
> >> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> >>
> >> CVSROOT: /usr/cvs
> >> Changes by: jkrell at birch. 10/01/29 09:57:33
> >>
> >> Modified files:
> >> cm3/m3-sys/m3middle/src/: Target.m3 
> >>
> >> Log message:
> >> in ToInt and IntI, do the conversion even if there is overflow
> >> (still returning FALSE for overflow)
> >>
> >>
> >>
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/6cdd7e37/attachment-0001.html>

From mbishop at esoteriq.org  Sun Jan 31 01:19:20 2010
From: mbishop at esoteriq.org (Martin Bishop)
Date: Sat, 30 Jan 2010 18:19:20 -0600
Subject: [M3devel] 5.8 Release?
Message-ID: <4B64CC88.6070409@esoteriq.org>

I don't want to be a buzz kill, but it's almost February 2010, and 5.8 
stable is still not out.  Are there still any issues left?  Anything 
that can be ignored until after release?




From hosking at cs.purdue.edu  Sun Jan 31 04:31:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 30 Jan 2010 22:31:18 -0500
Subject: [M3devel] 5.8 Release?
In-Reply-To: <4B64CC88.6070409@esoteriq.org>
References: <4B64CC88.6070409@esoteriq.org>
Message-ID: <E67ECCE2-26D3-4496-9417-3BD4494A8904@cs.purdue.edu>

Surely we are close.  What stability issues are there on the release branch?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 30 Jan 2010, at 19:19, Martin Bishop wrote:

> I don't want to be a buzz kill, but it's almost February 2010, and 5.8 stable is still not out.  Are there still any issues left?  Anything that can be ignored until after release?
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100130/4ba7fd3b/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 31 13:21:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:21:19 +0000
Subject: [M3devel] platform-independent packing/alignment?
Message-ID: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>


These are more potential ABI breaking changes.

Not sure if they'd break pickles or not.

 

 

I suggest we can probably get by with platform-independent packing/alignment settings.

Align everything by its size, up to 8. ?

That is increased alignment for LONGINT and LONGFLOAT on some systems.

  Which they probably should have been in the first place.

It would also increase alignment for obsolete M68K platforms.

 

 

I also suggest we need pragmas to declare something is packed/aligned

differently. But that might be avoided via C layers.

 

 

See, in mklib we have:

 

 

TYPE
  PIMAGE_SYMBOL = <* UNALIGNED *> UNTRACED REF IMAGE_SYMBOL;
  IMAGE_SYMBOL = RECORD
    N: ARRAY [0 .. 7] OF UINT8;
    Value              : UINT32;
    SectionNumber      : INT16;
    Type               : UINT16;
    StorageClass       : UINT8;
    NumberOfAuxSymbols : UINT8;
  END;

 

CONST
    IMAGE_SIZEOF_SYMBOL = 18;


 

But BYTESIZE(IMAGE_SYMBOL) is probably 20 on all platforms (except maybe M68K ones).

 

 

Then Target.Int8, etc. could be constants.

Maybe not worth anything.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/6b8cddf1/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 31 13:28:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?
Message-ID: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>


I'm seeing:

Just me?

I'll keep digging.

 

== package C:\dev2\cm3.2\m3-libs\m3core ==

 +++ 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

 

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/5cff08fc/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jan 31 13:37:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:37:23 +0000
Subject: [M3devel] errors compiling?
In-Reply-To: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
References: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
Message-ID: <COL101-W53FB7810A7679FB145A8E5E6590@phx.gbl>


nevermind, I fixed it

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?



I'm seeing:
Just me?
I'll keep digging.
 
== package C:\dev2\cm3.2\m3-libs\m3core ==
 +++ 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
 
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/7e06ff02/attachment-0001.html>

From dragisha at m3w.org  Sun Jan 31 17:29:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 17:29:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
Message-ID: <1264955387.4240.2.camel@faramir.m3w.org>

I've asked this before, but didn't catch answer:

On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> I suggest we can probably get by with platform-independent
> packing/alignment settings.

Some time ago I've used pickles (CM3) to save some data... My program
does not read that pickle anymore.... 

Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Sun Jan 31 19:59:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Jan 2010 13:59:53 -0500
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <C987DE66-5EF6-4581-817C-FBFA9986ACC0@cs.purdue.edu>

That should not be the case.  Any changes should have made for more capability rather than less.  Any chance you know what data type is not being read properly? 



On 31 Jan 2010, at 11:29, Dragi?a Duri? wrote:

> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 
> 
> Someone remembers moment when this incompatible changes were made? 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From rodney_bates at lcwb.coop  Sun Jan 31 21:00:08 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 31 Jan 2010 14:00:08 -0600
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <4B65E148.4090105@lcwb.coop>



Dragi?a Duri? wrote:
> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 

And you are certain your program that tries to read still contains
exact structurally equivalent types to all the types in the pickle?

> 
> Someone remembers moment when this incompatible changes were made? 


From dragisha at m3w.org  Sun Jan 31 22:14:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 22:14:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <4B65E148.4090105@lcwb.coop>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>
Message-ID: <1264972487.4240.4.camel@faramir.m3w.org>

I've not changed my code, that is for sure.... But now I am not sure
some parent type (esp MUTEX here an there) was not changed... I'll take
a look on this again sometime soon and report my findings.

Thanks for clues.

On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> 
> Dragi?a Duri? wrote:
> > I've asked this before, but didn't catch answer:
> > 
> > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> >> I suggest we can probably get by with platform-independent
> >> packing/alignment settings.
> > 
> > Some time ago I've used pickles (CM3) to save some data... My program
> > does not read that pickle anymore.... 
> 
> And you are certain your program that tries to read still contains
> exact structurally equivalent types to all the types in the pickle?
> 
> > 
> > Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Fri Jan  1 21:30:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 15:30:42 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
Message-ID: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>

What does -C do?

On 29 Dec 2009, at 12:47, Olaf Wagner wrote:

> Any ideas? Interaction problem between threads and select?
> 
> Olaf
> 
> ----- Forwarded message from bugs at elego.de -----
>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>    From: CM3 <bugs at elego.de>
> Reply-To: CM3 <bugs at elego.de>
> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>      To: @MISSING_DOMAIN
> 
> #1080: CVSUPD server hangs if used with -C option
> -----------------------------+----------------------------------------------
>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>      Type:  sw-bug          |           Status:  new
>  Priority:  high            |        Milestone:
> Component:  sys             |          Version:  5.8-RC3
>  Severity:  critical        |         Keywords:
>   Relnote:                  |     Confidential:  no
>       Org:  Collabnet       |   Estimatedhours:  0
>     Hours:  0               |         Billable:  0
> Totalhours:  0               |
> -----------------------------+----------------------------------------------
> Htr:
> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
> 
> Start the cvsupd server with -C option
> 
> ./cvsupd -b /data/cvsupd -C 2
> 
> Try cvsup client to connect to the sever
> 
> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> 
> The client connection will hang and after sometime we will get "Inactivity timeout"
> 
> 
> Fix:
> 
> 
> 
> Env:
> 
> 
> -----------------------------+----------------------------------------------
> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
> cvsup installed.
> 
> The server starts find and there was no issues if I start the server
> without -C option.
> 
> Starting cvsupd server without -C option
> 
> $ ./cvsupd -b /u2/site/data/cvsupd
> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> 
> Then I did a client request as below
> 
> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> Parsing supfile "/tmp/cvsupd.cfg"
> Connecting to myserver.com
> Connected to myserver.com
> Rejected by server: Access denied
> Will retry at 21:37:09
> 
> So the request was successful and I get a valid error message at the
> client.
> 
> But when I start the server with -C option like the one as below, requests
> from client are hanging and eventually getting "Inactivity timeout" after
> sometime.
> 
> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> 
> When ever a new client connection was made, this daemon clones another
> cvsupd process and it also hangs. So none of the client request were
> processed.
> 
> Strace of the main cvsupd server process, when a new client request was
> fired.
> 
> -----------------------------------
> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> gettimeofday({1262103026, 146476}, NULL) = 0
> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> _llseek(7, 0, [0], SEEK_CUR)            = 0
> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> close(7)                                = 0
> gettimeofday({1262103026, 147481}, NULL) = 0
> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
> such file or directory)
> write(5, "\0", 1)                       = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0xb7f43708) = 6543
> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
> unavailable)
> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> close(6)                                = 0
> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
> unavailable)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> 
> ------------------------------------
> 
> gdb backtrace of the main cvsupd server process
> 
> ------------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> ../src/unix/Common/UnixC.c:301
> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
> M3_A4bqCj_timeout=0xbfed9410) at
> ../src/thread/PTHREAD/ThreadPThread.m3:900
> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> ../src/thread/PTHREAD/ThreadPThread.m3:854
> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:153
> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> ------------------------------------------------
> 
> 
> strace of the cloned cvsupd process
> 
> -----------------------------------
> 
> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> 
> -----------------------------------
> 
> gdb backtrace of the cloned cvsupd process
> 
> -----------------------------------
> 
> #0  0x00a2a402 in __kernel_vsyscall ()
> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/libpthread.so.0
> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> ../src/FSServer.m3:231
> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> ../src/FSServer.m3:227
> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:399
> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> ../src/runtime/common/RTLinker.m3:113
> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> ../src/runtime/common/RTLinker.m3:122
> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> _m3main.mc:4
> 
> -------------------------------------------
> 
> So it looks like both the main and cloned cvsupd processes were waiting
> for a response from the kernel call "__kernel_vsyscall ()". Under what
> condition will this happen? Am I doing something wrong here?
> 
> -- 
> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> CM3 <http://projects.elego.de/cm3>
> Critical Mass Modula3 Compiler
> 
> 
> ----- End forwarded message -----
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From jay.krell at cornell.edu  Fri Jan  1 23:56:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 22:56:00 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
Message-ID: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>


I can understand that the name on the left isn't in scope "yet" on the right,
but what is the algorithm for anyone else using IMPORT?


import foo;
import foo(bar);
import foo(bar) as foobar;
import foo(bar).T as fooT;


I doubt all but the first of these are legal, but I also don't think they are very far fetched
in terms of being reasonable constructs and not difficult to implement.


And I'm not sure the presence of the '(' is enough disambiguation for a quick human reader
or a pleasantly simply enough implementation, but maybe.


All that is to say, I don't think disallowing interface foo = foo(bar) is so bad.


 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 1 Jan 2010 14:43:36 -0500
To: jkrell at elego.de
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3



That's a bug in m3tk scope management.  Probably needs a ticket in the bugs database...


On 30 Dec 2009, at 15:40, Jay Krell wrote:CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/12/30 15:40:06

Modified files:
	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3 
	                              m3makefile 
Added files:
	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg 
Removed files:
	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg 

Log message:
	go back to GenWord
	the other front end (Olivetti m3-tk)
	doesn't understand
	INTERFACE Word = Word(WordRep) END Word.
	but it does't understand
	INTERFACE Word = GenWord(WordRep) END Word.

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

From mika at async.async.caltech.edu  Sat Jan  2 00:02:23 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 01 Jan 2010 15:02:23 -0800
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <COL101-W50EF463F51810CE4748AF8E6770@phx.gbl> 
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
Message-ID: <20100101230223.355441A2080@async.async.caltech.edu>

Jay K writes:
...
>
>import foo=3B
>import foo(bar)=3B
>import foo(bar) as foobar=3B
>import foo(bar).T as fooT=3B

Modula-3 doesn't work like that.

You have to say

INTERFACE X = G(Y) ...

IMPORT X

You can't import "G(Y)" directly.  Saves having to worry too much about
name mangling.

Having a generic interface and a normal one with the same name is a common
pattern for me, at least.

You often have a single supertype and then many subtypes that are related
to that supertype by being extended with, say, a field of an arbitrary type.

Then you get...

INTERFACE Stuff; TYPE T ... END Stuff.

GENERIC INTERFACE Stuff(Specializing);
IMPORT Stuff;
TYPE T = Stuff.T OBJECT special : Specializing.T END;
END Stuff.

INTERFACE SpecialStuff = Stuff(Special)

Very convenient to use the same name at the top level, I think.

    Mika

>
>
>I doubt all but the first of these are legal=2C but I also don't think they=
> are very far fetched
>in terms of being reasonable constructs and not difficult to implement.
>
>
>And I'm not sure the presence of the '(' is enough disambiguation for a qui=
>ck human reader
>or a pleasantly simply enough implementation=2C but maybe.
>
>
>All that is to say=2C I don't think disallowing interface foo =3D foo(bar) =
>is so bad.
>
>
> - Jay
>
>From: hosking at cs.purdue.edu
>Date: Fri=2C 1 Jan 2010 14:43:36 -0500
>To: jkrell at elego.de
>CC: m3commit at elegosoft.com
>Subject: Re: [M3commit] CVS Update: cm3
>
>
>
>That's a bug in m3tk scope management.  Probably needs a ticket in the bugs=
> database...
>
>
>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:CVSROOT:	/usr/cvs
>Changes by:	jkrell at birch.	09/12/30 15:40:06
>
>Modified files:
>	cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 Word.i3 Word.m3=20
>	                              m3makefile=20
>Added files:
>	cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg=20
>Removed files:
>	cm3/m3-libs/m3core/src/word/: Word.ig Word.mg=20
>
>Log message:
>	go back to GenWord
>	the other front end (Olivetti m3-tk)
>	doesn't understand
>	INTERFACE Word =3D Word(WordRep) END Word.
>	but it does't understand
>	INTERFACE Word =3D GenWord(WordRep) END Word.
>
> 		 	   		  =
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I can understand that the name on the left isn't in scope "yet" on the righ=
>t=2C<br>but what is the algorithm for anyone else using IMPORT?<br><br><br>=
>import foo=3B<br>import foo(bar)=3B<br>import foo(bar) as foobar=3B<br>impo=
>rt foo(bar).T as fooT=3B<br><br><br>I doubt all but the first of these are =
>legal=2C but I also don't think they are very far fetched<br>in terms of be=
>ing reasonable constructs and not difficult to implement.<br><br><br>And I'=
>m not sure the presence of the '(' is enough disambiguation for a quick hum=
>an reader<br>or a pleasantly simply enough implementation=2C but maybe.<br>=
><br><br>All that is to say=2C I don't think disallowing interface foo =3D f=
>oo(bar) is so bad.<br><br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">=
>From: hosking at cs.purdue.edu<br>Date: Fri=2C 1 Jan 2010 14:43:36 -0500<br>To=
>: jkrell at elego.de<br>CC: m3commit at elegosoft.com<br>Subject: Re: [M3commit] =
>CVS Update: cm3<br><br>
>
><div><span class=3D"ecxApple-style-span" style=3D"border-collapse: separate=
>=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B=
> font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette=
>r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf=
>orm: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ec=
>xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=
>=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><div style=3D"word-wrap: break-wor=
>d=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: separat=
>e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=
>=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le=
>tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra=
>nsform: none=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D=
>"ecxApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C=
> 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=
>=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=
>=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit=
>e-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span=
>" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam=
>ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no=
>rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma=
>l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor=
>d-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-coll=
>apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font=
>-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n=
>ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px=
>=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"><s=
>pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col=
>or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s=
>tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci=
>ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no=
>ne=3B white-space: normal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-=
>style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=
>=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font=
>-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h=
>eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n=
>ormal=3B word-spacing: 0px=3B"><span class=3D"ecxApple-style-span" style=3D=
>"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve=
>tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo=
>nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-=
>indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:=
> 0px=3B"><span class=3D"ecxApple-style-span" style=3D"border-collapse: sepa=
>rate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12p=
>x=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l=
>etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr=
>ansform: none=3B white-space: normal=3B word-spacing: 0px=3B"><div><span cl=
>ass=3D"ecxApple-style-span" style=3D"font-size: medium=3B"><font class=3D"e=
>cxApple-style-span" color=3D"#0000ff" face=3D"'Gill Sans'">That's a bug in =
>m3tk scope management. &nbsp=3BProbably needs a ticket in the bugs database=
>...</font></span></div></span></span></span></span></span></span></span></s=
>pan></div></span></span>
></div>
><br><div><div>On 30 Dec 2009=2C at 15:40=2C Jay Krell wrote:</div><br class=
>=3D"ecxApple-interchange-newline"><blockquote><div>CVSROOT:<span class=3D"e=
>cxApple-tab-span" style=3D"white-space: pre=3B">	</span>/usr/cvs<br>Changes=
> by:<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span=
>>jkrell at birch.<span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>09/12/30 15:40:06<br><br>Modified files:<br><span class=3D"ecx=
>Apple-tab-span" style=3D"white-space: pre=3B">	</span>cm3/m3-libs/m3core/sr=
>c/word/: Long.i3 Long.m3 Word.i3 Word.m3 <br><span class=3D"ecxApple-tab-sp=
>an" style=3D"white-space: pre=3B">	</span> &nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
>sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
>=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3Bm3makefile <br>Added fil=
>es:<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</s=
>pan>cm3/m3-libs/m3core/src/word/: GenWord.ig GenWord.mg <br>Removed files:<=
>br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>=
>cm3/m3-libs/m3core/src/word/: Word.ig Word.mg <br><br>Log message:<br><span=
> class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>go back =
>to GenWord<br><span class=3D"ecxApple-tab-span" style=3D"white-space: pre=
>=3B">	</span>the other front end (Olivetti m3-tk)<br><span class=3D"ecxAppl=
>e-tab-span" style=3D"white-space: pre=3B">	</span>doesn't understand<br><sp=
>an class=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERF=
>ACE Word =3D Word(WordRep) END Word.<br><span class=3D"ecxApple-tab-span" s=
>tyle=3D"white-space: pre=3B">	</span>but it does't understand<br><span clas=
>s=3D"ecxApple-tab-span" style=3D"white-space: pre=3B">	</span>INTERFACE Wor=
>d =3D GenWord(WordRep) END Word.<br></div></blockquote></div><br> 		 	   		=
>  </body>
></html>=
>
>--_3ac6c68d-ca6e-4c55-9f4d-89e33c42a8f7_--


From jay.krell at cornell.edu  Sat Jan  2 00:05:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Jan 2010 23:05:44 +0000
Subject: [M3devel] C generating back end
Message-ID: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>


Fyi I finally looked at the 2.x implementation and the outputing of
C was implemented fairly directly at the m3front layer.
There wasn't the "M3CG" stuff.


Thus, the "easiest" way to get back such functionality would
probably be to "interleave" the old code and the new code within m3front.


The "cleaner" way is probably to implement a new M3CG though and
leave m3front unchanged.


I still think generating portable C a great way to achieve portability.
Better yet maybe, generate C++ and use its exception handling feature.
(ok, maybe generate both, in case some systems lack C++ support)


I realize there are several ways to view this though.

  gcc backend provides enough portability 
     imagine IA64_NT though. or Plan9. or even OpenBSD 
      or Darwin where there are long standing forks 
      (The OpenBSD patches are small and we carry/apply them.
      The Apple changes I think are mainly in the frontends
      which I think is how we get by.) 

     For efficient exception handling we should be able to use libunwind on most targets. 

  llvm would provide good portability and maybe other benefits like perf 
     less reach than gcc but hits the major platforms 
     difficult for me to get started with sorry 

  integrated backend could/should be ported around and is fast 
     a lot of work 
     I think the first steps here are to learn about mach-o and elf file formats
       as part of ports for other x86 targets. I've started a macho-dumper. 

  burg or others 

 - Jay

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

From hosking at cs.purdue.edu  Sat Jan  2 00:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Jan 2010 18:42:34 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
Message-ID: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>

On 1 Jan 2010, at 18:05, Jay K wrote:

> Fyi I finally looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such functionality would
> probably be to "interleave" the old code and the new code within m3front.

I'd like to avoid that sort of interleaving.

> The "cleaner" way is probably to implement a new M3CG though and
> leave m3front unchanged.

This is a much better plan.

> I still think generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception handling feature.
> (ok, maybe generate both, in case some systems lack C++ support)

We can use the gcc-backend exception handling support if anyone was prepared to work on it.

>  realize there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9. or even OpenBSD 
>       or Darwin where there are long standing forks 
>       (The OpenBSD patches are small and we carry/apply them.
>       The Apple changes I think are mainly in the frontends
>       which I think is how we get by.) 
> 
>      For efficient exception handling we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other benefits like perf 
>      less reach than gcc but hits the major platforms 
>      difficult for me to get started with sorry 
> 
>   integrated backend could/should be ported around and is fast 
>      a lot of work 
>      I think the first steps here are to learn about mach-o and elf file formats
>        as part of ports for other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 

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

From dabenavidesd at yahoo.es  Sat Jan  2 02:27:55 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 2 Jan 2010 01:27:55 +0000 (GMT)
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <694151.75147.qm@web23608.mail.ird.yahoo.com>

Hi all:
Olivetti had the the original development environment written with a C generating backend written in C for different operating system machines, they intended to realease it fully (probably it was) but performance showed was inferior to that of SRC environment at the time 2.x (Modula-3 to C written in Modula-3), which led to include Olivetti front end part as a library front end being part of the SRC distribution, later to deploy Network Objects high level intermediate code network logical layer.
Having a C backend this days wouldn't make sense if it was actually developed at some point, and up to a Professor remembers RMS wanted this to be donated to FSF so it could led to some sort to GPLed system, but there wasn't such a donation or haven't been done yet and it probably was related to the performance comparison (in the time of Olivetti and SRC 2.x systems) reason mentioned by Mick Jordan (see http://compilers.iecc.com/comparch/article/90-08-046 ) and later to M3CG (due SRC Modula-2+ system low level intermediate code) interface which has proven to be a good compromise between portability and performance.
If we could prove that Olivetti backend could be a plus in terms of M3 performance and portability to get it back and compare its actual performance with nowadays M3CG backend performance then this would have a point

Hope it helps, thanks in advance 
 

--- El vie, 1/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] C generating back end
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 1 de enero, 2010 18:42
> On 1 Jan
> 2010, at 18:05, Jay K
> wrote:
> Fyi I finally
> looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such
> functionality would
> probably be to "interleave" the old code and the
> new code within m3front.
> 
> I'd like to avoid that sort of
> interleaving.
> The
> "cleaner" way is probably to implement a new M3CG
> though and
> leave m3front unchanged.
> 
> This is a much better plan.
> I still think
> generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception
> handling feature.
> (ok, maybe generate both, in case some systems lack C++
> support)
> 
> We can use the gcc-backend exception handling
> support if anyone was prepared to work on it.
>  realize
> there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9.
> or even OpenBSD 
>       or Darwin where there are
> long standing forks 
>       (The OpenBSD patches are
> small and we carry/apply them.
>       The Apple changes I think
> are mainly in the frontends
>       which I think is how we get
> by.) 
> 
>      For efficient exception handling
> we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other
> benefits like perf 
>      less reach than gcc but hits the
> major platforms 
>      difficult for me to get started
> with sorry 
> 
>   integrated backend could/should be ported around and
> is fast 
>      a lot of work 
>      I think the first steps here are
> to learn about mach-o and elf file formats
>        as part of ports for
> other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 
> 
> 


      


From wagner at elegosoft.com  Sat Jan  2 11:54:06 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 02 Jan 2010 11:54:06 +0100
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with	-C
	option
In-Reply-To: <726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
Message-ID: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> What does -C do?

Make it a server process. From the manual:

      -C maxClients
                  Limits the number of simultaneous clients to maxClients.
                  Clients beyond the specified maximum are politely refused
                  service.

                  If this option is not specified, cvsupd serves one client in
                  the foreground and then exits.

Olaf

> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>
>> Any ideas? Interaction problem between threads and select?
>>
>> Olaf
>>
>> ----- Forwarded message from bugs at elego.de -----
>>    Date: Tue, 29 Dec 2009 16:23:23 -0000
>>    From: CM3 <bugs at elego.de>
>> Reply-To: CM3 <bugs at elego.de>
>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>      To: @MISSING_DOMAIN
>>
>> #1080: CVSUPD server hangs if used with -C option
>> -----------------------------+----------------------------------------------
>>  Reporter:  rajeshvadivelu  |            Owner:  wagner
>>      Type:  sw-bug          |           Status:  new
>>  Priority:  high            |        Milestone:
>> Component:  sys             |          Version:  5.8-RC3
>>  Severity:  critical        |         Keywords:
>>   Relnote:                  |     Confidential:  no
>>       Org:  Collabnet       |   Estimatedhours:  0
>>     Hours:  0               |         Billable:  0
>> Totalhours:  0               |
>> -----------------------------+----------------------------------------------
>> Htr:
>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz package.
>>
>> Start the cvsupd server with -C option
>>
>> ./cvsupd -b /data/cvsupd -C 2
>>
>> Try cvsup client to connect to the sever
>>
>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>
>> The client connection will hang and after sometime we will get   
>> "Inactivity timeout"
>>
>>
>> Fix:
>>
>>
>>
>> Env:
>>
>>
>> -----------------------------+----------------------------------------------
>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror my cvs
>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get the
>> cvsup installed.
>>
>> The server starts find and there was no issues if I start the server
>> without -C option.
>>
>> Starting cvsupd server without -C option
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd
>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30 21:02:46
>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>
>> Then I did a client request as below
>>
>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>> Parsing supfile "/tmp/cvsupd.cfg"
>> Connecting to myserver.com
>> Connected to myserver.com
>> Rejected by server: Access denied
>> Will retry at 21:37:09
>>
>> So the request was successful and I get a valid error message at the
>> client.
>>
>> But when I start the server with -C option like the one as below, requests
>> from client are hanging and eventually getting "Inactivity timeout" after
>> sometime.
>>
>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>
>> When ever a new client connection was made, this daemon clones another
>> cvsupd process and it also hangs. So none of the client request were
>> processed.
>>
>> Strace of the main cvsupd server process, when a new client request was
>> fired.
>>
>> -----------------------------------
>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0, 553000})
>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>> gettimeofday({1262103026, 146476}, NULL) = 0
>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>> close(7)                                = 0
>> gettimeofday({1262103026, 147481}, NULL) = 0
>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1 ENOENT (No
>> such file or directory)
>> write(5, "\0", 1)                       = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> clone(child_stack=0,
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> child_tidptr=0xb7f43708) = 6543
>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource temporarily
>> unavailable)
>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>> close(6)                                = 0
>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource temporarily
>> unavailable)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>
>> ------------------------------------
>>
>> gdb backtrace of the main cvsupd server process
>>
>> ------------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>> ../src/unix/Common/UnixC.c:301
>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779 (M3_Cwb5VA_nfd=4,
>> M3_A4bqCj_timeout=0xbfed9410) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001')
>>     at ../src/thread/PTHREAD/ThreadPThread.m3:936
>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:153
>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>> ------------------------------------------------
>>
>>
>> strace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>
>> -----------------------------------
>>
>> gdb backtrace of the cloned cvsupd process
>>
>> -----------------------------------
>>
>> #0  0x00a2a402 in __kernel_vsyscall ()
>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>> /lib/libpthread.so.0
>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4, M3_AicXUJ_alertable=0
>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ThreadPThread.m3:280
>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/SigHandler.m3:243
>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>> ../src/FSServer.m3:231
>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>> ../src/FSServer.m3:227
>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:399
>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>> ../src/runtime/common/RTLinker.m3:113
>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>> ../src/runtime/common/RTLinker.m3:122
>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>> _m3main.mc:4
>>
>> -------------------------------------------
>>
>> So it looks like both the main and cloned cvsupd processes were waiting
>> for a response from the kernel call "__kernel_vsyscall ()". Under what
>> condition will this happen? Am I doing something wrong here?
>>
>> --
>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>> CM3 <http://projects.elego.de/cm3>
>> Critical Mass Modula3 Compiler
>>
>>
>> ----- End forwarded message -----
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Sat Jan  2 18:20:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:20:04 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F8044.2080403@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 
> Having a generic interface and a normal one with the same name is a common
> pattern for me, at least.
> 
> You often have a single supertype and then many subtypes that are related
> to that supertype by being extended with, say, a field of an arbitrary type.
> 
> Then you get...
> 
> INTERFACE Stuff; TYPE T ... END Stuff.
> 
> GENERIC INTERFACE Stuff(Specializing);
> IMPORT Stuff;
> TYPE T = Stuff.T OBJECT special : Specializing.T END;
> END Stuff.
> 
> INTERFACE SpecialStuff = Stuff(Special)
> 
> Very convenient to use the same name at the top level, I think.
> 
>     Mika

Yuck! I hate this.  One of the things I really hate about Java and C++ is
having many different ways in which a reference to an identifier is looked
up, depending on the context of the reference.  This is one of the big ways
a language gets obscenely overcomplicated without providing any useful benefits.

One of Modula-3's strengths is that when an unqualified identifier is
referenced, it is always looked up according to the same rules, no matter
what kind of thing it is.  Only afterwards are semantic rules applied like,
e.g., the context requires a type but the identifier is a constant.

Except for this example, which I had missed up until now.  IMPORT Stuff
(and also EXPORTS Stuff) looks up Stuff as a global name in a different
way from INTERFACE SpecialStuff = Stuff(Special).  Unfortunately, the language
fails to address this at all in 2.5.5, and the implementation managed to
get away with violating the principle.  So now we have a bit of a slip into
the evil world of junk programming languages.

As for its being convenient, it may save a bit of effort during the initial
coding phase, by not requiring you to think up distinct names, but it is a
cruel and inhuman punishment to inflict on the miserable but innocent wretch who
has to maintain  your code later.  And in just case someone needs to be reminded,
coding is short.  Maintenance is long, sometimes almost forever.

We really should amend the language to say that ordinary and generic interfaces
combined must all have distinct global names.  Likewise for ordinary and
generic modules.

> 


From rodney_bates at lcwb.coop  Sat Jan  2 18:42:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 02 Jan 2010 11:42:34 -0600
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <20100101230223.355441A2080@async.async.caltech.edu>
References: <20091230144007.081152474001@birch.elegosoft.com>,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>
	<20100101230223.355441A2080@async.async.caltech.edu>
Message-ID: <4B3F858A.8070001@lcwb.coop>



Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 

On a separate issue, one of the things that the C++ template facility really
botched badly is that instantiations not only can be, but must be, anonymous.
So every single time you want to refer to it, you have to repeat the template
actuals list.  It makes for some very ponderous and confusing code to read,
especially if there are multiple instantiations involved.  It also makes the
semantic analysis unnecessarily difficult for both the human reader and compiler.

In Modula-3 an instantiation must be done once, giving it a simple name, with
the name used thereafter everywhere the instantiation is referred-to.


From jay.krell at cornell.edu  Sat Jan  2 20:18:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 19:18:58 +0000
Subject: [M3devel] scope/resolution of foo in interface foo = foo(bar)
In-Reply-To: <4B3F858A.8070001@lcwb.coop>
References: <20091230144007.081152474001@birch.elegosoft.com>, ,
	<21B2F22D-C1E9-46F2-8434-4CD78DCD7E96@cs.purdue.edu>
	<COL101-W50EF463F51810CE4748AF8E6770@phx.gbl>,
	<20100101230223.355441A2080@async.async.caltech.edu>,
	<4B3F858A.8070001@lcwb.coop>
Message-ID: <COL101-W2278F183A7D8B3C0574A73E6760@phx.gbl>


> Date: Sat, 2 Jan 2010 11:42:34 -0600
> From: rodney
> On a separate issue, one of the things that the C++ template facility really
> botched badly is that instantiations not only can be, but must be, anonymous.


Can be, but not must be.


for types:
  typedef vector<int> vi_t.


for functions, well, usually the parameters are deduced and you
don't have to say them:


template <typename T> T max(const T& a, const T& b)
{
  return (a > b ? a : b);
}


max(1, 2);


If you have something like:


template <typename T> T* New() { return new T(); }

then you do have to say New<Foo>().
You could do something onerous like:
Foo* (*const NewFoo)() = New<T>;


There is a new feature that might enable:


const auto NewFoo = New<T>;



but really, deduction of function template parameters is a very good thing,
no need to fight it, and making the parameters explicit
for some scenarios is not so bad.


There are some very confusing things about templates:
  How much can be checked without instantiation?
  Which names are bound at template definition vs. instantiation?
  Can "template metaprogramming" be done in a more direct way instead
    of seemingly just being an accident?


And (with reverse spin) there are some very powerful things you can do with templates:
   template meta programming :) 
   very good levels of inlining where otherwise you'd have little choice but to use
     function pointers and have poor efficiency (though, not that you can't 
     implement things easily enough and have them at least work without templates)
   not sure the term, but have you seen how in C++ you can write:
     a = b + c + d + e;


where the types involves are vectors/matrices and it compiles down
to have no temporary vectors/matrices.


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

From hosking at cs.purdue.edu  Sat Jan  2 20:35:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 2 Jan 2010 13:35:59 -0600
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>
Message-ID: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>

So, what's changed recently to break this?  It must have been working  
relatively recently.

Sent from my iPhone

On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> What does -C do?
>
> Make it a server process. From the manual:
>
>     -C maxClients
>                 Limits the number of simultaneous clients to  
> maxClients.
>                 Clients beyond the specified maximum are politely  
> refused
>                 service.
>
>                 If this option is not specified, cvsupd serves one  
> client in
>                 the foreground and then exits.
>
> Olaf
>
>> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
>>
>>> Any ideas? Interaction problem between threads and select?
>>>
>>> Olaf
>>>
>>> ----- Forwarded message from bugs at elego.de -----
>>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
>>>   From: CM3 <bugs at elego.de>
>>> Reply-To: CM3 <bugs at elego.de>
>>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
>>>     To: @MISSING_DOMAIN
>>>
>>> #1080: CVSUPD server hangs if used with -C option
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Reporter:  rajeshvadivelu  |            Owner:  wagner
>>>     Type:  sw-bug          |           Status:  new
>>> Priority:  high            |        Milestone:
>>> Component:  sys             |          Version:  5.8-RC3
>>> Severity:  critical        |         Keywords:
>>>  Relnote:                  |     Confidential:  no
>>>      Org:  Collabnet       |   Estimatedhours:  0
>>>    Hours:  0               |         Billable:  0
>>> Totalhours:  0               |
>>> ----------------------------- 
>>> +----------------------------------------------
>>> Htr:
>>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
>>> package.
>>>
>>> Start the cvsupd server with -C option
>>>
>>> ./cvsupd -b /data/cvsupd -C 2
>>>
>>> Try cvsup client to connect to the sever
>>>
>>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>>
>>> The client connection will hang and after sometime we will get   
>>> "Inactivity timeout"
>>>
>>>
>>> Fix:
>>>
>>>
>>>
>>> Env:
>>>
>>>
>>> ----------------------------- 
>>> +----------------------------------------------
>>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
>>> my cvs
>>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
>>> the
>>> cvsup installed.
>>>
>>> The server starts find and there was no issues if I start the server
>>> without -C option.
>>>
>>> Starting cvsupd server without -C option
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd
>>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
>>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
>>> 21:02:46
>>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
>>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
>>>
>>> Then I did a client request as below
>>>
>>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
>>> Parsing supfile "/tmp/cvsupd.cfg"
>>> Connecting to myserver.com
>>> Connected to myserver.com
>>> Rejected by server: Access denied
>>> Will retry at 21:37:09
>>>
>>> So the request was successful and I get a valid error message at the
>>> client.
>>>
>>> But when I start the server with -C option like the one as below,  
>>> requests
>>> from client are hanging and eventually getting "Inactivity  
>>> timeout" after
>>> sometime.
>>>
>>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
>>>
>>> When ever a new client connection was made, this daemon clones  
>>> another
>>> cvsupd process and it also hangs. So none of the client request were
>>> processed.
>>>
>>> Strace of the main cvsupd server process, when a new client  
>>> request was
>>> fired.
>>>
>>> -----------------------------------
>>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
>>> 553000})
>>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
>>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
>>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
>>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
>>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>>> gettimeofday({1262103026, 146476}, NULL) = 0
>>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> _llseek(7, 0, [0], SEEK_CUR)            = 0
>>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
>>> close(7)                                = 0
>>> gettimeofday({1262103026, 147481}, NULL) = 0
>>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
>>> ENOENT (No
>>> such file or directory)
>>> write(5, "\0", 1)                       = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> clone(child_stack=0,
>>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>>> child_tidptr=0xb7f43708) = 6543
>>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
>>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
>>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
>>> close(6)                                = 0
>>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
>>> temporarily
>>> unavailable)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
>>>
>>> ------------------------------------
>>>
>>> gdb backtrace of the main cvsupd server process
>>>
>>> ------------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
>>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
>>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
>>> ../src/unix/Common/UnixC.c:301
>>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
>>> (M3_Cwb5VA_nfd=4,
>>> M3_A4bqCj_timeout=0xbfed9410) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:900
>>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
>>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
>>> '\001')
>>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
>>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
>>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
>>> ../src/thread/PTHREAD/ThreadPThread.m3:854
>>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
>>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
>>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:153
>>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>> ------------------------------------------------
>>>
>>>
>>> strace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
>>>
>>> -----------------------------------
>>>
>>> gdb backtrace of the cloned cvsupd process
>>>
>>> -----------------------------------
>>>
>>> #0  0x00a2a402 in __kernel_vsyscall ()
>>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
>>> /lib/libpthread.so.0
>>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
>>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
>>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
>>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
>>> M3_AicXUJ_alertable=0
>>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
>>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
>>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
>>> ThreadPThread.m3:280
>>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
>>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
>>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
>>> SigHandler.m3:243
>>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
>>> ../src/FSServer.m3:231
>>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
>>> ../src/FSServer.m3:227
>>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
>>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:399
>>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
>>> ../src/runtime/common/RTLinker.m3:113
>>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
>>> ../src/runtime/common/RTLinker.m3:122
>>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
>>> _m3main.mc:4
>>>
>>> -------------------------------------------
>>>
>>> So it looks like both the main and cloned cvsupd processes were  
>>> waiting
>>> for a response from the kernel call "__kernel_vsyscall ()". Under  
>>> what
>>> condition will this happen? Am I doing something wrong here?
>>>
>>> --
>>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
>>> CM3 <http://projects.elego.de/cm3>
>>> Critical Mass Modula3 Compiler
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>>
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
>>> ermany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
>>>  Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> any
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> rlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>


From jay.krell at cornell.edu  Sat Jan  2 22:42:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 2 Jan 2010 21:42:22 +0000
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with
	-C	option
In-Reply-To: <8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
Message-ID: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>


 > It must have been working relatively recently.

This is probably the first time it has been tested since getting into our tree.

 - Jay

> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Sat, 2 Jan 2010 13:35:59 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C	option
> 
> So, what's changed recently to break this?  It must have been working  
> relatively recently.
> 
> Sent from my iPhone
> 
> On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> >
> >> What does -C do?
> >
> > Make it a server process. From the manual:
> >
> >     -C maxClients
> >                 Limits the number of simultaneous clients to  
> > maxClients.
> >                 Clients beyond the specified maximum are politely  
> > refused
> >                 service.
> >
> >                 If this option is not specified, cvsupd serves one  
> > client in
> >                 the foreground and then exits.
> >
> > Olaf
> >
> >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> >>
> >>> Any ideas? Interaction problem between threads and select?
> >>>
> >>> Olaf
> >>>
> >>> ----- Forwarded message from bugs at elego.de -----
> >>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
> >>>   From: CM3 <bugs at elego.de>
> >>> Reply-To: CM3 <bugs at elego.de>
> >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> >>>     To: @MISSING_DOMAIN
> >>>
> >>> #1080: CVSUPD server hangs if used with -C option
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Reporter:  rajeshvadivelu  |            Owner:  wagner
> >>>     Type:  sw-bug          |           Status:  new
> >>> Priority:  high            |        Milestone:
> >>> Component:  sys             |          Version:  5.8-RC3
> >>> Severity:  critical        |         Keywords:
> >>>  Relnote:                  |     Confidential:  no
> >>>      Org:  Collabnet       |   Estimatedhours:  0
> >>>    Hours:  0               |         Billable:  0
> >>> Totalhours:  0               |
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Htr:
> >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
> >>> package.
> >>>
> >>> Start the cvsupd server with -C option
> >>>
> >>> ./cvsupd -b /data/cvsupd -C 2
> >>>
> >>> Try cvsup client to connect to the sever
> >>>
> >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>>
> >>> The client connection will hang and after sometime we will get   
> >>> "Inactivity timeout"
> >>>
> >>>
> >>> Fix:
> >>>
> >>>
> >>>
> >>> Env:
> >>>
> >>>
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
> >>> my cvs
> >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
> >>> the
> >>> cvsup installed.
> >>>
> >>> The server starts find and there was no issues if I start the server
> >>> without -C option.
> >>>
> >>> Starting cvsupd server without -C option
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd
> >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
> >>> 21:02:46
> >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> >>>
> >>> Then I did a client request as below
> >>>
> >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>> Parsing supfile "/tmp/cvsupd.cfg"
> >>> Connecting to myserver.com
> >>> Connected to myserver.com
> >>> Rejected by server: Access denied
> >>> Will retry at 21:37:09
> >>>
> >>> So the request was successful and I get a valid error message at the
> >>> client.
> >>>
> >>> But when I start the server with -C option like the one as below,  
> >>> requests
> >>> from client are hanging and eventually getting "Inactivity  
> >>> timeout" after
> >>> sometime.
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> >>>
> >>> When ever a new client connection was made, this daemon clones  
> >>> another
> >>> cvsupd process and it also hangs. So none of the client request were
> >>> processed.
> >>>
> >>> Strace of the main cvsupd server process, when a new client  
> >>> request was
> >>> fired.
> >>>
> >>> -----------------------------------
> >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
> >>> 553000})
> >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> >>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> >>> gettimeofday({1262103026, 146476}, NULL) = 0
> >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> _llseek(7, 0, [0], SEEK_CUR)            = 0
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> close(7)                                = 0
> >>> gettimeofday({1262103026, 147481}, NULL) = 0
> >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
> >>> ENOENT (No
> >>> such file or directory)
> >>> write(5, "\0", 1)                       = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> clone(child_stack=0,
> >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> >>> child_tidptr=0xb7f43708) = 6543
> >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> >>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> close(6)                                = 0
> >>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>>
> >>> ------------------------------------
> >>>
> >>> gdb backtrace of the main cvsupd server process
> >>>
> >>> ------------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> >>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> >>> ../src/unix/Common/UnixC.c:301
> >>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
> >>> (M3_Cwb5VA_nfd=4,
> >>> M3_A4bqCj_timeout=0xbfed9410) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> >>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> >>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
> >>> '\001')
> >>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
> >>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> >>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> >>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:153
> >>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>> ------------------------------------------------
> >>>
> >>>
> >>> strace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> >>>
> >>> -----------------------------------
> >>>
> >>> gdb backtrace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> >>> /lib/libpthread.so.0
> >>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> >>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
> >>> M3_AicXUJ_alertable=0
> >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> >>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
> >>> ThreadPThread.m3:280
> >>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> >>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
> >>> SigHandler.m3:243
> >>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> >>> ../src/FSServer.m3:231
> >>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:227
> >>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>>
> >>> -------------------------------------------
> >>>
> >>> So it looks like both the main and cloned cvsupd processes were  
> >>> waiting
> >>> for a response from the kernel call "__kernel_vsyscall ()". Under  
> >>> what
> >>> condition will this happen? Am I doing something wrong here?
> >>>
> >>> --
> >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> >>> CM3 <http://projects.elego.de/cm3>
> >>> Critical Mass Modula3 Compiler
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>>
> >>>
> >>> --
> >>> Olaf Wagner -- elego Software Solutions GmbH
> >>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G 
> >>> ermany
> >>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: 
> >>>  Berlin
> >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> >>> DE163214194
> >>>
> >>
> >>
> >
> >
> >
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> >               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ 
> > any
> > phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be 
> > rlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> > DE163214194
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/c756c57e/attachment-0002.html>

From hosking at cs.purdue.edu  Sun Jan  3 17:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Jan 2010 11:48:05 -0500
Subject: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C
	option
In-Reply-To: <COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
References: <20091229184748.frhga784gkk4cosg@mail.elegosoft.com>,
	<726BCE28-8561-40BF-BFBD-F96EC4151B50@cs.purdue.edu>,
	<20100102115406.ck9y12tv4okcoso8@mail.elegosoft.com>,
	<8DB9B34C-2F82-4AE7-ADC4-100F01C5F874@cs.purdue.edu>
	<COL101-W124A6626686E82FBA7ED91E6760@phx.gbl>
Message-ID: <E842F070-580A-4D68-850F-DD4119515F35@cs.purdue.edu>

Can someone try with user threading to see if it is something in  
thread waiting?

Sent from my iPhone

On Jan 2, 2010, at 4:42 PM, Jay K <jay.krell at cornell.edu> wrote:

>  > It must have been working relatively recently.
>
> This is probably the first time it has been tested since getting  
> into our tree.
>
>  - Jay
>
> > From: hosking at cs.purdue.edu
> > To: wagner at elegosoft.com
> > Date: Sat, 2 Jan 2010 13:35:59 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if  
> used with -C	option
> >
> > So, what's changed recently to break this? It must have been working
> > relatively recently.
> >
> > Sent from my iPhone
> >
> > On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com>  
> wrote:
> >
> > > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > >
> > >> What does -C do?
> > >
> > > Make it a server process. From the manual:
> > >
> > > -C maxClients
> > > Limits the number of simultaneous clients to
> > > maxClients.
> > > Clients beyond the specified maximum are politely
> > > refused
> > > service.
> > >
> > > If this option is not specified, cvsupd serves one
> > > client in
> > > the foreground and then exits.
> > >
> > > Olaf
> > >
> > >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> > >>
> > >>> Any ideas? Interaction problem between threads and select?
> > >>>
> > >>> Olaf
> > >>>
> > >>> ----- Forwarded message from bugs at elego.de -----
> > >>> Date: Tue, 29 Dec 2009 16:23:23 -0000
> > >>> From: CM3 <bugs at elego.de>
> > >>> Reply-To: CM3 <bugs at elego.de>
> > >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> > >>> To: @MISSING_DOMAIN
> > >>>
> > >>> #1080: CVSUPD server hangs if used with -C option
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Reporter: rajeshvadivelu | Owner: wagner
> > >>> Type: sw-bug | Status: new
> > >>> Priority: high | Milestone:
> > >>> Component: sys | Version: 5.8-RC3
> > >>> Severity: critical | Keywords:
> > >>> Relnote: | Confidential: no
> > >>> Org: Collabnet | Estimatedhours: 0
> > >>> Hours: 0 | Billable: 0
> > >>> Totalhours: 0 |
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> Htr:
> > >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz
> > >>> package.
> > >>>
> > >>> Start the cvsupd server with -C option
> > >>>
> > >>> ./cvsupd -b /data/cvsupd -C 2
> > >>>
> > >>> Try cvsup client to connect to the sever
> > >>>
> > >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>>
> > >>> The client connection will hang and after sometime we will get
> > >>> "Inactivity timeout"
> > >>>
> > >>>
> > >>> Fix:
> > >>>
> > >>>
> > >>>
> > >>> Env:
> > >>>
> > >>>
> > >>> -----------------------------
> > >>> +----------------------------------------------
> > >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror
> > >>> my cvs
> > >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to  
> get
> > >>> the
> > >>> cvsup installed.
> > >>>
> > >>> The server starts find and there was no issues if I start the  
> server
> > >>> without -C option.
> > >>>
> > >>> Starting cvsupd server without -C option
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd
> > >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> > >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30
> > >>> 21:02:46
> > >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> > >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> > >>>
> > >>> Then I did a client request as below
> > >>>
> > >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> > >>> Parsing supfile "/tmp/cvsupd.cfg"
> > >>> Connecting to myserver.com
> > >>> Connected to myserver.com
> > >>> Rejected by server: Access denied
> > >>> Will retry at 21:37:09
> > >>>
> > >>> So the request was successful and I get a valid error message  
> at the
> > >>> client.
> > >>>
> > >>> But when I start the server with -C option like the one as  
> below,
> > >>> requests
> > >>> from client are hanging and eventually getting "Inactivity
> > >>> timeout" after
> > >>> sometime.
> > >>>
> > >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> > >>>
> > >>> When ever a new client connection was made, this daemon clones
> > >>> another
> > >>> cvsupd process and it also hangs. So none of the client  
> request were
> > >>> processed.
> > >>>
> > >>> Strace of the main cvsupd server process, when a new client
> > >>> request was
> > >>> fired.
> > >>>
> > >>> -----------------------------------
> > >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 1 (in [3], left {0,
> > >>> 553000})
> > >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> > >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> > >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> > >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > >>> fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
> > >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > >>> gettimeofday({1262103026, 146476}, NULL) = 0
> > >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY| 
> O_LARGEFILE) = 7
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> _llseek(7, 0, [0], SEEK_CUR) = 0
> > >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> > >>> close(7) = 0
> > >>> gettimeofday({1262103026, 147481}, NULL) = 0
> > >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1
> > >>> ENOENT (No
> > >>> such file or directory)
> > >>> write(5, "\0", 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> clone(child_stack=0,
> > >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> > >>> child_tidptr=0xb7f43708) = 6543
> > >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> > >>> futex(0x915a460, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580f0, FUTEX_WAKE, 1) = 1
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580b8, FUTEX_WAKE, 1) = 1
> > >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> futex(0x9158098, FUTEX_WAKE, 1) = 0
> > >>> close(6) = 0
> > >>> accept(3, 0xbf809e44, [16]) = -1 EAGAIN (Resource
> > >>> temporarily
> > >>> unavailable)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>> select(4, [3], [], [3], {1, 0}) = 0 (Timeout)
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> gdb backtrace of the main cvsupd server process
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> > >>> #2 0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> > >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410)  
> at
> > >>> ../src/unix/Common/UnixC.c:301
> > >>> #3 0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779
> > >>> (M3_Cwb5VA_nfd=4,
> > >>> M3_A4bqCj_timeout=0xbfed9410) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> > >>> #4 0x00f85c7a in ThreadPThread__XIOWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> > >>> M3_CtKayy_interval=1.7976931348623157e+308,  
> M3_AicXUJ_alertable=1
> > >>> '\001')
> > >>> at ../src/thread/PTHREAD/ThreadPThread.m3:936
> > >>> #5 0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> > >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> > >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> > >>> #6 0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> > >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> > >>> #7 0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:153
> > >>> #8 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #9 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0)  
> at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>> ------------------------------------------------
> > >>>
> > >>>
> > >>> strace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> gdb backtrace of the cloned cvsupd process
> > >>>
> > >>> -----------------------------------
> > >>>
> > >>> #0 0x00a2a402 in __kernel_vsyscall ()
> > >>> #1 0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > >>> /lib/libpthread.so.0
> > >>> #2 0x00f886e6 in ThreadPThread__pthread_cond_wait  
> (cond=0x89c60b8,
> > >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> > >>> #3 0x00f81d9d in ThreadPThread__XWait  
> (M3_BXP32l_self=0xb7f9400c,
> > >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,
> > >>> M3_AicXUJ_alertable=0
> > >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> > >>> #4 0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> > >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/
> > >>> ThreadPThread.m3:280
> > >>> #5 0x00bd4e14 in SigHandler__ChangeState  
> (M3_BnMAgS_d=0xb7f9c4bc,
> > >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> > >>> #6 0x00bd5ba6 in SigHandler__ShutDown () at ../src/
> > >>> SigHandler.m3:243
> > >>> #7 0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> > >>> ../src/FSServer.m3:231
> > >>> #8 0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> > >>> ../src/FSServer.m3:227
> > >>> #9 0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/ 
> Main.m3:336
> > >>> #10 0x00f717c8 in RTLinker__RunMainBody  
> (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:399
> > >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> > >>> ../src/runtime/common/RTLinker.m3:113
> > >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> > >>> ../src/runtime/common/RTLinker.m3:122
> > >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124,  
> envp=0xbfeda13c) at
> > >>> _m3main.mc:4
> > >>>
> > >>> -------------------------------------------
> > >>>
> > >>> So it looks like both the main and cloned cvsupd processes were
> > >>> waiting
> > >>> for a response from the kernel call "__kernel_vsyscall ()".  
> Under
> > >>> what
> > >>> condition will this happen? Am I doing something wrong here?
> > >>>
> > >>> --
> > >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> > >>> CM3 <http://projects.elego.de/cm3>
> > >>> Critical Mass Modula3 Compiler
> > >>>
> > >>>
> > >>> ----- End forwarded message -----
> > >>>
> > >>>
> > >>> --
> > >>> Olaf Wagner -- elego Software Solutions GmbH
> > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, G
> > >>> ermany
> > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sit 
> z:
> > >>> Berlin
> > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > >>> DE163214194
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Olaf Wagner -- elego Software Solutions GmbH
> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ
> > > any
> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Be
> > > rlin
> > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> > > DE163214194
> > >


From hendrik at topoi.pooq.com  Mon Jan  4 05:12:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 3 Jan 2010 23:12:22 -0500
Subject: [M3devel] C generating back end
In-Reply-To: <0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
References: <COL101-W297D3372020C2CD02C65A7E6770@phx.gbl>
	<0B27C390-09BA-4B09-9EE2-72602331FB94@cs.purdue.edu>
Message-ID: <20100104041222.GD7180@topoi.pooq.com>

On Fri, Jan 01, 2010 at 06:42:34PM -0500, Tony Hosking wrote:
> On 1 Jan 2010, at 18:05, Jay K wrote:
> 
> > Fyi I finally looked at the 2.x implementation and the outputing of
> > C was implemented fairly directly at the m3front layer.
> > There wasn't the "M3CG" stuff.
> > 
> > 
> > Thus, the "easiest" way to get back such functionality would
> > probably be to "interleave" the old code and the new code within m3front.
> 
> I'd like to avoid that sort of interleaving.
> 
> > The "cleaner" way is probably to implement a new M3CG though and
> > leave m3front unchanged.
> 
> This is a much better plan.
> 
> > I still think generating portable C a great way to achieve portability.
> > Better yet maybe, generate C++ and use its exception handling feature.

There's a potential advantage in generating C++:  it might be possible 
to interoperate with C++.  Whether it's feasible to make the C++ 
readable and its contents stable is a big question, though.

-- hendrik


From jay.krell at cornell.edu  Mon Jan  4 12:50:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Jan 2010 11:50:47 +0000
Subject: [M3devel] exception handling and signal mask?
Message-ID: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>


"try" isn't supposed to save the signal mask, right?
I mean..like..finally doesn't restore it, right?
Nor does I suspect raise/except.


Specifically: Darwin.
There should be underscores in Target.m3 there?


Some of this /might/ be might fault.
In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.


Furthermore, um... you know (or if you don't, I'll tell you):


Many platforms have two versions of setjmp/longjmp.
One saves/restore the signal mask. One does not.
Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.

And then, furthermore, every system I've looked into recently except for NT
offers sigsetjmp/siglongjmp.
Their semantics when present are consistent.
Albeit less efficient.
sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.

So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..


Not saving the signal mask is potentially much faster, as it might require a syscall to get.
(Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)


I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
Not going ahead with sigsetjmp. Just yet.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100104/5ec01fea/attachment-0002.html>

From hosking at cs.purdue.edu  Mon Jan  4 16:20:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Jan 2010 10:20:53 -0500
Subject: [M3devel] exception handling and signal mask?
In-Reply-To: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
References: <COL101-W11F2BE0407B66841381A8DE6740@phx.gbl>
Message-ID: <27F530A4-62ED-490E-83CA-E3045103B4E1@cs.purdue.edu>

On 4 Jan 2010, at 06:50, Jay K wrote:

> "try" isn't supposed to save the signal mask, right?
> I mean..like..finally doesn't restore it, right?
> Nor does I suspect raise/except.

Good question.   No, exception handling mechanisms should not be responsible for this.  The design principle is usually to make TRY as fast as possible at the expense of the exceptional case.  Signal mask restoration should be programmed explicitly in a FINALLY clause.

> Specifically: Darwin.
> There should be underscores in Target.m3 there?

So, short answer on Darwin is to prefer _setjmp/_longjmp.

Same on all other platforms.

> 
> 
> Some of this /might/ be might fault.
> In particular I was unaware of this signal mask thing and its relationship to setjmp/longjmp.
> 
> 
> Furthermore, um... you know (or if you don't, I'll tell you):
> 
> 
> Many platforms have two versions of setjmp/longjmp.
> One saves/restore the signal mask. One does not.
> Sometimes I think it is via some #define to "steer" /usr/include/setjmp.h.
> Sometimes, I'm certain, it is setjmp vs. _setjmp, longjmp vs. _longjmp.
> 
> And then, furthermore, every system I've looked into recently except for NT
> offers sigsetjmp/siglongjmp.
> Their semantics when present are consistent.
> Albeit less efficient.
> sigsetjmp takes an extra integer (boolean) indicating of the signal mask should be saved.
> They use sigjmp_buf instead of jmp_buf, which is sometimes identical, sometimes one or two integers larger, or possibly even larger, depending on the size of the signal mask.
> 
> So...for the cost of sometimes enlarging the jmpbuf, and for the cost of passing the extra integer 0, maybe we should use sigsetjmp on all Unix systems? I believe the Solaris documentation warns about the "less clearly named functions" (my wording) changing semantic..though I kind of doubt they can do that..
> 
> 
> Not saving the signal mask is potentially much faster, as it might require a syscall to get.
> (Though I also wonder if it can't be a special thread local, like at a fixed offset from FS or GS as NT does it.)
> 
> 
> I'll go ahead and try just the smaller change of having Darwin use _setjmp instead of setjmp.
> Not going ahead with sigsetjmp. Just yet.
> 
>  - Jay

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

From hosking at cs.purdue.edu  Wed Jan  6 03:59:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Jan 2010 21:59:42 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
Message-ID: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>

Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question.  What say we clean things up, revert to the original clean language definition, and eliminate LONGINT?  It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away.  The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs.  These can be rewritten to something other than LONGINT.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Wed Jan  6 07:12:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 06:12:17 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
Message-ID: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>


Can I still have:
 TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
or
 TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
? defined in an interface, not in the language?
 
 
If so, probably ok.
 
 
(And can I also somehow get:
 TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
 TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
or
 TYPE UINT32 = [0..16_FFFFFFFF];
 TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
?
)
 
 
Even on 32 bit machines?
 
 
I know there is interface Word.
 
 
And then, what is the difference between:
 
 
 on 32bit:
   INTEGER vs. [16_80000000..16_7FFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFF] 
 
 
 on 64bit:
   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 

 
Any at all?
Just that array sizes are cardinal?
 
 
I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

From hosking at cs.purdue.edu  Wed Jan  6 08:06:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:06:34 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
Message-ID: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>

What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.

On 6 Jan 2010, at 01:12, Jay K wrote:

> 
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
> 
> 
> If so, probably ok.
> 
> 
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
> 
> 
> Even on 32 bit machines?
> 
> 
> I know there is interface Word.
> 
> 
> And then, what is the difference between:
> 
> 
> on 32bit:
>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFF] 
> 
> 
> on 64bit:
>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
> 
> 
> Any at all?
> Just that array sizes are cardinal?
> 
> 
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  

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

From hosking at cs.purdue.edu  Wed Jan  6 08:11:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 02:11:53 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>

PS  Any type that *requires* 64-bit could be represented as:

ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]

or

RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END

Is there ever a need to treat these as 64-bit integers?

On 6 Jan 2010, at 02:06, Tony Hosking wrote:

> What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFF] 
>> 
>> 
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>> 
>>> 
>>> 
>>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>>> 
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484 		 	   		  
> 

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

From jay.krell at cornell.edu  Wed Jan  6 09:01:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 08:01:12 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
Message-ID: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>


Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
 
 
As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
 
 
I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
 
 
Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
 
 
Not to mention inlining via special support in the frontend.
(I realize a good backend could do the same).
 
 
interface int64;
 
T = ARRAY[0..1] OF INTEGER.
 
PROCEDURE +(a,b:T):T;
PROCEDURE *(a,b:T):T;
PROCEDURE /(a,b:T):T;
 
 
?
 
 
etc...
 
 
Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Jan 2010 02:11:53 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> PS Any type that *requires* 64-bit could be represented as:
>
> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>
> or
>
> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>
> Is there ever a need to treat these as 64-bit integers?
>
> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>
> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>
> On 6 Jan 2010, at 01:12, Jay K wrote:
>
>
> Can I still have:
> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> or
> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> ? defined in an interface, not in the language?
>
>
> If so, probably ok.
>
>
> (And can I also somehow get:
> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> or
> TYPE UINT32 = [0..16_FFFFFFFF];
> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> ?
> )
>
>
> Even on 32 bit machines?
>
>
> I know there is interface Word.
>
>
> And then, what is the difference between:
>
>
> on 32bit:
> INTEGER vs. [16_80000000..16_7FFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFF]
>
>
> on 64bit:
> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>
>
> Any at all?
> Just that array sizes are cardinal?
>
>
> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Jan 2010 21:59:42 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan  6 13:28:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 12:28:02 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W23D9DB3D782C31760086AFE6720@phx.gbl>


Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we don't yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/26f1fbaf/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan  6 14:17:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Jan 2010 13:17:34 +0000
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
Message-ID: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>


Was truncated!..edited slightly to avoid..


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000








Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)

 
#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/db5c80f2/attachment-0002.html>

From mika at async.async.caltech.edu  Wed Jan  6 17:25:58 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 06 Jan 2010 08:25:58 -0800
Subject: [M3devel] double double double double checking jmp_buf
	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl> 
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <20100106162558.7B4101A2079@async.async.caltech.edu>

Forgot the #endif there?

(81)trs80:~>./a.out
48 4
(82)trs80:~>uname -a
FreeBSD trs80.async.caltech.edu 4.11-RELEASE FreeBSD 4.11-RELEASE #3: Mon Nov 21 20:27:08 PST 2005     root at trs80.async.caltech.edu:/usr/src/sys/compile/TRS80  i386

[lapdog:~] mika% cc jay.c
[lapdog:~] mika% ./a.out
768 4
[lapdog:~] mika% uname -a
Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
[lapdog:~] mika% 

Jay K writes:
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Was truncated!..edited slightly to avoid..
>
>
>From: jay.krell at cornell.edu
>To: m3devel at elegosoft.com
>Subject: double double double double checking jmp_buf size/alignment
>Date: Wed=2C 6 Jan 2010 12:28:02 +0000
>
>
>
>
>
>
>
>
>Getting this right is very important.
>  Well=2C we can overstate but it is wasteful.
>
>
>So anyone with any time=2C please compile/run this and send the "platform" =
>(uname -a) and the output=2C thanks.
>Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
>m3-sys/m3middle/src/Target.m3 and see if all three agree.
>
>
>I have checked a bunch of systems myself but extra checking is good.
>
>
>If you have a system we do not yet or any longer support=2C those are ok to=
>o.
> (e.g. Alpha_*=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)
>
>=20
>#include <setjmp.h>
>#include <stdio.h>
>
>#ifdef __GNUC__
>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B }) - sizeof(x))=
>)
>#else
>#define ALIGN_OF(x) ((int)__alignof(x))
>
>int main()
>{
>  printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIGN_OF(jmp_buf))=3B
>  return 0=3B
>}
>
>
>Thanks=2C
> - Jay
> 		 	   		  =
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Was truncated!..edited slightly to avoid..<br><br><br><hr id=3D"stopSpellin=
>g">From: jay.krell at cornell.edu<br>To: m3devel at elegosoft.com<br>Subject: dou=
>ble double double double checking jmp_buf size/alignment<br>Date: Wed=2C 6 =
>Jan 2010 12:28:02 +0000<br><br>
>
>
>
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Verdana=3B}
></style>
>
>
>Getting this right is very important.<br>&nbsp=3B Well=2C we can overstate =
>but it is wasteful.<br><br><br>So anyone with any time=2C please compile/ru=
>n this and send the "platform" (uname -a) and the output=2C thanks.<br>Or l=
>ook at m3-libs/m3core/src/C/*/Csetjmp.i3 and<br>m3-sys/m3middle/src/Target.=
>m3 and see if all three agree.<br><br><br>I have checked a bunch of systems=
> myself but extra checking is good.<br><br><br>If you have a system we do n=
>ot yet or any longer support=2C those are ok too.<br>&nbsp=3B(e.g. Alpha_*=
>=2C ARM_*=2C MIPS_*=2C *_Irix=2C *_VMS=2C *_Tru64 etc.)<br><br>&nbsp=3B<br>=
>#include &lt=3Bsetjmp.h&gt=3B<br>#include &lt=3Bstdio.h&gt=3B<br><br>#ifdef=
> __GNUC__<br>#define ALIGN_OF(x) ((int)(sizeof(struct { char a=3B x b=3B })=
> - sizeof(x)))<br>#else<br>#define ALIGN_OF(x) ((int)__alignof(x))<br><br>i=
>nt main()<br>{<br>&nbsp=3B printf("%d %d\n"=2C (int)sizeof(jmp_buf)=2C ALIG=
>N_OF(jmp_buf))=3B<br>&nbsp=3B return 0=3B<br>}<br><br><br>Thanks=2C<br>&nbs=
>p=3B- Jay<br> 		 	   		  </body>
></html>=
>
>--_b0fc625a-8a60-4f2b-9394-0f52cc975894_--


From hosking at cs.purdue.edu  Wed Jan  6 17:42:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Jan 2010 11:42:56 -0500
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>
	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
Message-ID: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>

But my question is what are the current use-cases for LONGINT?  Do they justify retaining it?

On 6 Jan 2010, at 03:01, Jay K wrote:

> 
> Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
> 
> 
> As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
> 
> 
> I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
> 
> 
> Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
> 
> 
> Not to mention inlining via special support in the frontend.
> (I realize a good backend could do the same).
> 
> 
> interface int64;
> 
> T = ARRAY[0..1] OF INTEGER.
> 
> PROCEDURE +(a,b:T):T;
> PROCEDURE *(a,b:T):T;
> PROCEDURE /(a,b:T):T;
> 
> 
> ?
> 
> 
> etc...
> 
> 
> Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Jan 2010 02:11:53 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> PS Any type that *requires* 64-bit could be represented as:
>> 
>> ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]
>> 
>> or
>> 
>> RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END
>> 
>> Is there ever a need to treat these as 64-bit integers?
>> 
>> On 6 Jan 2010, at 02:06, Tony Hosking wrote:
>> 
>> What do you need those 64-bit types for on 32-bit machines? On 32-bit machines INTEGER would still be 32-bit.
>> 
>> On 6 Jan 2010, at 01:12, Jay K wrote:
>> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>> INTEGER vs. [16_80000000..16_7FFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFF]
>> 
>> 
>> on 64bit:
>> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>> 
>> 
>> 
>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 		 	   		  

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

From rodney_bates at lcwb.coop  Wed Jan  6 18:49:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 06 Jan 2010 11:49:46 -0600
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>,
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<84C08978-0083-4986-83D0-B3F255B5D526@cs.purdue.edu>	<COL101-W51E3A3F5F658AEFFAD2555E6720@phx.gbl>
	<1746EDCD-2BBE-4A4B-BACB-7EED5FEB29D2@cs.purdue.edu>
Message-ID: <4B44CD3A.9000501@lcwb.coop>



Tony Hosking wrote:
> But my question is what are the current use-cases for LONGINT?  Do they 
> justify retaining it?
> 

I want to code stuff that requires arithmetic in > 2^32 range, and be
portable between 32- and 64-bit targets.  Using a record with two
INTEGERs on 32-bit machines and INTEGER on 64-bit machines would require
a lot of code differences between the targets, and the differences
can be pervasive.

OTOH, using the record on all machines will not take advantage of native
64-bit arithmetic when available.

Encapsulating the arithmetic in function calls also would add a lot of
overhead, unless we had a compiler that would inline them, which, as
I understand, we do not.  It's also not as readable.  I am a staunch
opponent of adding user-definable operator overloading to get this
readability advantage, because it interacts with all kinds of things
and makes the language just absurdly overcomplicated.  But LONGINT
arithmetic is language-defined and highly constrained overloading,
so the language complexity impact is much less.


>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>     
> 


From rcolebur at SCIRES.COM  Wed Jan  6 21:03:02 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Wed, 6 Jan 2010 15:03:02 -0500
Subject: [M3devel] double double double double checking
	jmp_buf	size/alignment
In-Reply-To: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
References: <COL101-W4486DACA9FBE99B8CD1D27E6720@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76F734@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Results on the following platforms are all identical:

Windows 2000, Intel Pentium 3:  64 4
Windows XP, Intel Core Duo T2400:  64 4
Windows Vista, Intel Core2 Duo P9600:  64 4

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, January 06, 2010 8:18 AM
To: m3devel
Subject: Re: [M3devel] double double double double checking jmp_buf size/alignment

Was truncated!..edited slightly to avoid..

________________________________
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: double double double double checking jmp_buf size/alignment
Date: Wed, 6 Jan 2010 12:28:02 +0000

Getting this right is very important.
  Well, we can overstate but it is wasteful.


So anyone with any time, please compile/run this and send the "platform" (uname -a) and the output, thanks.
Or look at m3-libs/m3core/src/C/*/Csetjmp.i3 and
m3-sys/m3middle/src/Target.m3 and see if all three agree.


I have checked a bunch of systems myself but extra checking is good.


If you have a system we do not yet or any longer support, those are ok too.
 (e.g. Alpha_*, ARM_*, MIPS_*, *_Irix, *_VMS, *_Tru64 etc.)


#include <setjmp.h>
#include <stdio.h>

#ifdef __GNUC__
#define ALIGN_OF(x) ((int)(sizeof(struct { char a; x b; }) - sizeof(x)))
#else
#define ALIGN_OF(x) ((int)__alignof(x))

int main()
{
  printf("%d %d\n", (int)sizeof(jmp_buf), ALIGN_OF(jmp_buf));
  return 0;
}


Thanks,
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100106/15d709fb/attachment-0002.html>

From jdp at polstra.com  Wed Jan  6 22:06:00 2010
From: jdp at polstra.com (John Polstra)
Date: Wed, 06 Jan 2010 13:06:00 -0800
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>
Message-ID: <4B44FB38.3040704@polstra.com>

File sizes and seek offsets (among other things) are 64 bits even on 
32-bit machines, and files these days are often larger than 4GB.  In 
many applications it is necessary to do arithmetic on such values. 
Also, the fact that Modula-3 traps integer overflows causes trouble when 
only 32 bits are used for file offsets.  I had to put an ugly 
work-around into CVSup to avoid an integer overflow fault caused by more 
than 4GB being sent on a TCP connection.

John

Tony Hosking wrote:
> What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>>
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>>
>>
>> If so, probably ok.
>>
>>
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>>
>>
>> Even on 32 bit machines?
>>
>>
>> I know there is interface Word.
>>
>>
>> And then, what is the difference between:
>>
>>
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFF]
>>
>>
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
>>
>>
>> Any at all?
>> Just that array sizes are cardinal?
>>
>>
>> I don't know much about the language issues, but dealing with 64bit 
>> integers in 32bit Modula-3 ought to be about as easy and efficient as 
>> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
>> should be represented as 64bit integers, though they aren't yet..it 
>> seems to be a significant interface breaking change..though maybe 
>> range types aren't where LONGINT would be? I'll have to try that..
>>
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>>
>>>
>>>
>>> Now that Jay has carefully refactored all the C-dependent code, I'd 
>>> like to pose the following question. What say we clean things up, 
>>> revert to the original clean language definition, and eliminate 
>>> LONGINT? It was only ever there for compatibility with C headers 
>>> anyway, and these have all now been nicely abstracted away. The only 
>>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
>>> structs. These can be rewritten to something other than LONGINT.
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> 


From jay.krell at cornell.edu  Thu Jan  7 04:35:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 03:35:55 +0000
Subject: [M3devel] A "radical" proposal:  drop LONGINT
In-Reply-To: <4B44FB38.3040704@polstra.com>
References: <FF00B237-4B3A-43E9-9C47-FA7207A759EB@cs.purdue.edu>
	<COL101-W5039E2BCB4232DF76A8763E6720@phx.gbl>,
	<DCEDB240-EACD-42B1-8776-7DFF27A33426@cs.purdue.edu>,
	<4B44FB38.3040704@polstra.com>
Message-ID: <COL101-W37A4D23768FBED635EB116E6710@phx.gbl>


We still have a bug where merely browsing to a directory with a file > 4GB with the Trestle GUI raises an unhandled exception.
Ideally LONGINT or [0..16_7FFFFFFFFFFFFFFF or higher] would be the type for file sizes everywhere.
It is currently INTEGER and changing it to LONGINT breaks stuff. I'll try the subrange..maybe that'll compile...
I think I proposed changing the type to "double" but nobody including me is super keen on that.
Double does have an interesting property of offering far more range than a 32bit integer on all systems going way back...
 (53bits typically of precision within a 64bit double)

 - Jay


> Date: Wed, 6 Jan 2010 13:06:00 -0800
> From: jdp at polstra.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] A "radical" proposal:  drop LONGINT
> 
> File sizes and seek offsets (among other things) are 64 bits even on 
> 32-bit machines, and files these days are often larger than 4GB.  In 
> many applications it is necessary to do arithmetic on such values. 
> Also, the fact that Modula-3 traps integer overflows causes trouble when 
> only 32 bits are used for file offsets.  I had to put an ugly 
> work-around into CVSup to avoid an integer overflow fault caused by more 
> than 4GB being sent on a TCP connection.
> 
> John
> 
> Tony Hosking wrote:
> > What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> > machines INTEGER would still be 32-bit.
> > 
> > On 6 Jan 2010, at 01:12, Jay K wrote:
> > 
> >>
> >> Can I still have:
> >> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> or
> >> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> ? defined in an interface, not in the language?
> >>
> >>
> >> If so, probably ok.
> >>
> >>
> >> (And can I also somehow get:
> >> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> >> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> >> or
> >> TYPE UINT32 = [0..16_FFFFFFFF];
> >> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> >> ?
> >> )
> >>
> >>
> >> Even on 32 bit machines?
> >>
> >>
> >> I know there is interface Word.
> >>
> >>
> >> And then, what is the difference between:
> >>
> >>
> >> on 32bit:
> >>   INTEGER vs. [16_80000000..16_7FFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFF]
> >>
> >>
> >> on 64bit:
> >>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
> >>
> >>
> >> Any at all?
> >> Just that array sizes are cardinal?
> >>
> >>
> >> I don't know much about the language issues, but dealing with 64bit 
> >> integers in 32bit Modula-3 ought to be about as easy and efficient as 
> >> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
> >> should be represented as 64bit integers, though they aren't yet..it 
> >> seems to be a significant interface breaking change..though maybe 
> >> range types aren't where LONGINT would be? I'll have to try that..
> >>
> >>
> >> - Jay
> >>
> >>
> >> ________________________________
> >>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >>> Date: Tue, 5 Jan 2010 21:59:42 -0500
> >>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
> >>> Subject: [M3devel] A "radical" proposal: drop LONGINT
> >>>
> >>>
> >>>
> >>> Now that Jay has carefully refactored all the C-dependent code, I'd 
> >>> like to pose the following question. What say we clean things up, 
> >>> revert to the original clean language definition, and eliminate 
> >>> LONGINT? It was only ever there for compatibility with C headers 
> >>> anyway, and these have all now been nicely abstracted away. The only 
> >>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
> >>> structs. These can be rewritten to something other than LONGINT.
> >>>
> >>>
> >>> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >>> University
> >>> 305 N. University Street | West Lafayette | IN 47907 | USA
> >>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/7dd1b511/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan  7 07:59:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 06:59:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
Message-ID: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>


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/20100107/16b32603/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan  7 10:47:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 09:47:07 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>


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/20100107/dd342806/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan  7 12:22:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 11:22:37 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>


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/20100107/6cc326a8/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/6cc326a8/attachment-0002.txt>

From hendrik at topoi.pooq.com  Thu Jan  7 14:11:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 08:11:17 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <20100107131117.GA22266@topoi.pooq.com>

On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> 
> 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

In any case, is the proper type for file offsets [0..7fffffffffffffff] 
or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
effort to make that legal in Modula 3.

-- hendrik


From wagner at elegosoft.com  Thu Jan  7 14:52:10 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 07 Jan 2010 14:52:10 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>

Quoting hendrik at topoi.pooq.com:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>>
>> 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
>
> In any case, is the proper type for file offsets [0..7fffffffffffffff]
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> effort to make that legal in Modula 3.

Well, I don't think that should be any practical problem right now,
shouldn't it? But 32 bit offsets have been overcome for years even
on 32 bit systems, so I definitely think we should keep the LONGINT
type and even try to incompatibly change the internal file length
type (with due care and consideration of course).

And please not for the still unfinished release, but for the next
one.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Thu Jan  7 15:00:08 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 09:00:08 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <20100107140008.GA25288@topoi.pooq.com>

On Thu, Jan 07, 2010 at 02:52:10PM +0100, Olaf Wagner wrote:
> Quoting hendrik at topoi.pooq.com:
> 
> >In any case, is the proper type for file offsets [0..7fffffffffffffff]
> >or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> >effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it?

Not just yet.  But it will be, and I suspect Modula 3 will still be 
around then.

-- hendrik


From hosking at cs.purdue.edu  Thu Jan  7 16:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:12:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <82B392A0-160D-4CD3-A36C-A64DFE7605ED@cs.purdue.edu>

I've generally found it easy enough to fix clients so they use ORD(size) to convert LONGINT to INTEGER at the boundary between the library definitions and the application.  This means they will get a run-time error if they access a file of size > LAST(INTEGER), so more pervasive changes will be needed to handle larger files.  But that is the responsibility of the client code,  not the library.  The whole point of LONGINT was to support large file sizes.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 01:59, Jay K wrote:

> 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/20100107/67014ed0/attachment-0002.html>

From hosking at cs.purdue.edu  Thu Jan  7 16:13:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:13:58 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <E6BEA822-6DE6-45E5-BBE9-CE0DCD37664D@cs.purdue.edu>

On 7 Jan 2010, at 04:47, Jay K wrote:

> 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

I discourage both of these, just to emphasize that INTEGER and LONGINT are independent types.  

> Most of the toplevel users will end up throwing in ORD, as they
> require files to fit in memory/addressspace.

Right.

> 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
> 



From hosking at cs.purdue.edu  Thu Jan  7 16:20:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:20:38 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
Message-ID: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>

On 7 Jan 2010, at 06:22, Jay K wrote:

> 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.

Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.

The problem below comes because I made WordRep and LongRep hidden interfaces.  I've just reverted m3core/src/word/m3makefile so things will now work.

> 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
> 
> <1.txt>

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

From hosking at cs.purdue.edu  Thu Jan  7 16:21:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:21:25 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <D21111F3-7947-4E4A-BBD6-9EED9A238C3B@cs.purdue.edu>

It will need to be a LONGINT type:  [0L..16_7fffffffffffffffL]


On 7 Jan 2010, at 08:11, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Thu Jan  7 16:23:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 10:23:04 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>

On 7 Jan 2010, at 08:52, Olaf Wagner wrote:

> Well, I don't think that should be any practical problem right now,

> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).

I think I am now persuaded LONGINT should stay.  But, I don't understand what "incompatibly change the internal file length
type (with due care and consideration of course)" means?

> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hendrik at topoi.pooq.com  Thu Jan  7 17:46:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 11:46:20 -0500
Subject: [M3devel] Integers
Message-ID: <20100107164620.GA30061@topoi.pooq.com>

I have some questions as to the constraints that need to be placed on 
integral types.  These issues are fundamental to an understanding of the 
role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
about them.

Is there a need for an integer type that can contain all the sizes of 
integers that can be handled by the language?  I'll call it TOP just so 
I can talk about it easily.

If it is necessary, is TOP only needed to make the language definition 
clean and concise?  Conversely, is it necessary for TOP to be available 
to programmers?  Is it necessary for TOP to be efficiently implemented, 
or implemented at all?

Even if it is not available directly to programmers, are there language 
features that require it internally?

Is it necessary that, for every two integer subranges I and J, there 
exist an integer range K such that both I and J are subranges of K?

The most commonly used integral type is INTEGER.  It seems to be the 
type used by programmers by default when they don't want to think of 
the specific range they will need.  But is it necessary for the type 
called INTEGER to be TOP?  Or, is there is no maximum implemented 
integral type, is it still necessary for INTEGER to be a maximal 
integral type?

-- hendrik



From jay.krell at cornell.edu  Thu Jan  7 18:26:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 17:26:55 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
Message-ID: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>


> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);



after:
  a := ORD(Rd.Length(b));

  c := ORD(Rd.Index(b));


  Rd.Seek(b, VAL(d, LONGINT));




Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/3fe806a3/attachment-0002.html>

From mika at async.async.caltech.edu  Thu Jan  7 18:47:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 09:47:28 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <20100107174728.3A3D41A207D@async.async.caltech.edu>

Jay K writes:
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
...
>One more compatible alternative might be to add LengthL=2C IndexL=2C SeekL?
>Maybe only break rd/wr implementers but not users?
>
>
>The reason I don't like that though is that it is even more of a no-op.
>Nobody will switch to the new functions.
>Similar to how "today" everybody will just ORD/VAL over the difference.

Isn't this what the <*OBSOLETE*> pragma is for?

     Mika

>
>
>To be clear though=2C the time for this change was 10 or 20 years ago.
>Now=2C 32bit systems are going away and with them this problem.
>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I think Op=
>enBSD..)
>
>
> - Jay
>
>
>> Date: Thu=2C 7 Jan 2010 14:52:10 +0100
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>>=20
>> Quoting hendrik at topoi.pooq.com:
>>=20
>> > On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=2C Jay K wrote:
>> >>
>> >> File.i3:
>> >>
>> >>
>> >>   Status =3D RECORD
>> >>     type: Type=3B
>> >>     modificationTime: Time.T=3B
>> >>     size: CARDINAL (* oops... *)
>> >>   END=3B
>> >>
>> >>
>> >> What to do?
>> >> [0.. higher than 7FFFFFFF] doesn't "just work".
>> >>    higher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"  =
>=20
>> >> on the end=2C
>> >>    which presumably has some relationship to turning it into a  =20
>> >> LONGINT=2C which
>> >>    causes users to fail to compile
>> >
>> > In any case=2C is the proper type for file offsets [0..7fffffffffffffff=
>]
>> > or [0..ffffffffffffffff]?  I suspect the latter.  It might take some
>> > effort to make that legal in Modula 3.
>>=20
>> Well=2C I don't think that should be any practical problem right now=2C
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems=2C so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>>=20
>> And please not for the still unfinished release=2C but for the next
>> one.
>>=20
>> Olaf
>> --=20
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C G=
>ermany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86=
> 95
>>     http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: B=
>erlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=
>194
>>=20
> 		 	   		  =
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>&gt=3B Not in the current release<br><br>Agreed.<br><br><br>I think I'll ha=
>ve this done in the next few days=2C with the<br>major caveat that it does =
>break a lot of code. I'll fix the cm3 tree.<br><br><br>The breakage is roug=
>hly:<br><br><br>rd/wr users:<br>before:<br>&nbsp=3B a :=3D Rd.Length(b)=3B<=
>br>&nbsp=3B c :=3D Rd.Index(b)=3B<br>&nbsp=3B Rd.Seek(b=2C d)=3B<br>
><br><br>after:<br>&nbsp=3B a :=3D ORD(Rd.Length(b))=3B<br>
>&nbsp=3B c :=3D ORD(Rd.Index(b))=3B<br>
>
>&nbsp=3B Rd.Seek(b=2C VAL(d=2C LONGINT))=3B<br>
>
><br><br>Though I think the last line should just work without change.<br><b=
>r><br>rd/wr implementers:<br>&nbsp=3Bmore substantial changes=2C but still =
>similar=2C lots of ORD/VAL=2C and "L".<br><br><br>One more compatible alter=
>native might be to add LengthL=2C IndexL=2C SeekL?<br>Maybe only break rd/w=
>r implementers but not users?<br><br><br>The reason I don't like that thoug=
>h is that it is even more of a no-op.<br>Nobody will switch to the new func=
>tions.<br>Similar to how "today" everybody will just ORD/VAL over the diffe=
>rence.<br><br><br>To be clear though=2C the time for this change was 10 or =
>20 years ago.<br>Now=2C 32bit systems are going away and with them this pro=
>blem.<br>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I=
> think OpenBSD..)<br><br><br>&nbsp=3B- Jay<br><br><br>&gt=3B Date: Thu=2C 7=
> Jan 2010 14:52:10 +0100<br>&gt=3B From: wagner at elegosoft.com<br>&gt=3B To:=
> m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] what to do about fi=
>le sizes being 32bits?<br>&gt=3B <br>&gt=3B Quoting hendrik at topoi.pooq.com:=
><br>&gt=3B <br>&gt=3B &gt=3B On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=
>=2C Jay K wrote:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B File.i3:<br>=
>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   Status =
>=3D RECORD<br>&gt=3B &gt=3B&gt=3B     type: Type=3B<br>&gt=3B &gt=3B&gt=3B =
>    modificationTime: Time.T=3B<br>&gt=3B &gt=3B&gt=3B     size: CARDINAL (=
>* oops... *)<br>&gt=3B &gt=3B&gt=3B   END=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B What to do?<br>&gt=3B &gt=3B&gt=3B =
>[0.. higher than 7FFFFFFF] doesn't "just work".<br>&gt=3B &gt=3B&gt=3B    h=
>igher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L"   <br>&gt=
>=3B &gt=3B&gt=3B on the end=2C<br>&gt=3B &gt=3B&gt=3B    which presumably h=
>as some relationship to turning it into a   <br>&gt=3B &gt=3B&gt=3B LONGINT=
>=2C which<br>&gt=3B &gt=3B&gt=3B    causes users to fail to compile<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B In any case=2C is the proper type for file offs=
>ets [0..7fffffffffffffff]<br>&gt=3B &gt=3B or [0..ffffffffffffffff]?  I sus=
>pect the latter.  It might take some<br>&gt=3B &gt=3B effort to make that l=
>egal in Modula 3.<br>&gt=3B <br>&gt=3B Well=2C I don't think that should be=
> any practical problem right now=2C<br>&gt=3B shouldn't it? But 32 bit offs=
>ets have been overcome for years even<br>&gt=3B on 32 bit systems=2C so I d=
>efinitely think we should keep the LONGINT<br>&gt=3B type and even try to i=
>ncompatibly change the internal file length<br>&gt=3B type (with due care a=
>nd consideration of course).<br>&gt=3B <br>&gt=3B And please not for the st=
>ill unfinished release=2C but for the next<br>&gt=3B one.<br>&gt=3B <br>&gt=
>=3B Olaf<br>&gt=3B -- <br>&gt=3B Olaf Wagner -- elego Software Solutions Gm=
>bH<br>&gt=3B                 Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 =
>Berlin=2C Germany<br>&gt=3B phone: +49 30 23 45 86 96  mobile: +49 177 2345=
> 869  fax: +49 30 23 45 86 95<br>&gt=3B     http://www.elegosoft.com | Gesc=
>h=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin<br>&gt=3B Handelregister: Amtsg=
>ericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>&gt=3B <br> 		 	=
>   		  </body>
></html>=
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_--


From hosking at cs.purdue.edu  Thu Jan  7 19:58:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 13:58:51 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100107164620.GA30061@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
Message-ID: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>

I think your confusion relates to understanding how the language defines "base" types.

You should understand that INTEGER and LONGINT have *different* base types.  This indicates that they have inherently different representations, and indeed, operations on INTEGER and operations on LONGINT are inherently different.

Every enumeration type similarly has a base type.  If it's range is expressed over INTEGER values then its base type is INTEGER.  If expressed over LONGINT then its base type is LONGINT.

I don't think I understand the rest of your questions.

On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:

> I have some questions as to the constraints that need to be placed on 
> integral types.  These issues are fundamental to an understanding of the 
> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> about them.
> 
> Is there a need for an integer type that can contain all the sizes of 
> integers that can be handled by the language?  I'll call it TOP just so 
> I can talk about it easily.
> 
> If it is necessary, is TOP only needed to make the language definition 
> clean and concise?  Conversely, is it necessary for TOP to be available 
> to programmers?  Is it necessary for TOP to be efficiently implemented, 
> or implemented at all?
> 
> Even if it is not available directly to programmers, are there language 
> features that require it internally?
> 
> Is it necessary that, for every two integer subranges I and J, there 
> exist an integer range K such that both I and J are subranges of K?
> 
> The most commonly used integral type is INTEGER.  It seems to be the 
> type used by programmers by default when they don't want to think of 
> the specific range they will need.  But is it necessary for the type 
> called INTEGER to be TOP?  Or, is there is no maximum implemented 
> integral type, is it still necessary for INTEGER to be a maximal 
> integral type?
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Thu Jan  7 20:07:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:07:03 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W601686F3B46F7E436313EE6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
Message-ID: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>

Jay,

I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony

On 7 Jan 2010, at 12:26, Jay K wrote:

> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

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

From hosking at cs.purdue.edu  Thu Jan  7 20:17:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 14:17:40 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>

I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Jan 2010, at 14:07, Tony Hosking wrote:

> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
>> > Not in the current release
>> 
>> Agreed.
>> 
>> 
>> I think I'll have this done in the next few days, with the
>> major caveat that it does break a lot of code. I'll fix the cm3 tree.
>> 
>> 
>> The breakage is roughly:
>> 
>> 
>> rd/wr users:
>> before:
>>   a := Rd.Length(b);
>>   c := Rd.Index(b);
>>   Rd.Seek(b, d);
>> 
>> 
>> after:
>>   a := ORD(Rd.Length(b));
>>   c := ORD(Rd.Index(b));
>>   Rd.Seek(b, VAL(d, LONGINT));
>> 
>> 
>> Though I think the last line should just work without change.
>> 
>> 
>> rd/wr implementers:
>>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
>> 
>> 
>> One more compatible alternative might be to add LengthL, IndexL, SeekL?
>> Maybe only break rd/wr implementers but not users?
>> 
>> 
>> The reason I don't like that though is that it is even more of a no-op.
>> Nobody will switch to the new functions.
>> Similar to how "today" everybody will just ORD/VAL over the difference.
>> 
>> 
>> To be clear though, the time for this change was 10 or 20 years ago.
>> Now, 32bit systems are going away and with them this problem.
>> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
>> 
>> 
>>  - Jay
>> 
>> 
>> > Date: Thu, 7 Jan 2010 14:52:10 +0100
>> > From: wagner at elegosoft.com
>> > To: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
>> > 
>> > Quoting hendrik at topoi.pooq.com:
>> > 
>> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> > >>
>> > >> 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
>> > >
>> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
>> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
>> > > effort to make that legal in Modula 3.
>> > 
>> > Well, I don't think that should be any practical problem right now,
>> > shouldn't it? But 32 bit offsets have been overcome for years even
>> > on 32 bit systems, so I definitely think we should keep the LONGINT
>> > type and even try to incompatibly change the internal file length
>> > type (with due care and consideration of course).
>> > 
>> > And please not for the still unfinished release, but for the next
>> > one.
>> > 
>> > Olaf
>> > -- 
>> > Olaf Wagner -- elego Software Solutions GmbH
>> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> > 
> 

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

From jay.krell at cornell.edu  Thu Jan  7 21:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:31:31 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
Message-ID: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>


Given that files are in fact larger than 4GB, why should we impose such a limit?

Doesn't it make for a pretty lame system?

 

Pretty much no existing 32bit C system for many years now any such limit and

C started going past these limits around 15 years ago.

 

It turns out changes I sent were pretty nearly done. I can now build all of "std"

with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".

 

 

 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:  +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:  +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 


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

From jay.krell at cornell.edu  Thu Jan  7 21:33:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Jan 2010 20:33:22 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
Message-ID: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>


I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,

and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).

This seems to be about the best we can do.

 

Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?

Therefore INTEGER and LONGINT somewhat interchangable?

 

 

Again, currently merely browsing to a directory with a large file raises an exception.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:07:03 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Thu Jan  7 22:33:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:33:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>
Message-ID: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>

What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.

If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.

I am really starting to think the addition of LONGINT was a big mistake.

On 7 Jan 2010, at 15:31, Jay K wrote:

> Given that files are in fact larger than 4GB, why should we impose such a limit?
> Doesn't it make for a pretty lame system?
>  
> Pretty much no existing 32bit C system for many years now any such limit and
> C started going past these limits around 15 years ago.
>  
> It turns out changes I sent were pretty nearly done. I can now build all of "std"
> with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:17:40 -0500
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.
> 
> 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 7 Jan 2010, at 14:07, Tony Hosking wrote:
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone:  +49 30 23 45 86 96  +49 30 23 45 86 96 mobile:  +49 177 2345 869 +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 
> 

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

From hosking at cs.purdue.edu  Thu Jan  7 22:37:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 7 Jan 2010 16:37:12 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
Message-ID: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>

On 7 Jan 2010, at 15:33, Jay K wrote:

> I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,
> and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).
> This seems to be about the best we can do.

I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger than address spaces.  If someone really wants to use an OS-specific file size that is bigger than an address space then they can use the C interfaces, along with LONGINT.  If they are working with Rd/Wr then they don't need to mess with the ugliness.

>  Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?
> Therefore INTEGER and LONGINT somewhat interchangable?

Again, this contradicts the design principles of the Modula-3 type system.

>  Again, currently merely browsing to a directory with a large file raises an exception.

What code?  Does it use C interfaces or the Modula-3 interfaces?

>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:07:03 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Jay,
> 
> I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!
> 
> -- Tony
> 
> On 7 Jan 2010, at 12:26, Jay K wrote:
> 
> > Not in the current release
> 
> Agreed.
> 
> 
> I think I'll have this done in the next few days, with the
> major caveat that it does break a lot of code. I'll fix the cm3 tree.
> 
> 
> The breakage is roughly:
> 
> 
> rd/wr users:
> before:
>   a := Rd.Length(b);
>   c := Rd.Index(b);
>   Rd.Seek(b, d);
> 
> 
> after:
>   a := ORD(Rd.Length(b));
>   c := ORD(Rd.Index(b));
>   Rd.Seek(b, VAL(d, LONGINT));
> 
> 
> Though I think the last line should just work without change.
> 
> 
> rd/wr implementers:
>  more substantial changes, but still similar, lots of ORD/VAL, and "L".
> 
> 
> One more compatible alternative might be to add LengthL, IndexL, SeekL?
> Maybe only break rd/wr implementers but not users?
> 
> 
> The reason I don't like that though is that it is even more of a no-op.
> Nobody will switch to the new functions.
> Similar to how "today" everybody will just ORD/VAL over the difference.
> 
> 
> To be clear though, the time for this change was 10 or 20 years ago.
> Now, 32bit systems are going away and with them this problem.
> (Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)
> 
> 
>  - Jay
> 
> 
> > Date: Thu, 7 Jan 2010 14:52:10 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Quoting hendrik at topoi.pooq.com:
> > 
> > > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> > >>
> > >> 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
> > >
> > > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > > effort to make that legal in Modula 3.
> > 
> > Well, I don't think that should be any practical problem right now,
> > shouldn't it? But 32 bit offsets have been overcome for years even
> > on 32 bit systems, so I definitely think we should keep the LONGINT
> > type and even try to incompatibly change the internal file length
> > type (with due care and consideration of course).
> > 
> > And please not for the still unfinished release, but for the next
> > one.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

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

From mika at async.async.caltech.edu  Fri Jan  8 01:31:10 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 07 Jan 2010 16:31:10 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu> 
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>
	<COL101-W2789447B1C02C9F8EFBCA2E6710@phx.gbl>
	<D529CE6D-4A63-4EA6-A7B3-668C8900F84C@cs.purdue.edu>
Message-ID: <20100108003110.0BC1E1A207D@async.async.caltech.edu>

Tony Hosking writes:
>
>--Apple-Mail-29--1022292864
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=iso-8859-1
>
>On 7 Jan 2010, at 15:33, Jay K wrote:
>
>> I agree it isn't pretty but a big mistake was made many years ago, =
>assuming file sizes are no larger than address spaces,
>> and the current system might also not be so great (not allowing =
>comparing a LONGINT to "0" or assigning it from an INTEGER).
>> This seems to be about the best we can do.
>
>I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger =
>than address spaces.  If someone really wants to use an OS-specific file =
>size that is bigger than an address space then they can use the C =
>interfaces, along with LONGINT.  If they are working with Rd/Wr then =
>they don't need to mess with the ugliness.

Just to add my input to this discussion... 

I have programs that like to write huge log files (> 2GB), and with Wr.PutText
this is a problem.

But it's very easy to work around.  Use the RdWrReset interface implemented as
follows (not sure where I originally got this code from, Blair MacIntyre?):

MODULE RdWrReset;
IMPORT Rd AS R, Wr AS W;
IMPORT RdClass, WrClass;
<*NOWARN*>IMPORT UnsafeWr, UnsafeRd;

(* Since we need to use the Mutex properties of Rd.T and Wr.T, we
   should actually import UnsafeWr and UnsafeRd. We need to add the
   following revelations, as the comment in UnsafeRd points out, if we
   want to include both the Unsafe* and *Class interfaces. *)
REVEAL RdClass.Private <: MUTEX;
REVEAL WrClass.Private <: MUTEX;

PROCEDURE Rd (rd: R.T) =
  BEGIN
    LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END;
  END Rd;

PROCEDURE Wr (wr: W.T) =
  BEGIN
    LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END;
  END Wr;

BEGIN END RdWrReset.

So far this has sufficed for me...
    Mika


From jay.krell at cornell.edu  Fri Jan  8 02:07:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:07:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W19301B1547CB12BC8501ECE6700@phx.gbl>


 > As you are already aware, some systems have only 32-bit addressable files.

 

Really?!

I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.

4G has not been a large file size for quite a long time now.

FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.

Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.

 

 

 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.

 

 

I can build "std" now. It does escape pretty far, but it is actually fairly contained.

It would help a little of an INTEGER could be assigned to a LONGINT.

Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.

Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..

 

 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  

 

Isn't that pretty natural?

Aren't "file" one of the main things used with Rd/Wr?

Besides that, if you consider "streams", going beyond 4G seems even more limiting.

You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.

 

I agree that dealing with such large files can be difficult, depending on the algorithms.

But the "base" of the system shouldn't remove the ability for higher parts to do so.

 

 

And resorting to C seems unnecessary.

The operating system interfaces are essentially identical on Posix, as long you #define whatever.

They vary at the ABI level for compatibility.

 

 

Should I create a branch, or can we review the diffs and decide?

 

 

 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:   +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96  mobile:   +49 177 2345 869  +49 177 2345 869   +49 177 2345 869  +49 177 2345 869  fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



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

From jay.krell at cornell.edu  Fri Jan  8 02:09:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:09:11 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W17B8D1C035DBDB2940DF36E6700@phx.gbl>


To repeat myself, basically every system supports 64bit file sizes and they are easy to use from C.

In my opinion, a "systems" language is something you can do "anything" in.

Now, granted, the language isn't the issue here.

But conflation of libraries and languages is common and not entirely invalid.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 


From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?


What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:    +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96   mobile:    +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869   fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



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

From jay.krell at cornell.edu  Fri Jan  8 02:18:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:18:51 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<20100107131117.GA22266@topoi.pooq.com>, ,
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>,
	<COL101-W601686F3B46F7E436313EE6710@phx.gbl>,
	<BE0C860C-1307-4F8C-9935-72CF2EF77B05@cs.purdue.edu>, ,
	<178ACFA7-7412-4406-B176-80E27976A202@cs.purdue.edu>,
	<COL101-W614BE08BDE7A3041DF2A48E6710@phx.gbl>,
	<69B29C78-A38F-4068-BE4F-4073B284FF77@cs.purdue.edu>
Message-ID: <COL101-W260CDC61EC90506D4D79D8E6700@phx.gbl>


[truncated]

To repeat myself, basically every system supports 64bit file

sizes and they are easy to use from C.
In my opinion, a "systems" language is something you

can do "anything" in.
Now, granted, the language isn't the issue here.
But conflation of libraries and languages is common

and not entirely invalid.
 
 
 - Jay
 






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 01:07:23 +0000



 > As you are already aware, some systems have only 32-bit addressable files.
 
Really?!
I don't think any system that we currently support or almost any that we would forseably lacks ability to use files larger than 4G.
4G has not been a large file size for quite a long time now.
FreeBSD, NetBSD, NT, Linux, Solaris, AIX, Irix, VMS, HP-UX. 64bit file sizes in 32bit code.
Maybe not MS-DOS, maybe not Win9x, but maybe esp. via remote file systems.
 
 
 > If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.
 
 
I can build "std" now. It does escape pretty far, but it is actually fairly contained.
It would help a little of an INTEGER could be assigned to a LONGINT.
Then the "porting" work for Rd/Wr users is just to add ORD on Index/Length calls.
Currently they also need VAL(foo, LONGINT) also for Seek calls, which could be eliminated if..
 
 > You are conflating OS "files" with Modula-3 Rd/Wr.T.  
 
Isn't that pretty natural?
Aren't "file" one of the main things used with Rd/Wr?
Besides that, if you consider "streams", going beyond 4G seems even more limiting.
You know, I didn't change Read/Write/Get/whatever to use LONGINT. They require an in-memory buffer and therefore must use INTEGER or CARDINAL.
 
I agree that dealing with such large files can be difficult, depending on the algorithms.
But the "base" of the system shouldn't remove the ability for higher parts to do so.
 
 
And resorting to C seems unnecessary.
The operating system interfaces are essentially identical on Posix, as long you #define whatever.
They vary at the ABI level for compatibility.
 
 
Should I create a branch, or can we review the diffs and decide?
 
 
 - Jay


 






From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 16:33:41 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what to do about file sizes being 32bits?



What do you mean by "files"?  You are conflating OS "files" with Modula-3 Rd/Wr.T.  They are not necessarily the same.  Modula-3 is designed to be OS-independent.  As you are already aware, some systems have only 32-bit addressable files.


If we go the route you suggest then LONGINT will escape from a few isolated uses into the rest of the system.  This seems overkill.  With Rd/Wr.Length typed as INTEGER then on 64-bit systems you will have 64-bit addressable files.  Elsewhere, 32-bit.


I am really starting to think the addition of LONGINT was a big mistake.





On 7 Jan 2010, at 15:31, Jay K wrote:

Given that files are in fact larger than 4GB, why should we impose such a limit?
Doesn't it make for a pretty lame system?
 
Pretty much no existing 32bit C system for many years now any such limit and
C started going past these limits around 15 years ago.
 
It turns out changes I sent were pretty nearly done. I can now build all of "std"
with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".
 
 
 - Jay

 


Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.


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      +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001        +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001      +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      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484        +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484      +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484  



On 7 Jan 2010, at 14:07, Tony Hosking wrote:




Jay,


I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony


On 7 Jan 2010, at 12:26, Jay K wrote:

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);


after:
  a := ORD(Rd.Length(b));
  c := ORD(Rd.Index(b));
  Rd.Seek(b, VAL(d, LONGINT));


Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, SeekL?
Maybe only break rd/wr implementers but not users?


The reason I don't like that though is that it is even more of a no-op.
Nobody will switch to the new functions.
Similar to how "today" everybody will just ORD/VAL over the difference.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 7 Jan 2010 14:52:10 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> 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
> >
> > In any case, is the proper type for file offsets [0..7fffffffffffffff]
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
> > effort to make that legal in Modula 3.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, so I definitely think we should keep the LONGINT
> type and even try to incompatibly change the internal file length
> type (with due care and consideration of course).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone:     +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96        +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96      +49 30 23 45 86 96  +49 30 23 45 86 96    +49 30 23 45 86 96  +49 30 23 45 86 96    mobile:     +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869       +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869      +49 177 2345 869  +49 177 2345 869    +49 177 2345 869  +49 177 2345 869    fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



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

From rodney_bates at lcwb.coop  Fri Jan  8 02:22:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:22:00 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100107131117.GA22266@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
Message-ID: <4B4688B8.50701@lcwb.coop>

Full-range unsigned integers are a language designer's headache, because
there are conflicts no matter what you do.  The Modula-3 approach is to
use the operations in interface Word.i3 (and now Long.i3) on type
INTEGER (not CARDINAL, which has only half the range).  These apply
unsigned interpretation to values of type INTEGER.

hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
>> 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
> 
> In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> or [0..ffffffffffffffff]?  I suspect the latter.  It might take some 
> effort to make that legal in Modula 3.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 02:45:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:45:03 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B4688B8.50701@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<20100107131117.GA22266@topoi.pooq.com>, <4B4688B8.50701@lcwb.coop>
Message-ID: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>


I understand "full range" is a problem, because, something like,

the set of operations isn't closed.

 

 

I believe you need to define multiple types and/or

multiple operations.

 

 

You need an ability to trap/fail on overflow.

You need an ability for silent wraparound on overflow.

You need perhaps a way to add precision as needed. Slow.

You need perhaps a way to specify arbitrarily high precision,

  and then, again, either trap/fail or silent wraparound.

 

 

Basically, in my opinion, having just "INTEGER" and just "+"

isn't nearly sufficient.

 

 

Not having operator overloading makes pretty much any solution painful to use.

 

 

We and C both have a compromise that covers most cases and

when people really need higher fixed or arbitrary precision, they

either give up the convenient "operator" syntax or use C++.

 

 

As I understand, in C, unsigned integers are defined to "silently wraparound"

and signed integers are implementation defined, could "trap" but in reality

all implementations "silently wraparound".

It is a point of unsafety though, beyond the more well known

buffer overflows, leaks, etc.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:22:00 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> Full-range unsigned integers are a language designer's headache, because
> there are conflicts no matter what you do. The Modula-3 approach is to
> use the operations in interface Word.i3 (and now Long.i3) on type
> INTEGER (not CARDINAL, which has only half the range). These apply
> unsigned interpretation to values of type INTEGER.
> 
> hendrik at topoi.pooq.com wrote:
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >> 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
> > 
> > In any case, is the proper type for file offsets [0..7fffffffffffffff] 
> > or [0..ffffffffffffffff]? I suspect the latter. It might take some 
> > effort to make that legal in Modula 3.
> > 
> > -- hendrik
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/21906409/attachment-0002.html>

From rodney_bates at lcwb.coop  Fri Jan  8 02:35:20 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:35:20 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
Message-ID: <4B468BD8.4020106@lcwb.coop>


I addressed all these details in my original LONGINT proposal, but it
didn't get much attention at the time.  That would have been October
of 2007.  I can't find the posts right now, because the link
http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
too many email account changes to be able to find it in my own
inboxes.

I proposed, and still do, that LONGINT be an ordinal type.  This has
the consequence, by preexisting rules, that INTEGER and LONGINT would
be assignable to each other.  This does not violate the preexisting
language precedent, in fact, it is exactly like the preexisting rules
for INTEGER and all its subtypes--they are assignable if the value is
in the LHS type.

This eliminates the necessity for the ORD and VAL conversions in most
places, where there are mixtures of the types.  Most places in the
language require only assignability, not type equality.  Exceptions
include passing to a VAR formal and use in a type definition of a new
type.

A consequence of existing rules is that there would be, if necessary,
runtime value checks.  In many cases, including the examples we are
discussing here, assigning a LONGINT to an INTEGER could well
introduce a bug when a value is out of range, but this is no different
from what happens when ORD/VAL are coded explicitly.

On the other side of this argument, the necessity of coding ORD/VAL
would point out statically, places where value range errors should be
ruled out by the programmer.  A conscientious programmer would then
make an informed decision whether to just insert ORD/VAL, or whether
it was necessary to change the INTEGER variable to LONGINT.  But
again, the already existing rules for subranges don't do this, so
making INTEGER and LONGINT assignable would be consistent.

Note that right now, the current implementation has a linguistic
contradiction in that, if subranges of LONGINT are allowed, then
LONGINT is an ordinal type, which implies LONGINT and INTEGER are
mutually assignable.  This could, of course be fixed in the language,
but I would prefer making the two types assignable.




Jay K wrote:
> 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
> 


From rodney_bates at lcwb.coop  Fri Jan  8 02:37:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 07 Jan 2010 19:37:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
Message-ID: <4B468C63.9050404@lcwb.coop>



Tony Hosking wrote:
> On 7 Jan 2010, at 06:22, Jay K wrote:
> 
>> 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.
> 
> Again, I discourage this as not in the spirit of the Modula-3 type 
> system which abhors implicit casts.
> 
Indeed, Modula-3 has no implicit casts at all.  But it does have something
that sometimes accomplishes the same result in a way that is far simpler
to define and represents a higher level of abstraction, namely, the
concept of assignability.  A value, e.g. 10, can be in the value set of
many types (INTEGER, many of its subranges, and now LONGINT and many if
its subranges too).  If so, it can in certain carefully specified cases,
be assigned from one of these types to another, without any syntactically
explicit notation required of the programmer.

This represents the more abstract view that 10 is 10, as opposed to the
usual view that 10 sitting in a byte is not the same as 10 in a word.
Of course, at the machine level. they are not the same, but in Modula-3,
that is only a representation matter that the compiler must take care of,
not a high-level language matter that needs pages of rules to define.

It took me years to fully understand the implications of replacing implicit
type conversions by the assignability concept, but I now consider it one
of Modula-3's great ideas, even if it is a small thing.


From jay.krell at cornell.edu  Fri Jan  8 03:01:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:01:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <COL101-W41E4AFA2D1DDE2CD2C39D7E6700@phx.gbl>


I apologize for not paying close attention at the time.

That seems to make sense to me now.

 

 

There is at least an in-between version where INTEGER

is assignable to LONGINT.

 

 

In your proposal, the amount of source change required would be

I think very very little. Some code would "just work" with large files,

and some code would fail.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:35:20 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time. That would have been October
> of 2007. I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type. This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other. This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.
> 
> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types. Most places in the
> language require only assignability, not type equality. Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.
> 
> A consequence of existing rules is that there would be, if necessary,
> runtime value checks. In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.
> 
> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer. A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT. But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.
> 
> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable. This could, of course be fixed in the language,
> but I would prefer making the two types assignable.
> 
> 
> 
> 
> Jay K wrote:
> > 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/20100108/9394f4b3/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan  8 02:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
Message-ID: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>


I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/3f0be214/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan  8 03:25:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 02:25:56 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>, ,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>, ,
	<4B468C63.9050404@lcwb.coop>,
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <COL101-W55238865FDCA7966D9D371E6700@phx.gbl>


Here are some of the old messages. I haven't yet found a proposal.


https://mail.elegosoft.com/pipermail/m3devel/2007-July/000323.html
https://mail.elegosoft.com/pipermail/m3devel/2007-July/
https://mail.elegosoft.com/pipermail/m3devel/

You have to allow the exception for the certificate.


 - Jay



From: jay.krell at cornell.edu
To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Date: Fri, 8 Jan 2010 01:58:33 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?








I don't believe currently "10" is assignable

(or comparable) to LONGINT.

You have to use 10L.

 

 

I do believe any INTEGER or CARDINAL expression should be assignable

to LONGINT, but I don't think it is implemented that way currently.

 

 

And, then, I wonder if subranges are all we need, no LONGINT.

But I don't understand the language well enough.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:37:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> 
> Tony Hosking wrote:
> > On 7 Jan 2010, at 06:22, Jay K wrote:
> > 
> >> 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.
> > 
> > Again, I discourage this as not in the spirit of the Modula-3 type 
> > system which abhors implicit casts.
> > 
> Indeed, Modula-3 has no implicit casts at all. But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability. A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too). If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ea64c1af/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan  8 04:35:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 03:35:44 +0000
Subject: [M3devel] longint..revisited?
Message-ID: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>


I can't find Rodney's proposal but I think I understand
a lot of it from today's mail.


Can we revisit this?


My understanding is that Rodney's proposal
deems INTEGER assignable to LONGINT,
and vice versa, and that assignments of LONGINT
to INTEGER undergo runtime range checks,
can raise exceptions.


I assume it also follows that:


LONGINT can be added/subtracted/modded to INTEGER,
yielding LONGINT.


INTEGER MOD LONGINT would range check the LONGINT.


INC/DEC(LONGINT, INTEGER) would just work


INC/DEC(INTEGER, LONGINT) would range check.


The downside is that the chance for failure would be
silently injected into various places.


Another proposal would be that INTEGER is assignable to LONGINT,
but not vice versa. I really don't see why not.


   LONGINT := INTEGER  
   LONGINT + INTEGER => LONGINT  
  


LONGINT - INTEGER => LONGINT  
  


LONGINT * INTEGER => LONGINT  
   LONGINT / INTEGER => LONGINT  
  
LONGINT MOD INTEGER => INTEGER (think about it) 
   INC(LONGINT, INTEGER)
  

DEC(LONGINT, INTEGER)





all seem very reasonable.


 - Jay

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

From hendrik at topoi.pooq.com  Fri Jan  8 04:53:44 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 22:53:44 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
Message-ID: <20100108035343.GA9556@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> 
> I understand "full range" is a problem, because, something like,
> the set of operations isn't closed.

What does this mean?  What exactly do you mean by "full range"?  And 
what do you mean by "closed"?

> 
> I believe you need to define multiple types and/or
> multiple operations.
> 
> You need an ability to trap/fail on overflow.
> 
> You need an ability for silent wraparound on overflow.
> You need perhaps a way to add precision as needed. Slow.
> You need perhaps a way to specify arbitrarily high precision,
>   and then, again, either trap/fail or silent wraparound.
> 
> Basically, in my opinion, having just "INTEGER" and just "+"
> isn't nearly sufficient.
> 
> Not having operator overloading makes pretty much any solution painful to use.

+ is defined on integers and reals.  If that's not an overload, why not 
have + defined on longint as well?

> We and C both have a compromise that covers most cases and
> when people really need higher fixed or arbitrary precision, they
> either give up the convenient "operator" syntax or use C++.
>  
> 
> As I understand, in C, unsigned integers are defined to "silently wraparound"

The wraparound unsigned integers are extremely useful.  The most common 
operations, +, *, and - have a clean, well-defined semantics as 
arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
identifies.

Suppose you have an expression involving +, -, * and integers in 
0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
If you evaluate it with nonwraparound arithmetic, you may get overflow.
Nonetheless, using wraparound arithmetic under these conditions will 
still give the right answer.

This makes wraparound integers useful for indexing strange arrays with, 
say, multiple subscripts in the rante 1000000000..1000000003.  
Intermediate results partway through subscript evaluations can overflow 
to their hearts' content, and you still get the right element in the 
end.

> 
> and signed integers are implementation defined, could "trap" but in reality
> all implementations "silently wraparound".
> It is a point of unsafety though, beyond the more well known
> buffer overflows, leaks, etc.
> 
>  - Jay
> 
>  
> > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > 
> > Full-range unsigned integers are a language designer's headache, because
> > there are conflicts no matter what you do. The Modula-3 approach is to
> > use the operations in interface Word.i3 (and now Long.i3) on type
> > INTEGER (not CARDINAL, which has only half the range). These apply
> > unsigned interpretation to values of type INTEGER.

The problem with Word.i3 is that expressions involving these integers 
are so unreadable as to be seriously susceptible to error.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 05:03:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 7 Jan 2010 23:03:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
Message-ID: <20100108040333.GB9556@topoi.pooq.com>

On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
> I think your confusion relates to understanding how the language 
> defines "base" types.
> 
> You should understand that INTEGER and LONGINT have *different* base 
> types.  This indicates that they have inherently different 
> representations,

What's implicit in this statment is that all the subranges of INTEGER 
have inherently the same representation.  Why is this inportant?  Are 
there, for example,  places in the language where you have a subrange 
but don't know what the subrange is?

> and indeed, operations on INTEGER and operations on 
> LONGINT are inherently different.

So in the language at present, there is no single type at the top of the 
integer type lattice (and it's not really a lattice).  There are, 
however, two maximal types.  Is this right?

> 
> Every enumeration type similarly has a base type.  If it's range is 
> expressed over INTEGER values then its base type is INTEGER.  If 
> expressed over LONGINT then its base type is LONGINT.
> 
> I don't think I understand the rest of your questions.

Where in the language is it important that INTEGER and LONGINT be 
different base types?  In other words, what advantages does this 
separation convey?

-- hendrik
> 
> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
> 
> > I have some questions as to the constraints that need to be placed on 
> > integral types.  These issues are fundamental to an understanding of the 
> > role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
> > about them.
> > 
> > Is there a need for an integer type that can contain all the sizes of 
> > integers that can be handled by the language?  I'll call it TOP just so 
> > I can talk about it easily.
> > 
> > If it is necessary, is TOP only needed to make the language definition 
> > clean and concise?  Conversely, is it necessary for TOP to be available 
> > to programmers?  Is it necessary for TOP to be efficiently implemented, 
> > or implemented at all?
> > 
> > Even if it is not available directly to programmers, are there language 
> > features that require it internally?
> > 
> > Is it necessary that, for every two integer subranges I and J, there 
> > exist an integer range K such that both I and J are subranges of K?
> > 
> > The most commonly used integral type is INTEGER.  It seems to be the 
> > type used by programmers by default when they don't want to think of 
> > the specific range they will need.  But is it necessary for the type 
> > called INTEGER to be TOP?  Or, is there is no maximum implemented 
> > integral type, is it still necessary for INTEGER to be a maximal 
> > integral type?
> > 
> > -- hendrik
> 


From jay.krell at cornell.edu  Fri Jan  8 07:07:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:07:08 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W45DD659513608DE2BE3F86E6700@phx.gbl>


I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case, n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case, 2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0397073c/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan  8 07:41:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 06:41:09 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>,
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>,
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <COL101-W530411D2F9C6E2619BD794E6700@phx.gbl>


[truncated again, I have a knack for
aiming near 80 columns and therefore getting
the period right where the mail software truncates..]




From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 06:07:08 +0000








I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case,
    n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case,
   2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/ae9ef910/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan  8 08:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 07:44:53 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
Message-ID: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>


This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.

 

  LONGINT + INTEGER => LONGINT 

  LONGINT - INTEGER => LONGINT 

  LONGINT * INTEGER => LONGINT 

  LONGINT DIV INTEGER => LONGINT 

  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 

  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  

  LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  

  MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

  MAX(INTEGER, LONGINT) => LONGINT  

  LONGINT := INTEGER 

 

Other mixes are less obvious and would require runtime checks.

 

I think the backend will just work but I haven't tried that yet.

 (Truth be told, I can only affectively edit files on NT...)

 

Thoughts?

 

 - Jay 

 

Index: builtinOps/Dec.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
retrieving revision 1.9
diff -u -r1.9 Dec.m3
--- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
+++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
@@ -44,7 +44,7 @@
     IF (NUMBER (ce.args^) > 1) THEN
       IF Type.IsSubtype (t, LInt.T) THEN
         t := Type.Base (Expr.TypeOf (ce.args[1]));
-        IF (t # LInt.T) THEN
+        IF t # LInt.T AND t # Int.T THEN
           Error.Txt (name, "second argument must be a LONGINT");
         END;
       ELSE
Index: builtinOps/Max.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
retrieving revision 1.3
diff -u -r1.3 Max.m3
--- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
+++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
@@ -25,11 +25,14 @@
 
 PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     ta := Type.Base (Expr.TypeOf (ce.args[0]));
     tb := Type.Base (Expr.TypeOf (ce.args[1]));
 
-    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
+    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
+      resultType := LInt.T;
+    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
       Error.Txt (name, "incompatible argument types");
     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
       (* ok *)
@@ -39,7 +42,11 @@
       Error.Txt (name, "wrong argument types");
       ta := Int.T;
     END;
-    ce.type := ta;
+    IF resultType # NIL THEN
+      ce.type := resultType;
+    ELSE
+      ce.type := ta;
+    END;
   END DoCheck;
 
 PROCEDURE Compile (ce: CallExpr.T) =
Index: exprs/AddExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 AddExpr.m3
--- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
+++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -67,6 +67,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -74,8 +75,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
-      p.class := Class.cLINT
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -96,7 +98,11 @@
     ELSE
       ta := Expr.BadOperands ("\'+\'", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/DivExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 DivExpr.m3
--- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,7 +60,7 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF (ta = Int.T) AND (tb = Int.T) THEN
       p.type := Int.T;
-    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.type := LInt.T;
     ELSE
       p.type := Expr.BadOperands ("DIV", ta, tb);
Index: exprs/ModExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
retrieving revision 1.5
diff -u -r1.5 ModExpr.m3
--- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
+++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -60,6 +60,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -67,8 +68,18 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
+
     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
       p.class := Class.cLINT;
+
+    (* The result of MOD cannot be higher than either of its inputs.
+     * small divided by big is 0 remainder small
+     * big divided by small has a remainder of at most small
+     *)
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
+      p.class := Class.cINT;
+      resultType := Int.T;
+
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -78,7 +89,11 @@
     ELSE p.class := Class.cERR;  ta := Int.T;
       ta := Expr.BadOperands ("MOD", ta, tb);
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/MultiplyExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
retrieving revision 1.3
diff -u -r1.3 MultiplyExpr.m3
--- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
+++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -66,6 +66,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -73,8 +74,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
       p.class := cINT;
-    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := cLINT;
+      resultType := LInt.T;
     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
       p.class := cREAL;
     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
@@ -90,7 +92,11 @@
       ta := Expr.BadOperands ("\'*\'", ta, tb);
       p.class := cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: exprs/SubtractExpr.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
retrieving revision 1.4
diff -u -r1.4 SubtractExpr.m3
--- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
+++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
@@ -73,6 +73,7 @@
 
 PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
   VAR ta, tb, range: Type.T;
+      resultType: Type.T := NIL;
   BEGIN
     Expr.TypeCheck (p.a, cs);
     Expr.TypeCheck (p.b, cs);
@@ -80,8 +81,9 @@
     tb := Type.Base (Expr.TypeOf (p.b));
     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
       p.class := Class.cINT;
-    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
+    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
       p.class := Class.cLINT;
+      resultType := LInt.T;
     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
       p.class := Class.cREAL;
     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
@@ -113,7 +115,11 @@
       ta := Expr.BadOperands ("\'-\'", ta, tb);
       p.class := Class.cINT;
     END;
-    p.type := ta;
+    IF resultType # NIL THEN
+      p.type := resultType;
+    ELSE
+      p.type := ta;
+    END;
   END Check;
 
 PROCEDURE Prep (p: P) =
Index: types/Type.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
retrieving revision 1.8
diff -u -r1.8 Type.m3
--- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
+++ types/Type.m3 8 Jan 2010 07:35:43 -0000
@@ -543,6 +543,10 @@
     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
       RETURN TRUE;
     ELSIF IsOrdinal (a) THEN
+      (* INTEGER is assignable to LONGINT *)
+      IF a = LInt.T AND b = Int.T THEN
+        RETURN TRUE;
+      END;
       (* ordinal types:  OK if there is a common supertype
          and they have at least one member in common. *)
       IF IsEqual (Base(a), Base(b), NIL)






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

From wagner at elegosoft.com  Fri Jan  8 11:44:48 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 11:44:48 +0100
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
Message-ID: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>
>> Well, I don't think that should be any practical problem right now,
>
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems, so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>
> I think I am now persuaded LONGINT should stay.  But, I don't   
> understand what "incompatibly change the internal file length
> type (with due care and consideration of course)" means?

I only just got round to reading all those mails.

I meant changing the file lengths and offsets in all our libraries,
like Rd/Wr. Basically what Jay has started on right away ;-)

I agree that this should be done in a feature branch though.
Changes should be reviewed.
Regression tests need to be run on all platforms.

And of course we should all more or less agree that we want to do that.
I think it has been a mistake that we haven't been able to support
long file sizes in a consistent way throughout our code. Of course this
problem will vanish in some years when everybody is using 64 bit platforms.
But for embedded programming for example 32 bit processors may remain
useful and in use much longer.

I'm not sure if we should support assignability between INTEGER and
LONGINT, as Rodney's original proposal did. Probably yes, but I must
admit that I've been too little engaged in language theory for years now
so that I cannot really oversee the impacts.

Files with sizes larger than 4 GB get more and more common. Just think
of DVD images for example. And I don't think that it will be really
appreciated by users of M3 applications that they immediately crash
just because one has opened a directory browser based on the distributed
libraries :-)

Just my opinion of course. I don't really understand why you are so
drastically opposing LONGINT suddenly. Probably I haven't been able to
follow some of the arguments.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan  8 12:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 11:13:58 +0000
Subject: [M3devel] latest longint file size diffs
Message-ID: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>


Attached is my latest work here.
With the compiler changes (in the diff), I was able to
elminate most uses of VAL(expr, LONGINT).
There's something slightly off such that I had
to add a very small number, like two.

 

 

The compiler change is newer than earlier.

For example you can now assign CARDINAL to LONGINT.

I didn't do it, but you should also be able to add/subtract/etc.

mixing CARDINAL and LONGINT.

 


FOR statements also don't allow the level of mixing
that they should.


 

I'm hoping to get agreement soon just from the diffs

but if necessary I'll look how to create a branch.

My general worry about branches is developers just

go off on their own in a branch and it's impossible to

get anyone to look at it, they are busy enough with one branch,

let alone multiple..

 


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif8.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0537b9e6/attachment-0002.txt>

From wagner at elegosoft.com  Fri Jan  8 12:32:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Jan 2010 12:32:24 +0100
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <20100108123224.rryfffs1kw40k4sk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>
> The compiler change is newer than earlier.
>
> For example you can now assign CARDINAL to LONGINT.
>
> I didn't do it, but you should also be able to add/subtract/etc.
>
> mixing CARDINAL and LONGINT.
>
> FOR statements also don't allow the level of mixing
> that they should.
>
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
>
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..

I think in this case it makes sense, as we need to run full regression
tests on all target platforms IMO.

You just should mark the start of the branch with

   cvs tag branch_feature_longint_offset_start

then create the branch tag itself

   cvs tag -b branch_feature_longint_offset

update your workspace to that branch

   cvs up -r branch_feature_longint_offset

and finally commit the changes

   cvs commit

This all assumes you've started on a fairly recent trunk and
there are no conflicts.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Fri Jan  8 15:28:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 09:28:11 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <20100108142811.GA14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:44:53AM +0000, Jay K wrote:
> 
> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
> 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  

No, it was correct.

    MIN( 5, -1000000000000000L) = -1000000000000000L
    So the result really needs to be LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:08:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:08:20 -0500
Subject: [M3devel] longint..revisited?
In-Reply-To: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
References: <COL101-W47CF841206965EA37DDC68E6700@phx.gbl>
Message-ID: <49C29A52-F861-4875-A6B0-B77758F08781@cs.purdue.edu>

Again, this proposal raises serious problems regarding implicit coercions, against the design principals of the Modula-3 type system.

On 7 Jan 2010, at 22:35, Jay K wrote:

> I can't find Rodney's proposal but I think I understand
> a lot of it from today's mail.
> 
> 
> Can we revisit this?
> 
> 
> My understanding is that Rodney's proposal
> deems INTEGER assignable to LONGINT,
> and vice versa, and that assignments of LONGINT
> to INTEGER undergo runtime range checks,
> can raise exceptions.
> 
> 
> I assume it also follows that:
> 
> 
> LONGINT can be added/subtracted/modded to INTEGER,
> yielding LONGINT.
> 
> 
> INTEGER MOD LONGINT would range check the LONGINT.
> 
> 
> INC/DEC(LONGINT, INTEGER) would just work
> 
> 
> INC/DEC(INTEGER, LONGINT) would range check.
> 
> 
> The downside is that the chance for failure would be
> silently injected into various places.
> 
> 
> Another proposal would be that INTEGER is assignable to LONGINT,
> but not vice versa. I really don't see why not.
> 
> 
>    LONGINT := INTEGER  
>    LONGINT + INTEGER => LONGINT  
>    LONGINT - INTEGER => LONGINT  
>    LONGINT * INTEGER => LONGINT  
>    LONGINT / INTEGER => LONGINT  
>    LONGINT MOD INTEGER => INTEGER (think about it) 
>    INC(LONGINT, INTEGER)
>    DEC(LONGINT, INTEGER)
> 
> 
> all seem very reasonable.
> 
> 
>  - Jay
> 



From hosking at cs.purdue.edu  Fri Jan  8 17:17:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:17:07 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <D75FD9A8-3049-4942-95BD-B9DE79920AFA@cs.purdue.edu>

On 7 Jan 2010, at 23:03, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>> 
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?

A subrange always has a known base type.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?

Correct.  Here is the subtype rule for ordinals:

For ordinal types T and U, we have T <: U if they have the same base type and every member of T is a member of U. That is, subtyping on ordinal types reflects the subset relation on the value sets.

Currently, we have two possible base types for ordinals: INTEGER and LONGINT.  They are distinct, unrelated types.

>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>> 
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

It conveys specific information about what specific machine values and operations implement them.  They can (and usually do) require different code to operate on them.  From a programmer's perspective, I know that every operation on INTEGER base values will involve *natural* integer arithmetic.  For LONGINT I am much less sure, and may require even calling a library to perform the operation (if the machine doesn't naturally support LONGINT).

> 
> -- hendrik
>> 
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>> 
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>> 
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>> 
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>> 
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>> 
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>> 
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>> 
>>> -- hendrik
>> 

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

From hosking at cs.purdue.edu  Fri Jan  8 17:26:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:26:07 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468BD8.4020106@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
Message-ID: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>

On 7 Jan 2010, at 20:35, Rodney M. Bates wrote:

> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time.  That would have been October
> of 2007.  I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type.

LONGINT *is* an ordinal type.  It just has a different base type than INTEGER so it is not subtype-related.

> This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other.  This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.

The question really is what should the top type be?

We don't want to have all ordinal types base themselves on LONGINT because then they will all incur LONGINT operations (which may be more expensive than the "natural" INTEGER operations).

> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types.  Most places in the
> language require only assignability, not type equality.  Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.

I really don't see how to accomodate this within the Modula-3 type system and its existing rules.

Now, we could introduce an explicit rule that says INTEGER <: LONGINT.  Then we can freely assign INTEGER values to LONGINT values.

> A consequence of existing rules is that there would be, if necessary,
> runtime value checks.  In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.

Allowing assignment of LONGINT to INTEGER requires an implicit range check on assignment, but perhaps that is OK.

> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer.  A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT.  But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.

In this case I prefer the need for explicit conversion just so that programmers are made aware.

> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable.  This could, of course be fixed in the language,
> but I would prefer making the two types assignable.

No, there is no contradiction in the current implementation.  It treats subranges of LONGINT as having base type LONGINT.   So they are unrelated to INTEGER based types.

> 
> 
> 
> 
> Jay K wrote:
>> 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



From hosking at cs.purdue.edu  Fri Jan  8 17:27:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:27:36 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B468C63.9050404@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>
	<4B468C63.9050404@lcwb.coop>
Message-ID: <F1B2BC0B-A862-4361-8E39-88D6B0061444@cs.purdue.edu>

Agreed.

On 7 Jan 2010, at 20:37, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> On 7 Jan 2010, at 06:22, Jay K wrote:
>>> 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.
>> Again, I discourage this as not in the spirit of the Modula-3 type system which abhors implicit casts.
> Indeed, Modula-3 has no implicit casts at all.  But it does have something
> that sometimes accomplishes the same result in a way that is far simpler
> to define and represents a higher level of abstraction, namely, the
> concept of assignability.  A value, e.g. 10, can be in the value set of
> many types (INTEGER, many of its subranges, and now LONGINT and many if
> its subranges too).  If so, it can in certain carefully specified cases,
> be assigned from one of these types to another, without any syntactically
> explicit notation required of the programmer.
> 
> This represents the more abstract view that 10 is 10, as opposed to the
> usual view that 10 sitting in a byte is not the same as 10 in a word.
> Of course, at the machine level. they are not the same, but in Modula-3,
> that is only a representation matter that the compiler must take care of,
> not a high-level language matter that needs pages of rules to define.
> 
> It took me years to fully understand the implications of replacing implicit
> type conversions by the assignability concept, but I now consider it one
> of Modula-3's great ideas, even if it is a small thing.

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

From hosking at cs.purdue.edu  Fri Jan  8 17:29:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:29:33 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108035343.GA9556@topoi.pooq.com>
References: <4B4688B8.50701@lcwb.coop>
	<COL101-W312B9388647F0FE89BB196E6700@phx.gbl>
	<20100108035343.GA9556@topoi.pooq.com>
Message-ID: <303FF080-4129-4669-B264-151C32DE559F@cs.purdue.edu>

On 7 Jan 2010, at 22:53, hendrik at topoi.pooq.com wrote:

> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?

We do have + defined on LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 17:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 11:36:18 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>

I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?

Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).

On 8 Jan 2010, at 05:44, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 7 Jan 2010, at 08:52, Olaf Wagner wrote:
>> 
>>> Well, I don't think that should be any practical problem right now,
>> 
>>> shouldn't it? But 32 bit offsets have been overcome for years even
>>> on 32 bit systems, so I definitely think we should keep the LONGINT
>>> type and even try to incompatibly change the internal file length
>>> type (with due care and consideration of course).
>> 
>> I think I am now persuaded LONGINT should stay.  But, I don't  understand what "incompatibly change the internal file length
>> type (with due care and consideration of course)" means?
> 
> I only just got round to reading all those mails.
> 
> I meant changing the file lengths and offsets in all our libraries,
> like Rd/Wr. Basically what Jay has started on right away ;-)
> 
> I agree that this should be done in a feature branch though.
> Changes should be reviewed.
> Regression tests need to be run on all platforms.
> 
> And of course we should all more or less agree that we want to do that.
> I think it has been a mistake that we haven't been able to support
> long file sizes in a consistent way throughout our code. Of course this
> problem will vanish in some years when everybody is using 64 bit platforms.
> But for embedded programming for example 32 bit processors may remain
> useful and in use much longer.
> 
> I'm not sure if we should support assignability between INTEGER and
> LONGINT, as Rodney's original proposal did. Probably yes, but I must
> admit that I've been too little engaged in language theory for years now
> so that I cannot really oversee the impacts.
> 
> Files with sizes larger than 4 GB get more and more common. Just think
> of DVD images for example. And I don't think that it will be really
> appreciated by users of M3 applications that they immediately crash
> just because one has opened a directory browser based on the distributed
> libraries :-)
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Fri Jan  8 18:00:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 12:00:01 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	? T <: U, or
	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	? T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 17:49:06 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:49:06 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>	<COL101-W248A52A95757FB5EDB2B32E6710@phx.gbl>,
	<527D7354-97E5-47EB-A0FB-FDA7EE3D2B6A@cs.purdue.edu>,
	<4B468C63.9050404@lcwb.coop>
	<COL101-W38657CCBAC2F7C2DB4F6D6E6700@phx.gbl>
Message-ID: <4B476202.7010004@lcwb.coop>



Jay K wrote:
> I don't believe currently "10" is assignable
> (or comparable) to LONGINT.
> You have to use 10L.

This is a bit subtle, and I should have been more explicit.  I didn't
mean the Modula-3 expression "10", I meant just the value ten.

 From 2.2:
------------------------------------------------------------------------------
Every expression has a unique type, but a value can be a member of many types.
For example, the value 6 is a member of both [0..9] and
INTEGER.  It would be ambiguous to talk about ``the type of a value''.
Thus the phrase ``type of x'' means ``type of the expression
x'', while ``x is a member of T'' means ``the value of
x is a member of T''.
------------------------------------------------------------------------------

The snippets of Modula-3 _code_ "10" and "10L"  are expressions.  Each has
both a value (which is the same) and a type (which is different).  The value
10 is a member of both types.

The 2.2 quote was written before we had LONGINT and its literals, so referring to
the value 6 wasn't as unclear.  Maybe it would be better to say that the
value 10 when stored in an INTEGER is a different abstract value than
10 stored in a LONGINT.  Then the two types would have disjoint value
sets.  But I think that would be a serious contradiction to the way
subranges work.

>  
>  
> I do believe any INTEGER or CARDINAL expression should be assignable
> to LONGINT, but I don't think it is implemented that way currently.
>  
>  
> And, then, I wonder if subranges are all we need, no LONGINT.
> But I don't understand the language well enough.
>  
>  
>  - Jay
> 


From rodney_bates at lcwb.coop  Fri Jan  8 17:53:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 10:53:42 -0600
Subject: [M3devel] LONGINT, my original proposal
Message-ID: <4B476316.4000005@lcwb.coop>

Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 64-bitProposal
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment-0002.ksh>

From rodney_bates at lcwb.coop  Fri Jan  8 18:10:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:10:28 -0600
Subject: [M3devel] Integers
In-Reply-To: <20100108040333.GB9556@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>
Message-ID: <4B476704.8010403@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>>
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?
> 

No, this is not implicit.  An implementation can (and probably should)
store a variable of a subrange type in a byte or two, if sufficient to
hold the range.  When the programmer assigns this to an INTEGER, the
compiler will have to make a representation change.  But is has the
necessary information to do this without huge trouble.

Similarly, the implementation _must_ store a subrange in a restricted
size field when it is a field or array element having a BITS type
derived from a subrange type.

What's unique about Modula-3 is that such representation changes are
left to the compiler, while the language merely views values as
sometimes belonging to more than one type, and allows such values to be
assigned when so.  The usual approach in other languages is to elevate
the representation change from a machine-level matter to a language-
level matter by treating it as an implicit type change in addition to
a representation change.  The result is always a lot of unnecessary
complexity in the language.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?
> 
>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>>
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

One thing that is very much needed in a language (not the only thing)
is a type that always matches the implementation's native arithmetic
size, which is most efficient.  If you don't distinguish this type,
it becomes either impossible or horribly convoluted to define arithmetic
so native machine arithmetic can be usually used where possible,
but multi-word arithmetic will be used where needed.

> 
> -- hendrik
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>>
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>>
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>>
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>>
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>>
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>>
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>>
>>> -- hendrik
> 


From mika at async.async.caltech.edu  Fri Jan  8 18:34:12 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 09:34:12 -0800
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu> 
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <20100108173412.8531F1A207A@async.async.caltech.edu>

Tony Hosking writes:
...
>A type T is assignable to a type U if:
>
>	=95 T <: U, or
>	=95 U <: T and T is an array or a reference type other than =
>ADDRESS (This restriction is lifted in unsafe modules.), or
>	=95 T and U are ordinal types with at least one member in =
>common.
>
>This suggests that we don't really need to say that INTEGER <: LONGINT.
>
>We can simply rely on the third clause regarding their both being =
>ordinal types with at least one member in common.  Then assignment =
>simply needs to test that the values are in range.
>

Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
the same "member"?

By a similar argument, you could make REAL and LONGREAL assignable.
Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
the same bit patterns, same as 0 and 0L for that matter, and I can add
that the way you do single-precision floating point on Alpha is by zeroing
a big chunk in the middle of your double-precision fp registers...)

I think I am with you on removing LONGINT from the language.  The proper
way of handling file sizes (or anything else that might be a bigger number
than a machine word) is through abstraction.  I have a suspicion that it's
probably a severe micro-optimization to worry about the efficiency of
operations on file sizes.  The thought that someone is adding automatic
type conversion to Modula-3, a la C, makes me feel slightly sick to
my stomach...

I confess that my position is influenced by the fact that I have written
many programs that generate Modula-3 code as an "intermediate language".
I really really really need M3 to be easy to understand to get this to
work well.  Also being able to parse interfaces and know precisely what
they mean is important to me.  If the rules start getting sloppy.. that
would really upset me.  On the other hand this means that if I'm faced
with a problem that doesn't really fit into M3 well, say, working in
arithmetic mod 2^(wordsize), my first instinct is not to demand changes
to the language definition but to write a code generator that takes
appropriate infix (or maybe more likely prefix) code and turns it into
the appropriate calls through the Word interface.  It's a pain, yes, 
but in the long run that's the right way, because you can do so much
more with that approach than just unsigned integers.

    Mika


From rcolebur at SCIRES.COM  Fri Jan  8 18:36:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 12:36:50 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA67@ATLEX02-SRV.SCIRES.LOCAL>

I agree with Tony that we need a clean proposal to debate.  I also agree with keeping the spirit of the Modula-3 language and type rules.

Randy Coleburn

-----Original Message-----
From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Friday, January 08, 2010 12:00 PM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] mixing INTEGER and LONGINT?

Let's have a clean language proposal before thinking about implementing it...  ;-)

I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).

Looking further at the assignability rules:

A type T is assignable to a type U if:

	* T <: U, or
	* U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
	* T and U are ordinal types with at least one member in common.

This suggests that we don't really need to say that INTEGER <: LONGINT.

We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

On 8 Jan 2010, at 02:44, Jay K wrote:

> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT 
>   LONGINT - INTEGER => LONGINT 
>   LONGINT * INTEGER => LONGINT 
>   LONGINT DIV INTEGER => LONGINT 
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>   MAX(INTEGER, LONGINT) => LONGINT  
>   LONGINT := INTEGER 
>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay 
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 



From rodney_bates at lcwb.coop  Fri Jan  8 18:33:52 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 11:33:52 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
Message-ID: <4B476C80.4090601@lcwb.coop>



Jay K wrote:
> This simple diff in the front end allows the "obvious" mixing of INTEGER 
> and LONGINT without any need for ORD or VAL.
>  
>   LONGINT + INTEGER => LONGINT
>   LONGINT - INTEGER => LONGINT
>   LONGINT * INTEGER => LONGINT
>   LONGINT DIV INTEGER => LONGINT
>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should 
> be INTEGER)
>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct) 
>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct) 
>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be 
> INTEGER) 
>   MAX(INTEGER, LONGINT) => LONGINT 
>   LONGINT := INTEGER

Making INTEGER and LONGINT mutually assignable (or even one-way
assignability of INTEGER to LONGINT) implies all of the above.
The arithmetic operators are defined as generalizations of Modula-3
procedures, with parameters of VALUE mode.  And the rule for VALUE
requires only that the actual be assignable to the formal, not
have identical type.  This is what I originally proposed.

Actually, with LONGINT in the picture, the arithmetic operators have
to be defined more carefully, in order to avoid or remove ambiguity in
resolution of builtin overloaded arithmetic operators. Particularly,
we have to eliminate the possibility that, e.g., an expression of the form
INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
operator, by assignability of INTEGER to LONGINT.  This would completely
the efficiency of native machine arithmetic.

Whatever we do, I feel very strongly that we should preserve consistency
with both the existing rules that assignment statements and passing
VALUE parameters require assignability.  That means that explicitly coded
VAL/ORD functions will be required either in both assignments and mixed
arithmetic, or neither.  The same applies to a number of other places
that require assignability.


>  
> Other mixes are less obvious and would require runtime checks.
>  
> I think the backend will just work but I haven't tried that yet.
>  (Truth be told, I can only affectively edit files on NT...)
>  
> Thoughts?
>  
>  - Jay
>  
> Index: builtinOps/Dec.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
> retrieving revision 1.9
> diff -u -r1.9 Dec.m3
> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
> @@ -44,7 +44,7 @@
>      IF (NUMBER (ce.args^) > 1) THEN
>        IF Type.IsSubtype (t, LInt.T) THEN
>          t := Type.Base (Expr.TypeOf (ce.args[1]));
> -        IF (t # LInt.T) THEN
> +        IF t # LInt.T AND t # Int.T THEN
>            Error.Txt (name, "second argument must be a LONGINT");
>          END;
>        ELSE
> Index: builtinOps/Max.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
> retrieving revision 1.3
> diff -u -r1.3 Max.m3
> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
> @@ -25,11 +25,14 @@
>  
>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      ta := Type.Base (Expr.TypeOf (ce.args[0]));
>      tb := Type.Base (Expr.TypeOf (ce.args[1]));
>  
> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
> +      resultType := LInt.T;
> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>        Error.Txt (name, "incompatible argument types");
>      ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>        (* ok *)
> @@ -39,7 +42,11 @@
>        Error.Txt (name, "wrong argument types");
>        ta := Int.T;
>      END;
> -    ce.type := ta;
> +    IF resultType # NIL THEN
> +      ce.type := resultType;
> +    ELSE
> +      ce.type := ta;
> +    END;
>    END DoCheck;
>  
>  PROCEDURE Compile (ce: CallExpr.T) =
> Index: exprs/AddExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 AddExpr.m3
> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -67,6 +67,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -74,8 +75,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
> -      p.class := Class.cLINT
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -96,7 +98,11 @@
>      ELSE
>        ta := Expr.BadOperands ("\'+\'", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/DivExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 DivExpr.m3
> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,7 +60,7 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF (ta = Int.T) AND (tb = Int.T) THEN
>        p.type := Int.T;
> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.type := LInt.T;
>      ELSE
>        p.type := Expr.BadOperands ("DIV", ta, tb);
> Index: exprs/ModExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
> retrieving revision 1.5
> diff -u -r1.5 ModExpr.m3
> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -60,6 +60,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -67,8 +68,18 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> +
>      ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>        p.class := Class.cLINT;
> +
> +    (* The result of MOD cannot be higher than either of its inputs.
> +     * small divided by big is 0 remainder small
> +     * big divided by small has a remainder of at most small
> +     *)
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
> +      p.class := Class.cINT;
> +      resultType := Int.T;
> +
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -78,7 +89,11 @@
>      ELSE p.class := Class.cERR;  ta := Int.T;
>        ta := Expr.BadOperands ("MOD", ta, tb);
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/MultiplyExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
> retrieving revision 1.3
> diff -u -r1.3 MultiplyExpr.m3
> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -66,6 +66,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -73,8 +74,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>        p.class := cINT;
> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := cLINT;
> +      resultType := LInt.T;
>      ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>        p.class := cREAL;
>      ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
> @@ -90,7 +92,11 @@
>        ta := Expr.BadOperands ("\'*\'", ta, tb);
>        p.class := cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: exprs/SubtractExpr.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
> retrieving revision 1.4
> diff -u -r1.4 SubtractExpr.m3
> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
> @@ -73,6 +73,7 @@
>  
>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>    VAR ta, tb, range: Type.T;
> +      resultType: Type.T := NIL;
>    BEGIN
>      Expr.TypeCheck (p.a, cs);
>      Expr.TypeCheck (p.b, cs);
> @@ -80,8 +81,9 @@
>      tb := Type.Base (Expr.TypeOf (p.b));
>      IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>        p.class := Class.cINT;
> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>        p.class := Class.cLINT;
> +      resultType := LInt.T;
>      ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>        p.class := Class.cREAL;
>      ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
> @@ -113,7 +115,11 @@
>        ta := Expr.BadOperands ("\'-\'", ta, tb);
>        p.class := Class.cINT;
>      END;
> -    p.type := ta;
> +    IF resultType # NIL THEN
> +      p.type := resultType;
> +    ELSE
> +      p.type := ta;
> +    END;
>    END Check;
>  
>  PROCEDURE Prep (p: P) =
> Index: types/Type.m3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
> retrieving revision 1.8
> diff -u -r1.8 Type.m3
> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
> @@ -543,6 +543,10 @@
>      IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>        RETURN TRUE;
>      ELSIF IsOrdinal (a) THEN
> +      (* INTEGER is assignable to LONGINT *)
> +      IF a = LInt.T AND b = Int.T THEN
> +        RETURN TRUE;
> +      END;
>        (* ordinal types:  OK if there is a common supertype
>           and they have at least one member in common. *)
>        IF IsEqual (Base(a), Base(b), NIL)
> 
> 
> 
> 
> 
> 


From hosking at cs.purdue.edu  Fri Jan  8 19:00:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:00:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:

> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.

We have this.

> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.

>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.

> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.

We have this right now.

>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!

>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.

The current implementation illustrates that this is not a problem.

> 4. LONGINT # INTEGER.

We have this right now.

>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.

Agreed.

> 5. LONGINT is an ordinal type. 

We have this right now.

>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.

> 6. Neither LONGINT nor INTEGER is a subtype of the other.  

We have this right now.

>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.

Agreed.

> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.

We have this.

> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.

>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.

Agreed.

>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.

>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.

OK.  I think I see how to implement this...

> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.

> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.

We already support this.

> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.

Already supported.

> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.

>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.

> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.	

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.

> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.

This is the current implementation.

>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  

Agreed.

>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.

This is the current implementation.

>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.

Agreed.

> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).

> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation. 

> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.

Agreed.

> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.

>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).

> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range. 

This is the current implementation.

> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.

This is the current implementation.

> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here. 

This is the current implementation.

> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.

This is the current implementation.

> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.

We have this.

> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.

>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.

Until we see the need I hesitate to implement it.

>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.

Agreed.

> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.

I just added these.

>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.

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

From hosking at cs.purdue.edu  Fri Jan  8 19:08:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:08:46 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <3BB40DAB-60F8-461E-A9C8-FF80A81F74A8@cs.purdue.edu>

On 8 Jan 2010, at 12:34, Mika Nystrom wrote:

> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>> 
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>> 
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>> 
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>> 
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?

Yes, we could potentially do that.  It is straightforward because their significant bits are the same.

> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)

Not so reasonable, because their bits are different and need explicit conversion.

> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree with those sentiments.  While LONGINT can be accomodated (and more elegantly if we evolve towards Rodney's proposal -- see my other e-mail) I am still not convinced that it is worth all the complications.  If LONGINT is there only for large file sizes then abstraction is a *much* better way to go.  Why add a general-purpose type for a one-off use-case?

> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.

Agreed.

From hosking at cs.purdue.edu  Fri Jan  8 19:19:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:19:58 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B476C80.4090601@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<4B476C80.4090601@lcwb.coop>
Message-ID: <18553308-F36F-44B9-857F-E53B859B02C0@cs.purdue.edu>

To summarise the discussion so far...

1. Do we really need LONGINT?  Some have expressed a desire for it.  The only use-case so far is large file sizes.

2. If we do need LONGINT then Rodney's proposal seems sound apart from the question of resolution of the builtin overloaded arithmetic operators.  Rodney's proposal is that they resolve to the maximal type of their operands.  Jay, I am very concerned about your definitions for MOD/DIV below because I think they are inherently unintuitive (witness your own claims of "subtlety" -- Modula-3 should not ever have subtle semantics!).  I forget what the rules for C happen to be... (with good reason since I've never wanted to try to remember them and avoid mixed type operands like the plague!).  So, do I hear strong arguments for or against mixed type integer operands?

On 8 Jan 2010, at 12:33, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>   LONGINT + INTEGER => LONGINT
>>  LONGINT - INTEGER => LONGINT
>>  LONGINT * INTEGER => LONGINT
>>  LONGINT DIV INTEGER => LONGINT
>>  INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)
>>  INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)   MAX(INTEGER, LONGINT) => LONGINT   LONGINT := INTEGER
> 
> Making INTEGER and LONGINT mutually assignable (or even one-way
> assignability of INTEGER to LONGINT) implies all of the above.
> The arithmetic operators are defined as generalizations of Modula-3
> procedures, with parameters of VALUE mode.  And the rule for VALUE
> requires only that the actual be assignable to the formal, not
> have identical type.  This is what I originally proposed.
> 
> Actually, with LONGINT in the picture, the arithmetic operators have
> to be defined more carefully, in order to avoid or remove ambiguity in
> resolution of builtin overloaded arithmetic operators. Particularly,
> we have to eliminate the possibility that, e.g., an expression of the form
> INTEGER <op> INTEGER would resolve to the LONGINT <op> LONGINT -> LONGINT
> operator, by assignability of INTEGER to LONGINT.  This would completely
> the efficiency of native machine arithmetic.
> 
> Whatever we do, I feel very strongly that we should preserve consistency
> with both the existing rules that assignment statements and passing
> VALUE parameters require assignability.  That means that explicitly coded
> VAL/ORD functions will be required either in both assignments and mixed
> arithmetic, or neither.  The same applies to a number of other places
> that require assignability.
> 
> 
>> Other mixes are less obvious and would require runtime checks.
>> I think the backend will just work but I haven't tried that yet.
>> (Truth be told, I can only affectively edit files on NT...)
>> Thoughts?
>>  - Jay
>> Index: builtinOps/Dec.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Dec.m3,v
>> retrieving revision 1.9
>> diff -u -r1.9 Dec.m3
>> --- builtinOps/Dec.m3 25 Sep 2009 02:42:10 -0000 1.9
>> +++ builtinOps/Dec.m3 8 Jan 2010 07:35:43 -0000
>> @@ -44,7 +44,7 @@
>>     IF (NUMBER (ce.args^) > 1) THEN
>>       IF Type.IsSubtype (t, LInt.T) THEN
>>         t := Type.Base (Expr.TypeOf (ce.args[1]));
>> -        IF (t # LInt.T) THEN
>> +        IF t # LInt.T AND t # Int.T THEN
>>           Error.Txt (name, "second argument must be a LONGINT");
>>         END;
>>       ELSE
>> Index: builtinOps/Max.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/builtinOps/Max.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 Max.m3
>> --- builtinOps/Max.m3 18 Sep 2007 20:25:36 -0000 1.3
>> +++ builtinOps/Max.m3 8 Jan 2010 07:35:43 -0000
>> @@ -25,11 +25,14 @@
>>  PROCEDURE DoCheck (name: TEXT;  ce: CallExpr.T) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     ta := Type.Base (Expr.TypeOf (ce.args[0]));
>>     tb := Type.Base (Expr.TypeOf (ce.args[1]));
>> -    IF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>> +    IF (ta = LInt.T AND tb = Int.T) OR (tb = LInt.T AND ta = Int.T) THEN
>> +      resultType := LInt.T;
>> +    ELSIF (NOT Type.IsEqual (ta, tb, NIL)) THEN
>>       Error.Txt (name, "incompatible argument types");
>>     ELSIF (ta = Int.T) OR (ta = LInt.T) OR (Type.IsOrdinal (ta)) THEN
>>       (* ok *)
>> @@ -39,7 +42,11 @@
>>       Error.Txt (name, "wrong argument types");
>>       ta := Int.T;
>>     END;
>> -    ce.type := ta;
>> +    IF resultType # NIL THEN
>> +      ce.type := resultType;
>> +    ELSE
>> +      ce.type := ta;
>> +    END;
>>   END DoCheck;
>>  PROCEDURE Compile (ce: CallExpr.T) =
>> Index: exprs/AddExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/AddExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 AddExpr.m3
>> --- exprs/AddExpr.m3 4 May 2008 11:03:45 -0000 1.3
>> +++ exprs/AddExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -67,6 +67,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -74,8 +75,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T) THEN
>> -      p.class := Class.cLINT
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -96,7 +98,11 @@
>>     ELSE
>>       ta := Expr.BadOperands ("\'+\'", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/DivExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/DivExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 DivExpr.m3
>> --- exprs/DivExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/DivExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,7 +60,7 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF (ta = Int.T) AND (tb = Int.T) THEN
>>       p.type := Int.T;
>> -    ELSIF (ta = LInt.T) AND (tb = LInt.T) THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.type := LInt.T;
>>     ELSE
>>       p.type := Expr.BadOperands ("DIV", ta, tb);
>> Index: exprs/ModExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/ModExpr.m3,v
>> retrieving revision 1.5
>> diff -u -r1.5 ModExpr.m3
>> --- exprs/ModExpr.m3 4 May 2008 11:03:46 -0000 1.5
>> +++ exprs/ModExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -60,6 +60,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -67,8 +68,18 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> +
>>     ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>>       p.class := Class.cLINT;
>> +
>> +    (* The result of MOD cannot be higher than either of its inputs.
>> +     * small divided by big is 0 remainder small
>> +     * big divided by small has a remainder of at most small
>> +     *)
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>> +      p.class := Class.cINT;
>> +      resultType := Int.T;
>> +
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -78,7 +89,11 @@
>>     ELSE p.class := Class.cERR;  ta := Int.T;
>>       ta := Expr.BadOperands ("MOD", ta, tb);
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/MultiplyExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/MultiplyExpr.m3,v
>> retrieving revision 1.3
>> diff -u -r1.3 MultiplyExpr.m3
>> --- exprs/MultiplyExpr.m3 4 May 2008 11:03:46 -0000 1.3
>> +++ exprs/MultiplyExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -66,6 +66,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -73,8 +74,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (tb = Int.T)   AND (ta = Int.T)   THEN
>>       p.class := cINT;
>> -    ELSIF (tb = LInt.T)  AND (ta = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (tb = Reel.T)  AND (ta = Reel.T)  THEN
>>       p.class := cREAL;
>>     ELSIF (tb = LReel.T) AND (ta = LReel.T) THEN
>> @@ -90,7 +92,11 @@
>>       ta := Expr.BadOperands ("\'*\'", ta, tb);
>>       p.class := cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: exprs/SubtractExpr.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/SubtractExpr.m3,v
>> retrieving revision 1.4
>> diff -u -r1.4 SubtractExpr.m3
>> --- exprs/SubtractExpr.m3 4 May 2008 11:03:46 -0000 1.4
>> +++ exprs/SubtractExpr.m3 8 Jan 2010 07:35:43 -0000
>> @@ -73,6 +73,7 @@
>>  PROCEDURE Check (p: P;  VAR cs: Expr.CheckState) =
>>   VAR ta, tb, range: Type.T;
>> +      resultType: Type.T := NIL;
>>   BEGIN
>>     Expr.TypeCheck (p.a, cs);
>>     Expr.TypeCheck (p.b, cs);
>> @@ -80,8 +81,9 @@
>>     tb := Type.Base (Expr.TypeOf (p.b));
>>     IF    (ta = Int.T)   AND (tb = Int.T)   THEN
>>       p.class := Class.cINT;
>> -    ELSIF (ta = LInt.T)  AND (tb = LInt.T)  THEN
>> +    ELSIF (ta = LInt.T OR ta = Int.T) AND (tb = LInt.T OR tb = Int.T) THEN
>>       p.class := Class.cLINT;
>> +      resultType := LInt.T;
>>     ELSIF (ta = Reel.T)  AND (tb = Reel.T)  THEN
>>       p.class := Class.cREAL;
>>     ELSIF (ta = LReel.T) AND (tb = LReel.T) THEN
>> @@ -113,7 +115,11 @@
>>       ta := Expr.BadOperands ("\'-\'", ta, tb);
>>       p.class := Class.cINT;
>>     END;
>> -    p.type := ta;
>> +    IF resultType # NIL THEN
>> +      p.type := resultType;
>> +    ELSE
>> +      p.type := ta;
>> +    END;
>>   END Check;
>>  PROCEDURE Prep (p: P) =
>> Index: types/Type.m3
>> ===================================================================
>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/types/Type.m3,v
>> retrieving revision 1.8
>> diff -u -r1.8 Type.m3
>> --- types/Type.m3 4 May 2008 11:03:49 -0000 1.8
>> +++ types/Type.m3 8 Jan 2010 07:35:43 -0000
>> @@ -543,6 +543,10 @@
>>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>>       RETURN TRUE;
>>     ELSIF IsOrdinal (a) THEN
>> +      (* INTEGER is assignable to LONGINT *)
>> +      IF a = LInt.T AND b = Int.T THEN
>> +        RETURN TRUE;
>> +      END;
>>       (* ordinal types:  OK if there is a common supertype
>>          and they have at least one member in common. *)
>>       IF IsEqual (Base(a), Base(b), NIL)

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

From rcolebur at SCIRES.COM  Fri Jan  8 19:20:50 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Fri, 8 Jan 2010 13:20:50 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>

Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in "cm3/doc" and the language posters in "cm3/doc/src_reports".

Randy Coleburn


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Friday, January 08, 2010 1:01 PM
To: Rodney M. Bates
Cc: m3devel
Subject: Re: [M3devel] LONGINT, my original proposal

We already have much of this, but not all.  Notes below...

I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.

I am looking into making the changes to the current implementation that will bring this into being.

On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:


Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
aspects of this I quickly changed, either because I changed my mind on something,
or realized something was a specification bug.  I am working on rediscovering what
they were.
A proposal for Modula-3 language changes to support an integer type
larger than the native size of the target processor.

This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.

Actual statements about the language are numbered.  Comments are
indented more deeply, following a numbered item they apply to.  Some
numbered items are labeled "NO CHANGE", and merely call attention to
the lack of a change, where it is relevant or calls for comment.

Changes to the language proper:

1. There is a new builtin type named LONGINT.

We have this.


2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).

Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


     The intent is that INTEGER will remain as the native integer
     size on the implemented processor.  LONGINT might be bigger, but
     not necessarily.  Typically, on a 32-bit processor, LONGINT
     would be 64 bits.  On a 64-bit processor, it could be 64 or 128.

This is what we currently have.


3. There are new literals of type LONGINT, denoted by following a
   nonempty sequence of digits by either 'l' or 'L'.

We have this right now.


     Having distinctly spelled literals preserves Modula-3's clean
     system of referentially transparent typing, i.e, the type of
     every expression is determined by the expression alone, without
     regard to how it is used.  The 3 floating point types already
     follow this principle.  Literals of ambiguous type, combined
     with a system of implicit conversions taken from the context
     would create a semantic mess.  (e.g. Ada).

I wholeheartedly agree!


     I believe intuitively that Id, LOCK, and LOOP are not members of
     FOLLOW(Number), but need to check this mechanically.  It would
     mean that the new literals can not undermine any existing,
     compilable code.

The current implementation illustrates that this is not a problem.


4. LONGINT # INTEGER.

We have this right now.


     This is true regardless of whether their ranges are equal.  This
     keeps the typing independent of the implementation.  Doing
     otherwise could be a portability nightmare.

Agreed.


5. LONGINT is an ordinal type.

We have this right now.


     This means the existing rules of assignability will allow
     assignment between LONGINT and its subtypes and INTEGER and its
     subtypes, with the usual runtime value check, when required.

I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.


6. Neither LONGINT nor INTEGER is a subtype of the other.

We have this right now.


     This is true regardless of whether their ranges are equal, in
     part for the same reason the types are unequal.

     Note that, for ordinal types, assignability doesn't actually use
     the subtype relation.  In fact, the one place I can find in the
     present language where subtypes matter for ordinal types is in
     the definition of signatures of operators, etc.  In 2.6.1,
     paragraph 5, operands must have a subtype of the type specified.
     Keeping LONGINT and INTEGER subtype-unrelated keeps this
     statement unambiguous and allows easy specification of the
     operators.

Agreed.


7. Prefix operators +, -, and ABS can take an operand having a
   subtype of LONGINT, in which case, their result has type LONGINT.

We have this.


8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.
   If either is a subtype of LONGINT, the result has type LONGINT,
   otherwise INTEGER.  The result is correct (i.e., no overflow
   occurs) if the result value is a member of the result type.

I am uneasy about mixing parameter types in this way.
I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.


     With assignment between different subranges, Modula-3 takes the
     view that this is not an implied type conversion at all.
     Instead, the rules have the effect that if the value is a member
     of the LHS type, then it's OK.  I think this is a brilliant
     piece of language design.  Compare to the many pages of
     description that C++ and Java require to define implied type
     conversions in assignments, and they only have a few
     integer-like types, whereas current Modula-3 has, typically,
     ~2^31 subrange types involved.  It's also less
     implementation-oriented, because it doesn't appeal to bit
     representations, etc.

Agreed.


     I resisted allowing mixed sizes of operands, until I realized we
     can do the same thing with operators as with assignment, i.e.,
     just require result values to be in range, without calling
     anything an implied type conversion.

This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.


     A compiler can implement this by just doing the arithmetic in
     the same size as the result type.  This means if both operands
     are subtypes of INTEGER, (which will always be the case with
     existing code,) then the native arithmetic will be used, without
     loss of efficiency.

OK.  I think I see how to implement this...


9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
   operands that are subtypes of a mixture of INTEGER and LONGINT.

     Again, a compiler can figure out how to generate code for this,
     with no loss of efficiency when both are subtypes of INTEGER.

Same as above.  I think it can be implemented.


10. The first parameter to FLOAT can have a subtype of either INTEGER
   or LONGINT.

We already support this.


11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
   parameter, which can be either LONGINT or INTEGER, and which
   specifies the result type of the operation.  If omitted, it
   defaults to INTEGER.  The result has this type.

     The default preserves existing code.

Already supported.


12. The result type of ORD is LONGINT if the parameter is a subtype of
   LONGINT, otherwise it remains INTEGER.

The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.


     There is really not much programmer value in applying ORD to a
     subtype of either INTEGER or LONGINT, since this is just an
     identity on the value.  It would provide an explicit, widening
     type conversion, and NARROW won't accomplish this, because it is
     only defined on reference types.  However, this rule provides
     consistency, and maybe would simplify some machine-generated
     source code scheme.

     This fails to support an implementation's effort to expand the
     number of values of an enumeration type beyond the current
     implied limitation of the positive native word values.  How
     tough.

I see no problem with the maximum enumeration type values being restricted to natural integers.


13. The first parameter to VAL can be a subtype of either INTEGER or
   LONGINT.

     Beside generalizing the existing uses of VAL, this also allows
     explicit conversions between LONGINT and INTEGER, if there is
     any need for them.

The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.


14. (NO CHANGE) The safe definitions of INC and DEC do not change.

     As a consequence of the changes to +, -, ORD, and VAL, the
     existing equivalent WITH-statement definition will generalize to
     mixes of any ordinal type for the first parameter and a subtype
     of either INTEGER or LONGINT for the second.

[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
The current implementation does not allow mixing INTEGER/LONGINT operand and increments.

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.

Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?


16. Neither LONGINT, nor any subtype thereof, can be used as the index
   type of an array type.

This is the current implementation.


     One could think about allowing this, but it would require a lot
     of other things to be generalized, and is unlikely to be of much
     use.

Agreed.


     After the world's having had to learn twice the hard way, what a
     mess that comes from addresses that are larger than the native
     arithmetic size, we are unlikely to see it again.  So, the only
     ways a longer LONGINT index type could be of any use are: 1)
     arrays of elements no bigger than a byte, that occupy more than
     half the entire addressable memory, and you want to avoid
     negative index values, or 2) arrays of packed elements less than
     byte size that occupy at least one eighth of the memory (or some
     mixture thereof).  All these cases also can occur only when
     using close to the maximum addressable virtual memory.  Not very
     likely.

     If you really need 64-bit array subscripts, you will have to use
     an implementation whose native size is 64 bits.

     This also avoids generalizing SUBARRAY, several procedures in
     required interface TEXT, more extensive generalization of
     NUMBER, etc.

17. Neither LONGINT, nor any subtype thereof, can be used as the base
   type of a set type.

This is the current implementation.


     This is similar to the array index limitation.  Sets on base
     types of long range are very unlikely, as they would be too bit.
     The assignability rules should make subranges of INTEGER
     relatively easy to use as set base types instead of short
     subranges of LONGINT.  This also obviates generalizing IN.

Agreed.


18. The result type of NUMBER is LONGCARD if its parameter is a
   subtype of LONGINT, otherwise INTEGER, as currently.

     NUMBER has always had the messy problem that its correct value
     can lie beyond the upper limit of its result type CARDINAL.
     Fortunately, it is rare to use it in cases where this happens.
     The expanded definition still has the equivalent problem, but it
     seems even less likely to actually happen.

     One could consider making NUMBER always return a LONGCARD, which
     would fix the problem for parameters that are INTEGER, but that
     would not preserve existing semantics or efficiency.

The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).


19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.

This is the current implementation.


     If you really need 64-bit sizes or typecodes, you will have to
     use an implementation whose native size is 64 bits.

Agreed.


20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).

Agreed.


     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.

The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


Changes to required (AKA standard) interfaces:

21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
   Word.Rotate, and the CARDINAL parameters of Word.Extract and
   Word.Insert are unchanged.

     These are bit numbers.  There is no need for a longer range.

This is the current implementation.


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.

This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?


     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.

This is the current implementation.


23. (NO CHANGE) The Base and Precision values in required interfaces
   Real, LongReal, and Extended, keep the type INTEGER.

      There is no need for increased value range here.

This is the current implementation.


24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
    and Float.ILogb, whose result type is INTEGER, do not have LONGINT
    counterparts.

      It is difficult to imagine these values needing greater range.

This is the current implementation.


25. Fmt has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


26. Lex has a new function LongInt, parallel to Int, but replacing
   INTEGER by LONGINT.

We have this.


27. There is a new required interface named LongAddress.  It is UNSAFE
   and contains procedures that are equivalents for the 5 unsafe
   ADDRESS arithmetic operations, with LONGINT substituted in place
   of INTEGER in their signatures.  These are given in 2.7 and
   include a +, two overloaded meanings of -, an INC, and a DEC.

We currently do not support this.


     It is remotely conceivable that there could be a target whose
     native address size is longer than its native integer size
     (unlike the reverse.)  In such a case, these operations might be
     needed.

Until we see the need I hesitate to implement it.


     Four of them could be accommodated by just generalizing the
     INTEGER parameter to allow either INTEGER or LONGINT.  The
     remaining operator subtracts two ADDRESS operands and returns an
     INTEGER.  This can't be generalized using Modula-3's existing
     pattern of overload resolution of builtin operations.
     Redefining it to always do LONGINT arithmetic would violate the
     existing efficiency criterion.  Two separate operations are
     needed.

     This solution avoids complexity in the language proper, while
     still accommodating a rare requirement.  It could probably be
     left unimplemented unless/until such a target actually happens.

Agreed.


Changes to useful interfaces:

28. IO has new procedures PutLongInt and GetLongInt, parallel to
   PutInt and GetInt.

I just added these.


     I have not looked systematically at all the useful interfaces
     for other places that use CARDINAL and INTEGER and might need to
     be generalized.  (Can anyone point to a tool that will grep
     files in .ps or .pdf format, or something equivalent?)

     Note that changes in nonrequired interfaces should be
     implementable just by writing new/modified library code, without
     additional help from the compiler.

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

From hosking at cs.purdue.edu  Fri Jan  8 19:25:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 13:25:10 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FA83@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <4020F84F-CF80-4C0B-8586-FD7D7AD8F052@cs.purdue.edu>

I've already made changes to cm3/doc/reference that match the current implementation (no implicit assignability).  I'm happy to adjust that to match what we eventually implement.

On 8 Jan 2010, at 13:20, Randy Coleburn wrote:

> Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in ?cm3/doc? and the language posters in ?cm3/doc/src_reports?.
>  
> Randy Coleburn
> 
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Friday, January 08, 2010 1:01 PM
> To: Rodney M. Bates
> Cc: m3devel
> Subject: Re: [M3devel] LONGINT, my original proposal
>  
> We already have much of this, but not all.  Notes below...
>  
> I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.
>  
> I am looking into making the changes to the current implementation that will bring this into being.
>  
> On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:
> 
> 
> Here is my orginal LONGINT proposal, from my own disk file.  There were one or two
> aspects of this I quickly changed, either because I changed my mind on something,
> or realized something was a specification bug.  I am working on rediscovering what
> they were.
> A proposal for Modula-3 language changes to support an integer type
> larger than the native size of the target processor.
> 
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> Actual statements about the language are numbered.  Comments are
> indented more deeply, following a numbered item they apply to.  Some
> numbered items are labeled "NO CHANGE", and merely call attention to
> the lack of a change, where it is relevant or calls for comment.
> 
> Changes to the language proper: 
> 
> 1. There is a new builtin type named LONGINT.
>  
> We have this.
> 
> 
> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>  
> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
>      The intent is that INTEGER will remain as the native integer
>      size on the implemented processor.  LONGINT might be bigger, but
>      not necessarily.  Typically, on a 32-bit processor, LONGINT
>      would be 64 bits.  On a 64-bit processor, it could be 64 or 128.
>  
> This is what we currently have.
> 
> 
> 3. There are new literals of type LONGINT, denoted by following a
>    nonempty sequence of digits by either 'l' or 'L'.
>  
> We have this right now.
> 
> 
>      Having distinctly spelled literals preserves Modula-3's clean
>      system of referentially transparent typing, i.e, the type of
>      every expression is determined by the expression alone, without
>      regard to how it is used.  The 3 floating point types already
>      follow this principle.  Literals of ambiguous type, combined
>      with a system of implicit conversions taken from the context 
>      would create a semantic mess.  (e.g. Ada).
>  
> I wholeheartedly agree!
> 
> 
>      I believe intuitively that Id, LOCK, and LOOP are not members of
>      FOLLOW(Number), but need to check this mechanically.  It would
>      mean that the new literals can not undermine any existing,
>      compilable code.
>  
> The current implementation illustrates that this is not a problem.
> 
> 
> 4. LONGINT # INTEGER.
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal.  This
>      keeps the typing independent of the implementation.  Doing
>      otherwise could be a portability nightmare.
>  
> Agreed.
> 
> 
> 5. LONGINT is an ordinal type.
>  
> We have this right now.
> 
> 
>      This means the existing rules of assignability will allow
>      assignment between LONGINT and its subtypes and INTEGER and its
>      subtypes, with the usual runtime value check, when required.
>  
> I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.
> 
> 
> 6. Neither LONGINT nor INTEGER is a subtype of the other.  
>  
> We have this right now.
> 
> 
>      This is true regardless of whether their ranges are equal, in
>      part for the same reason the types are unequal.
> 
>      Note that, for ordinal types, assignability doesn't actually use
>      the subtype relation.  In fact, the one place I can find in the
>      present language where subtypes matter for ordinal types is in
>      the definition of signatures of operators, etc.  In 2.6.1,
>      paragraph 5, operands must have a subtype of the type specified.
>      Keeping LONGINT and INTEGER subtype-unrelated keeps this
>      statement unambiguous and allows easy specification of the
>      operators.
>  
> Agreed.
> 
> 
> 7. Prefix operators +, -, and ABS can take an operand having a
>    subtype of LONGINT, in which case, their result has type LONGINT.
>  
> We have this.
> 
> 
> 8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
>    If either is a subtype of LONGINT, the result has type LONGINT,
>    otherwise INTEGER.  The result is correct (i.e., no overflow
>    occurs) if the result value is a member of the result type.
>  
> I am uneasy about mixing parameter types in this way.
> I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.
> 
> 
>      With assignment between different subranges, Modula-3 takes the
>      view that this is not an implied type conversion at all.
>      Instead, the rules have the effect that if the value is a member
>      of the LHS type, then it's OK.  I think this is a brilliant
>      piece of language design.  Compare to the many pages of
>      description that C++ and Java require to define implied type
>      conversions in assignments, and they only have a few
>      integer-like types, whereas current Modula-3 has, typically,
>      ~2^31 subrange types involved.  It's also less
>      implementation-oriented, because it doesn't appeal to bit
>      representations, etc.
>  
> Agreed.
> 
> 
>      I resisted allowing mixed sizes of operands, until I realized we
>      can do the same thing with operators as with assignment, i.e.,
>      just require result values to be in range, without calling
>      anything an implied type conversion.
>  
> This is part of my uneasiness.  I guess I am willing to accept that the type of the operation is the maximal type of its operands.
> 
> 
>      A compiler can implement this by just doing the arithmetic in
>      the same size as the result type.  This means if both operands
>      are subtypes of INTEGER, (which will always be the case with
>      existing code,) then the native arithmetic will be used, without
>      loss of efficiency.
>  
> OK.  I think I see how to implement this...
> 
> 
> 9. Relational operators =, #, <, >, <=, and >=, can accept a pair of
>    operands that are subtypes of a mixture of INTEGER and LONGINT.
> 
>      Again, a compiler can figure out how to generate code for this,
>      with no loss of efficiency when both are subtypes of INTEGER.
>  
> Same as above.  I think it can be implemented.
> 
> 
> 10. The first parameter to FLOAT can have a subtype of either INTEGER
>    or LONGINT.
>  
> We already support this.
> 
> 
> 11. FLOOR, CEILING, ROUND, and TRUNC have an optional second
>    parameter, which can be either LONGINT or INTEGER, and which
>    specifies the result type of the operation.  If omitted, it
>    defaults to INTEGER.  The result has this type.
> 
>      The default preserves existing code.
>  
> Already supported.
> 
> 
> 12. The result type of ORD is LONGINT if the parameter is a subtype of
>    LONGINT, otherwise it remains INTEGER.
>  
> The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.
> If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.
> 
> 
>      There is really not much programmer value in applying ORD to a
>      subtype of either INTEGER or LONGINT, since this is just an
>      identity on the value.  It would provide an explicit, widening
>      type conversion, and NARROW won't accomplish this, because it is
>      only defined on reference types.  However, this rule provides
>      consistency, and maybe would simplify some machine-generated
>      source code scheme.
> 
>      This fails to support an implementation's effort to expand the
>      number of values of an enumeration type beyond the current
>      implied limitation of the positive native word values.  How
>      tough.
>  
> I see no problem with the maximum enumeration type values being restricted to natural integers.
> 
> 
> 13. The first parameter to VAL can be a subtype of either INTEGER or
>    LONGINT.
> 
>      Beside generalizing the existing uses of VAL, this also allows
>      explicit conversions between LONGINT and INTEGER, if there is
>      any need for them.
>  
> The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.
> Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.
> 
> 
> 14. (NO CHANGE) The safe definitions of INC and DEC do not change.
> 
>      As a consequence of the changes to +, -, ORD, and VAL, the
>      existing equivalent WITH-statement definition will generalize to
>      mixes of any ordinal type for the first parameter and a subtype
>      of either INTEGER or LONGINT for the second.
>  
> [Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]
> The current implementation does not allow mixing INTEGER/LONGINT operand and increments.
>  
> 15. There is a new builtin type named LONGCARD.  It "behaves just
>    like" (but is not equal to) [0..LAST(LONGINT)].
> 
>      The current CARDINAL has an interesting history.  Originally, it
>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>      was later changed to be "just like" the subrange, i.e., the two
>      are not the same type, but have the same properties in every
>      other respect.  The only reason for the change had to do with
>      reading pickles, which are completely defined and implemented as
>      library code.  The change did affect the type analysis of the
>      language, nevertheless.
> 
>      We should preserve this property for LONGCARD too.
>  
> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> 
> 16. Neither LONGINT, nor any subtype thereof, can be used as the index
>    type of an array type.
>  
> This is the current implementation.
> 
> 
>      One could think about allowing this, but it would require a lot
>      of other things to be generalized, and is unlikely to be of much
>      use.  
>  
> Agreed.
> 
> 
>      After the world's having had to learn twice the hard way, what a
>      mess that comes from addresses that are larger than the native
>      arithmetic size, we are unlikely to see it again.  So, the only
>      ways a longer LONGINT index type could be of any use are: 1)
>      arrays of elements no bigger than a byte, that occupy more than
>      half the entire addressable memory, and you want to avoid
>      negative index values, or 2) arrays of packed elements less than
>      byte size that occupy at least one eighth of the memory (or some
>      mixture thereof).  All these cases also can occur only when
>      using close to the maximum addressable virtual memory.  Not very
>      likely.
> 
>      If you really need 64-bit array subscripts, you will have to use
>      an implementation whose native size is 64 bits.
> 
>      This also avoids generalizing SUBARRAY, several procedures in
>      required interface TEXT, more extensive generalization of
>      NUMBER, etc.
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>    type of a set type.
>  
> This is the current implementation.
> 
> 
>      This is similar to the array index limitation.  Sets on base
>      types of long range are very unlikely, as they would be too bit.
>      The assignability rules should make subranges of INTEGER
>      relatively easy to use as set base types instead of short
>      subranges of LONGINT.  This also obviates generalizing IN.
>  
> Agreed.
> 
> 
> 18. The result type of NUMBER is LONGCARD if its parameter is a
>    subtype of LONGINT, otherwise INTEGER, as currently.
> 
>      NUMBER has always had the messy problem that its correct value
>      can lie beyond the upper limit of its result type CARDINAL.
>      Fortunately, it is rare to use it in cases where this happens.
>      The expanded definition still has the equivalent problem, but it
>      seems even less likely to actually happen.
> 
>      One could consider making NUMBER always return a LONGCARD, which
>      would fix the problem for parameters that are INTEGER, but that
>      would not preserve existing semantics or efficiency.
>  
> The current implementation leaves the result of NUMBER as CARDINAL.  The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).
> 
> 
> 19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.
>  
> This is the current implementation. 
>  
> 
>      If you really need 64-bit sizes or typecodes, you will have to
>      use an implementation whose native size is 64 bits.
>  
> Agreed.
> 
> 
> 20. The statement that the upperbound of a FOR loop should not be
>    LAST(INTEGER) also applies to LAST(LONGINT).
>  
> Agreed.
> 
> 
>      Note that the existing definition of FOR otherwise generalizes
>      to LONGINT without change.
>  
> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
> 
> 
> Changes to required (AKA standard) interfaces:
> 
> 21. (NO CHANGE).  The INTEGER parameters to Word.Shift and
>    Word.Rotate, and the CARDINAL parameters of Word.Extract and
>    Word.Insert are unchanged.
> 
>      These are bit numbers.  There is no need for a longer range.
>  
> This is the current implementation.
> 
> 
> 22. There is a new required interface LongWord.  It almost exactly
>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>    new functions ToWord and FromWord, that conversion between the two
>    types, using unsigned interpretations of the values.  ToInt may
>    produce a checked runtime error, if the result value is not in the
>    range of an unsigned interpretation of INTEGER.
>  
> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> 
>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>      consistency.  This means simple assignability tests and
>      assignments between the types will use signed interpretations.
>      So different functions are needed to do size changes with
>      unsigned interpretation.
>  
> This is the current implementation.
> 
> 
> 23. (NO CHANGE) The Base and Precision values in required interfaces
>    Real, LongReal, and Extended, keep the type INTEGER.
> 
>       There is no need for increased value range here.
>  
> This is the current implementation.
> 
> 
> 24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,
>     and Float.ILogb, whose result type is INTEGER, do not have LONGINT
>     counterparts.
> 
>       It is difficult to imagine these values needing greater range.
>  
> This is the current implementation.
> 
> 
> 25. Fmt has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 26. Lex has a new function LongInt, parallel to Int, but replacing
>    INTEGER by LONGINT.
>  
> We have this.
> 
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>    and contains procedures that are equivalents for the 5 unsafe
>    ADDRESS arithmetic operations, with LONGINT substituted in place
>    of INTEGER in their signatures.  These are given in 2.7 and
>    include a +, two overloaded meanings of -, an INC, and a DEC.
>  
> We currently do not support this.
> 
> 
>      It is remotely conceivable that there could be a target whose
>      native address size is longer than its native integer size
>      (unlike the reverse.)  In such a case, these operations might be
>      needed.
>  
> Until we see the need I hesitate to implement it.
> 
> 
>      Four of them could be accommodated by just generalizing the
>      INTEGER parameter to allow either INTEGER or LONGINT.  The
>      remaining operator subtracts two ADDRESS operands and returns an
>      INTEGER.  This can't be generalized using Modula-3's existing
>      pattern of overload resolution of builtin operations.
>      Redefining it to always do LONGINT arithmetic would violate the
>      existing efficiency criterion.  Two separate operations are
>      needed.
> 
>      This solution avoids complexity in the language proper, while
>      still accommodating a rare requirement.  It could probably be 
>      left unimplemented unless/until such a target actually happens.
>  
> Agreed.
> 
> 
> Changes to useful interfaces: 
> 
> 28. IO has new procedures PutLongInt and GetLongInt, parallel to
>    PutInt and GetInt.
>  
> I just added these.
> 
> 
>      I have not looked systematically at all the useful interfaces
>      for other places that use CARDINAL and INTEGER and might need to
>      be generalized.  (Can anyone point to a tool that will grep
>      files in .ps or .pdf format, or something equivalent?)
> 
>      Note that changes in nonrequired interfaces should be
>      implementable just by writing new/modified library code, without
>      additional help from the compiler.
>  

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

From hendrik at topoi.pooq.com  Fri Jan  8 19:34:17 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:34:17 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B476316.4000005@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
Message-ID: <20100108183416.GC14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:53:42AM -0600, Rodney M. Bates wrote:
> 
> 17. Neither LONGINT, nor any subtype thereof, can be used as the base
>     type of a set type.
> 
>       This is similar to the array index limitation.  Sets on base
>       types of long range are very unlikely, as they would be too bit.

"too big", not "too bit"

>       The assignability rules should make subranges of INTEGER
>       relatively easy to use as set base types instead of short
>       subranges of LONGINT.  This also obviates generalizing IN.
> 
> 27. There is a new required interface named LongAddress.  It is UNSAFE
>     and contains procedures that are equivalents for the 5 unsafe
>     ADDRESS arithmetic operations, with LONGINT substituted in place
>     of INTEGER in their signatures.  These are given in 2.7 and
>     include a +, two overloaded meanings of -, an INC, and a DEC.
> 
>       It is remotely conceivable that there could be a target whose
>       native address size is longer than its native integer size
>       (unlike the reverse.)  In such a case, these operations might be
>       needed.

The IBM 360 had three-byte addresses, but a four-byte integer.
However, they had to be four-byte aligned, and were usually handled 
using four-byte operations.  However, OS code (in assembler) often 
stuffer various non-address flags in the extra byte, so except for 
its massive obsolescence, this would be a real consideration.  The IBM 
370 had special instructions for loading and storing the three address 
bytes of a machine word, making this a little cleaner.  I'm told a later 
version of this architecture switched to four-byte addresses, causing a 
very expensive rewrite of a huge amount of code.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 19:54:53 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:54:53 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108114448.3fukoteb40og04og@mail.elegosoft.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
Message-ID: <20100108185453.GD14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
> 
> Just my opinion of course. I don't really understand why you are so
> drastically opposing LONGINT suddenly. Probably I haven't been able to
> follow some of the arguments.

I could understand opposition to LONGINT if it were based on it being a 
kludge stuck in to quickly patch a problem while we spend time thinking 
about the real, elegant solution.  And having two types like INTEGER and 
LONGINT without one being a subrange of the other seems like a kludge to 
me, however necessary it also appears.

But let me ask a question.  Is there ever any need for a Modula 3 
compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
INTEGER is 32 bits?

(I might have asked "more than 12 bits" in the above question, but 
modern 23-bit machines may very well have 16-bit operations but not 
12-bit operations.)

-- hendrik

P.S.  As far as I know, I don't think the C standard ever specifies that 
arithmetic operations on its file offset type (Is it offset_t?  I 
forget.) have any relation whatsoever to actual file position?  As far 
as I know, it could be a count of the number of bytes to read to reach 
that position, or it could consist of cylinder, track, and sector 
numbers, or it could even be encrypted.  Fie on the C implementor that 
does any of these things, though.


From hendrik at topoi.pooq.com  Fri Jan  8 19:58:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 13:58:41 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
Message-ID: <20100108185841.GE14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
> 
> The question really is what should the top type be?
> 
> We don't want to have all ordinal types base themselves on LONGINT 
> because then they will all incur LONGINT operations (which may be more 
> expensive than the "natural" INTEGER operations).

Is it even necessary for a compiler to implement -128..127 as more than 
one byte?

-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 20:04:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 14:04:09 -0500
Subject: [M3devel] Integers
In-Reply-To: <4B476704.8010403@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
Message-ID: <20100108190409.GF14151@topoi.pooq.com>

On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> 
> What's unique about Modula-3 is that such representation changes are
> left to the compiler, while the language merely views values as
> sometimes belonging to more than one type, and allows such values to be
> assigned when so.  The usual approach in other languages is to elevate
> the representation change from a machine-level matter to a language-
> level matter by treating it as an implicit type change in addition to
> a representation change.  The result is always a lot of unnecessary
> complexity in the language.
...
...
> >
> >Where in the language is it important that INTEGER and LONGINT be 
> >different base types?  In other words, what advantages does this 
> >separation convey?
> 
> One thing that is very much needed in a language (not the only thing)
> is a type that always matches the implementation's native arithmetic
> size, which is most efficient.  If you don't distinguish this type,
> it becomes either impossible or horribly convoluted to define arithmetic
> so native machine arithmetic can be usually used where possible,
> but multi-word arithmetic will be used where needed.

Yes.  You do need this type.  And you can even call it INTEGER.  But is 
there any reason it cannot be a predefined subrange type of LONGINT?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 20:32:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:32:56 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <7743770A-2B7E-4AF7-8F6C-EC44041717AE@cs.purdue.edu>

On 8 Jan 2010, at 13:54, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
>> 
>> Just my opinion of course. I don't really understand why you are so
>> drastically opposing LONGINT suddenly. Probably I haven't been able to
>> follow some of the arguments.
> 
> I could understand opposition to LONGINT if it were based on it being a 
> kludge stuck in to quickly patch a problem while we spend time thinking 
> about the real, elegant solution.  And having two types like INTEGER and 
> LONGINT without one being a subrange of the other seems like a kludge to 
> me, however necessary it also appears.

It really is kind of a kludge invented just for large files.

> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

[0..1024] has memory representation of 16 bits.  What's the point of the question?  Values of [0..1024] are INTEGER and operations on them are INTEGER typed.

> (I might have asked "more than 12 bits" in the above question, but 
> modern 23-bit machines may very well have 16-bit operations but not 
> 12-bit operations.)
> 
> -- hendrik
> 
> P.S.  As far as I know, I don't think the C standard ever specifies that 
> arithmetic operations on its file offset type (Is it offset_t?  I 
> forget.) have any relation whatsoever to actual file position?  As far 
> as I know, it could be a count of the number of bytes to read to reach 
> that position, or it could consist of cylinder, track, and sector 
> numbers, or it could even be encrypted.  Fie on the C implementor that 
> does any of these things, though.

Right, so this argues in favor of a cleaner abstraction of file offsets rather than LONGINT.



From hosking at cs.purdue.edu  Fri Jan  8 20:33:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:33:54 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185841.GE14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<4B468BD8.4020106@lcwb.coop>
	<EECDB6D3-5E81-437C-8F82-7E7651B7647C@cs.purdue.edu>
	<20100108185841.GE14151@topoi.pooq.com>
Message-ID: <C5865D4D-441B-4410-B5A0-CA2A3F746C20@cs.purdue.edu>

They are stored as 1-byte values.  But the values of that type are INTEGERs and operated on as INTEGERs.

On 8 Jan 2010, at 13:58, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:26:07AM -0500, Tony Hosking wrote:
>> 
>> The question really is what should the top type be?
>> 
>> We don't want to have all ordinal types base themselves on LONGINT 
>> because then they will all incur LONGINT operations (which may be more 
>> expensive than the "natural" INTEGER operations).
> 
> Is it even necessary for a compiler to implement -128..127 as more than 
> one byte?
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Fri Jan  8 20:36:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 14:36:18 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108190409.GF14151@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
Message-ID: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>

On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> 
>> What's unique about Modula-3 is that such representation changes are
>> left to the compiler, while the language merely views values as
>> sometimes belonging to more than one type, and allows such values to be
>> assigned when so.  The usual approach in other languages is to elevate
>> the representation change from a machine-level matter to a language-
>> level matter by treating it as an implicit type change in addition to
>> a representation change.  The result is always a lot of unnecessary
>> complexity in the language.
> ...
> ...
>>> 
>>> Where in the language is it important that INTEGER and LONGINT be 
>>> different base types?  In other words, what advantages does this 
>>> separation convey?
>> 
>> One thing that is very much needed in a language (not the only thing)
>> is a type that always matches the implementation's native arithmetic
>> size, which is most efficient.  If you don't distinguish this type,
>> it becomes either impossible or horribly convoluted to define arithmetic
>> so native machine arithmetic can be usually used where possible,
>> but multi-word arithmetic will be used where needed.
> 
> Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> there any reason it cannot be a predefined subrange type of LONGINT?

I sense confusion here...

INTEGER is not a subrange type.
Neither is LONGINT.



From rodney_bates at lcwb.coop  Fri Jan  8 20:25:50 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:25:50 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
Message-ID: <4B4786BE.3000607@lcwb.coop>



Tony Hosking wrote:
> Let's have a clean language proposal before thinking about implementing it...  ;-)
> 
> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
> 
> Looking further at the assignability rules:
> 
> A type T is assignable to a type U if:
> 
> 	? T <: U, or
> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
> 	? T and U are ordinal types with at least one member in common.
> 
> This suggests that we don't really need to say that INTEGER <: LONGINT.

I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
but it has some additional other consequences that I considered undesirable.  I don't
remember what they were off the top of my head, but could no doubt reconstruct them,
if anybody cares.

> 
> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.

Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
do one of:

1) Say LONGINT is not an ordinal type.

2) Say that 10 and 10L are not only expressions of different types, but
    also distinct values as well.  The low values of LONGINT and the
    corresponding values of INTEGER would not be the same.

3) Alter the definition of assignability, for example to say in the third clause,
    that T and U must have the same base type as well as a member in common.

Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
also mean there would be no subranges of LONGINT and probably eliminate several
other things you might expect to come along with LONGINT.

Doing 2) Seems like a big contradiction to the way subranges work and the existing
Modula-3 philosophy of types sometimes having overlapping value sets.

Which leaves 3), which I think is the only reasonable way to do this.

If we leave this as is, it will follow that assignment statements and mixed arithmetic
are legal and work the same way as with different subranges of the same base type.
Given the liberal assignability rules we already have, I don't think this is
necessarily a bad idea, despite my general bias toward requiring more stuff to
be explicit in code.  There are about 8 or 9 places, as I recall, that would be
affected because they require only assignability.

The definitions of the arithmetic operators would have to be treated with some care
to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
arithmetic, something we absolutely must avoid.  This points out where the analogy
to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
implementation is to expand the operands to the base type and do the arithmetic
in that size.  Here, we don't want that to happen unless at least one operand is
LONGINT.

On a side note, I do not believe the analogy to the floating types applies here.
With INTEGER/LONGINT, there is a very obvious and natural equivalence between
the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
different native machine floating types.  The messiness of floating representation
means you can't assume the exactly representable reals are the same for two different
floating types, even within some restricted value range.



> 
> On 8 Jan 2010, at 02:44, Jay K wrote:
> 
>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>  
>>   LONGINT + INTEGER => LONGINT 
>>   LONGINT - INTEGER => LONGINT 
>>   LONGINT * INTEGER => LONGINT 
>>   LONGINT DIV INTEGER => LONGINT 
>>   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER) 
>>   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)  
>>   LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)  
>>   MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)  
>>   MAX(INTEGER, LONGINT) => LONGINT  
>>   LONGINT := INTEGER 
>>  
>> Other mixes are less obvious and would require runtime checks.
>>  
>> I think the backend will just work but I haven't tried that yet.
>>  (Truth be told, I can only affectively edit files on NT...)
>>  
>> Thoughts?
>>  
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:33:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:33:37 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
Message-ID: <4B478891.8010101@lcwb.coop>

Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
specific case where this community has seen significant need.  But I have a number of times
in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
new use cases will happen.  Especially, we can expect the proliferation of embedded devices
to create then.  And I really believe it can be done without a lot of violence to the
Language..

Tony Hosking wrote:
> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
> 
> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
> 
>


From rodney_bates at lcwb.coop  Fri Jan  8 20:42:09 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 08 Jan 2010 13:42:09 -0600
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108173412.8531F1A207A@async.async.caltech.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
Message-ID: <4B478A91.3090609@lcwb.coop>



Mika Nystrom wrote:
> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>>
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>>
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>>
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?
> 
> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)
> 
> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree, I hate the horrible complexities of implicit type conversions
in other languages.  But this doesn't have to be done by automatic type
conversion, just another instance of Modula-3's existing superior concept of
assignability between non-disjoint types.

> 
> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.
> 
>     Mika
> 

In my original proposal, I said:
-------------------------------------------------------------------------
This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.


-------------------------------------------------------------------------

I still believe we can do these things, and also that the changes
to the language are not too drastic.  They are mostly just more
instances of existing concepts.


From hosking at cs.purdue.edu  Fri Jan  8 21:40:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:40:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B478891.8010101@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<59DCA404-36FD-4EC0-B7AE-3FA59F3F6C4D@cs.purdue.edu>
	<4B478891.8010101@lcwb.coop>
Message-ID: <597E64CD-7805-486C-AC7B-025A117C8B4E@cs.purdue.edu>

But should we really introduce restricted range multi-word arithmetic?
Why not instead make use of a general arbitrary range type like BigInteger.T?  (see the arithmetic package)

Again, I am acting devil's advocate here...

On 8 Jan 2010, at 14:33, Rodney M. Bates wrote:

> Well I don't agree that large files sizes are the only reason to have LONGINT.  They may be the
> specific case where this community has seen significant need.  But I have a number of times
> in the past (in various programming languages) needed multi-word arithmetic.  Moreover,
> new use cases will happen.  Especially, we can expect the proliferation of embedded devices
> to create then.  And I really believe it can be done without a lot of violence to the
> Language..
> 
> Tony Hosking wrote:
>> I am opposing LONGINT now (somewhat as a devil's advocate) because we introduced it simply to solve one very small problem: file sizes larger than INTEGER.  Perhaps we would have been better off sticking with a double-INTEGER record with lo/hi fields to represent file sizes?
>> Its introduction has added significant complication to the compiler, which I am frequently stumbling over (not to mention deep questions of typing in the language, as evidenced by the controversy over assignability between INTEGER and LONGINT).
>> 

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

From hosking at cs.purdue.edu  Fri Jan  8 21:47:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:47:56 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B4786BE.3000607@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<4B4786BE.3000607@lcwb.coop>
Message-ID: <93B01681-30DB-4D5E-9429-131DCB74E794@cs.purdue.edu>

On 8 Jan 2010, at 14:25, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> Let's have a clean language proposal before thinking about implementing it...  ;-)
>> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
>> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
>> Looking further at the assignability rules:
>> A type T is assignable to a type U if:
>> 	? T <: U, or
>> 	? U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	? T and U are ordinal types with at least one member in common.
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> 
> I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
> but it has some additional other consequences that I considered undesirable.  I don't
> remember what they were off the top of my head, but could no doubt reconstruct them,
> if anybody cares.

Right, I much prefer assignability rule 3, rather than a subtype relationship.

>> We can simply rely on the third clause regarding their both being ordinal types with at least one member in common.  Then assignment simply needs to test that the values are in range.
> 
> Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
> do one of:
> 
> 1) Say LONGINT is not an ordinal type.

Not necessarily.  See my definition of ORD/VAL in the update language spec.

> 2) Say that 10 and 10L are not only expressions of different types, but
>   also distinct values as well.  The low values of LONGINT and the
>   corresponding values of INTEGER would not be the same.

I don't think we need to say they are different values (in fact, they can be converted).  VAL(10, LONGINT) = 10L.

> 3) Alter the definition of assignability, for example to say in the third clause,
>   that T and U must have the same base type as well as a member in common.

In my definition both INTEGER and LONGINT *are* ordinal types so no need to change.

> Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
> also mean there would be no subranges of LONGINT and probably eliminate several
> other things you might expect to come along with LONGINT.

Agreed.

> Doing 2) Seems like a big contradiction to the way subranges work and the existing
> Modula-3 philosophy of types sometimes having overlapping value sets.

Agreed.

> Which leaves 3), which I think is the only reasonable way to do this.

I don't see the need if both are ordinal types.  They have some values in common.  So they are assignable.

> If we leave this as is, it will follow that assignment statements and mixed arithmetic
> are legal and work the same way as with different subranges of the same base type.
> Given the liberal assignability rules we already have, I don't think this is
> necessarily a bad idea, despite my general bias toward requiring more stuff to
> be explicit in code.  There are about 8 or 9 places, as I recall, that would be
> affected because they require only assignability.

So, in the current implementation we just don't have assignability and mixed arithmetic.

> The definitions of the arithmetic operators would have to be treated with some care
> to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
> arithmetic, something we absolutely must avoid.

Correct.

> This points out where the analogy
> to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
> implementation is to expand the operands to the base type and do the arithmetic
> in that size.

But that is exactly how the current implementation works.

> Here, we don't want that to happen unless at least one operand is
> LONGINT.

So, the base type yields the correct behavior.

> On a side note, I do not believe the analogy to the floating types applies here.
> With INTEGER/LONGINT, there is a very obvious and natural equivalence between
> the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
> different native machine floating types.  The messiness of floating representation
> means you can't assume the exactly representable reals are the same for two different
> floating types, even within some restricted value range.

Yes, that is why I am leaning in your direction: assignability plus mixed arithmetic.

> 
> 
> 
>> On 8 Jan 2010, at 02:44, Jay K wrote:
>>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>>   LONGINT + INTEGER => LONGINT   LONGINT - INTEGER => LONGINT   LONGINT * INTEGER => LONGINT   LONGINT DIV INTEGER => LONGINT   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)    LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)    MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)    MAX(INTEGER, LONGINT) => LONGINT    LONGINT := INTEGER  Other mixes are less obvious and would require runtime checks.
>>> I think the backend will just work but I haven't tried that yet.
>>> (Truth be told, I can only affectively edit files on NT...)
>>> Thoughts?
>>> 
>> 



From hosking at cs.purdue.edu  Fri Jan  8 21:51:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 15:51:13 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <4B478A91.3090609@lcwb.coop>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>
	<20100108173412.8531F1A207A@async.async.caltech.edu>
	<4B478A91.3090609@lcwb.coop>
Message-ID: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>

Once more summarising the discussion so far.

*If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).

The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?

On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:

> 
> 
> Mika Nystrom wrote:
>> Tony Hosking writes:
>> ...
>>> A type T is assignable to a type U if:
>>> 
>>> 	=95 T <: U, or
>>> 	=95 U <: T and T is an array or a reference type other than =
>>> ADDRESS (This restriction is lifted in unsafe modules.), or
>>> 	=95 T and U are ordinal types with at least one member in =
>>> common.
>>> 
>>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>>> 
>>> We can simply rely on the third clause regarding their both being =
>>> ordinal types with at least one member in common.  Then assignment =
>>> simply needs to test that the values are in range.
>>> 
>> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
>> the same "member"?
>> By a similar argument, you could make REAL and LONGREAL assignable.
>> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
>> the same bit patterns, same as 0 and 0L for that matter, and I can add
>> that the way you do single-precision floating point on Alpha is by zeroing
>> a big chunk in the middle of your double-precision fp registers...)
>> I think I am with you on removing LONGINT from the language.  The proper
>> way of handling file sizes (or anything else that might be a bigger number
>> than a machine word) is through abstraction.  I have a suspicion that it's
>> probably a severe micro-optimization to worry about the efficiency of
>> operations on file sizes.  The thought that someone is adding automatic
>> type conversion to Modula-3, a la C, makes me feel slightly sick to
>> my stomach...
> 
> I agree, I hate the horrible complexities of implicit type conversions
> in other languages.  But this doesn't have to be done by automatic type
> conversion, just another instance of Modula-3's existing superior concept of
> assignability between non-disjoint types.
> 
>> I confess that my position is influenced by the fact that I have written
>> many programs that generate Modula-3 code as an "intermediate language".
>> I really really really need M3 to be easy to understand to get this to
>> work well.  Also being able to parse interfaces and know precisely what
>> they mean is important to me.  If the rules start getting sloppy.. that
>> would really upset me.  On the other hand this means that if I'm faced
>> with a problem that doesn't really fit into M3 well, say, working in
>> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
>> to the language definition but to write a code generator that takes
>> appropriate infix (or maybe more likely prefix) code and turns it into
>> the appropriate calls through the Word interface.  It's a pain, yes, but in the long run that's the right way, because you can do so much
>> more with that approach than just unsigned integers.
>>    Mika
> 
> In my original proposal, I said:
> -------------------------------------------------------------------------
> This proposal satisfies (I believe) the following principles:
> 
> The static correctness and type analysis of existing code written to
> the current language definition will not change with the new
> definition.  This also implies that the new language definition will
> not introduce new type mismatches that would make existing pickles
> unreadable.
> 
> The runtime semantics and time and space efficiency of existing code
> written to the current language definition will also not change with
> the new definition, if the native word size of the implementation does
> not change.  Of course, porting existing code to an implementation
> with different native word size can change the runtime semantics by
> changing the supported value range, with or without language change.
> 
> The static type analysis of programs written to the modified language
> definition will be independent of the implementation, particularly, of
> the native word size.  This prevents inadvertently writing code that
> is highly nonportable among different native word sizes.
> 
> The new, not-necessarily-native integer type does not extend to
> certain existing uses of INTEGER and CARDINAL that are of unlikely
> utility and would add complexity.
> 
> 
> -------------------------------------------------------------------------
> 
> I still believe we can do these things, and also that the changes
> to the language are not too drastic.  They are mostly just more
> instances of existing concepts.



From hendrik at topoi.pooq.com  Fri Jan  8 22:39:23 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:39:23 -0500
Subject: [M3devel] Integers
In-Reply-To: <2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
Message-ID: <20100108213923.GA9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
> >> 
> >> What's unique about Modula-3 is that such representation changes are
> >> left to the compiler, while the language merely views values as
> >> sometimes belonging to more than one type, and allows such values to be
> >> assigned when so.  The usual approach in other languages is to elevate
> >> the representation change from a machine-level matter to a language-
> >> level matter by treating it as an implicit type change in addition to
> >> a representation change.  The result is always a lot of unnecessary
> >> complexity in the language.
> > ...
> > ...
> >>> 
> >>> Where in the language is it important that INTEGER and LONGINT be 
> >>> different base types?  In other words, what advantages does this 
> >>> separation convey?
> >> 
> >> One thing that is very much needed in a language (not the only thing)
> >> is a type that always matches the implementation's native arithmetic
> >> size, which is most efficient.  If you don't distinguish this type,
> >> it becomes either impossible or horribly convoluted to define arithmetic
> >> so native machine arithmetic can be usually used where possible,
> >> but multi-word arithmetic will be used where needed.
> > 
> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
> > there any reason it cannot be a predefined subrange type of LONGINT?
> 
> I sense confusion here...
> 
> INTEGER is not a subrange type.

The question is not whether it is a subrange type.  It isn't.
The question is whether it could be.

> Neither is LONGINT.
> 

-- hendrik



From hosking at cs.purdue.edu  Fri Jan  8 22:47:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:47:00 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>

On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
> 
> The question is not whether it is a subrange type.  It isn't.
> The question is whether it could be.

I think that would result in major contradictions in the type system.



From mika at async.async.caltech.edu  Fri Jan  8 22:50:28 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 08 Jan 2010 13:50:28 -0800
Subject: [M3devel] Integers
In-Reply-To: <20100108213923.GA9749@topoi.pooq.com> 
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
Message-ID: <20100108215028.40A651A207A@async.async.caltech.edu>


Hendrik, do you mean:

"INTEGER is that subrange of LONGINT that happens to be efficiently 
implementable on the target architecture"?

Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
choose it as I please when I configure/compile the compiler?

    Mika

hendrik at topoi.pooq.com writes:
>On Fri, Jan 08, 2010 at 02:36:18PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 14:04, hendrik at topoi.pooq.com wrote:
>> 
>> > On Fri, Jan 08, 2010 at 11:10:28AM -0600, Rodney M. Bates wrote:
>> >> 
>> >> What's unique about Modula-3 is that such representation changes are
>> >> left to the compiler, while the language merely views values as
>> >> sometimes belonging to more than one type, and allows such values to be
>> >> assigned when so.  The usual approach in other languages is to elevate
>> >> the representation change from a machine-level matter to a language-
>> >> level matter by treating it as an implicit type change in addition to
>> >> a representation change.  The result is always a lot of unnecessary
>> >> complexity in the language.
>> > ...
>> > ...
>> >>> 
>> >>> Where in the language is it important that INTEGER and LONGINT be 
>> >>> different base types?  In other words, what advantages does this 
>> >>> separation convey?
>> >> 
>> >> One thing that is very much needed in a language (not the only thing)
>> >> is a type that always matches the implementation's native arithmetic
>> >> size, which is most efficient.  If you don't distinguish this type,
>> >> it becomes either impossible or horribly convoluted to define arithmetic
>> >> so native machine arithmetic can be usually used where possible,
>> >> but multi-word arithmetic will be used where needed.
>> > 
>> > Yes.  You do need this type.  And you can even call it INTEGER.  But is 
>> > there any reason it cannot be a predefined subrange type of LONGINT?
>> 
>> I sense confusion here...
>> 
>> INTEGER is not a subrange type.
>
>The question is not whether it is a subrange type.  It isn't.
>The question is whether it could be.
>
>> Neither is LONGINT.
>> 
>
>-- hendrik


From hendrik at topoi.pooq.com  Fri Jan  8 22:50:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 16:50:33 -0500
Subject: [M3devel] Integers
In-Reply-To: <889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
Message-ID: <20100108215033.GB9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
> >> I sense confusion here...
> >> 
> >> INTEGER is not a subrange type.
> > 
> > The question is not whether it is a subrange type.  It isn't.
> > The question is whether it could be.
> 
> I think that would result in major contradictions in the type system.

Just what would the malign consequences be?

-- hendrik


From hosking at cs.purdue.edu  Fri Jan  8 22:53:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 16:53:29 -0500
Subject: [M3devel] Integers
In-Reply-To: <20100108215033.GB9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
Message-ID: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>

Then the base type of INTEGER would be LONGINT.

Thus, INTEGER operations would incur the expense of unnatural LONGINT operations.

That is unacceptable.

On 8 Jan 2010, at 16:50, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 04:47:00PM -0500, Tony Hosking wrote:
>> On 8 Jan 2010, at 16:39, hendrik at topoi.pooq.com wrote:
>>>> I sense confusion here...
>>>> 
>>>> INTEGER is not a subrange type.
>>> 
>>> The question is not whether it is a subrange type.  It isn't.
>>> The question is whether it could be.
>> 
>> I think that would result in major contradictions in the type system.
> 
> Just what would the malign consequences be?
> 
> -- hendrik

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

From jay.krell at cornell.edu  Fri Jan  8 23:30:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Jan 2010 22:30:57 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<8E59C253-6AE7-4A5B-82B3-11DB7360FE2E@cs.purdue.edu>,
	<20100108173412.8531F1A207A@async.async.caltech.edu>,
	<4B478A91.3090609@lcwb.coop>,
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
Message-ID: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>


 > The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?


Two of us addressed this.

The answer is not technically/scientifically pleasing.
The answer is simply that in-fix operators are more convenient and libraries are not.

Obviously the general clean answer is either:

   operator overloading on user defined types, making the library convenient 

   or maybe a language feature for fixed but arbitrary precision integers

    e.g. 

     int1024 = BITS 1024 for INTEGER

     or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]

     or uint1024 = [0..Word.LShift(1, 1024)]

 

 

and the compiler would be compelled to generate code for any precision.

 

 

These are both more work.

LONGINT is indeed a special case.

C compilers all provide it "long long" or "__int64".

File sizes are indeed probably the typical use case for C?

But also things like InterlockedCompareExchange64 of some "packed" format.

 

Personally I would gladly accept

 FileSize = [0..Word.LShift(1, 63 or 64)];

 

 

even so...the compiler/language feature could (initially) limit the "bits" to 64, but

still implement via this more general syntax and not some new special type/keyword.

 

 

This is the question floating around: maybe there are just integers of varying size/range.

 

 

Maybe the compiler can notice if the size is <= or > a natural size?

 

Mixed arithmetic would be possible among arbitrary pairs of sizes and have a simple

formula for the result. Assuming "silent wraparound", addition would just pick the larger of the two.

But then, what if I assign to an even larger type? Hm.

Then you want addition of n and m to produce max(n, m) + 1, and such.

Perhaps there is some rule..you know..checked narrowing..?

And the checks can be omitted if the assignment is to a larger type?

e.g.

LONGINT := INTEGER + INTEGER => no overflow check

LONGINT := LONGINT + LONGINT => overflow check

int1024 := LONGINT + LONGINT => no overflow check

?

 

 

In reality I think no code would use the wider := narrow + narrow.

But it seems technically reasonable.

 

 

In reality code either wants the overflow check, or a type that expands its precision as needed.

("bignum", etc.)

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 15:51:13 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] mixing INTEGER and LONGINT?
> 
> Once more summarising the discussion so far.
> 
> *If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).
> 
> The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?
> 
> On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:
> 
> > 
> > 
> > Mika Nystrom wrote:
> >> Tony Hosking writes:
> >> ...
> >>> A type T is assignable to a type U if:
> >>> 
> >>> =95 T <: U, or
> >>> =95 U <: T and T is an array or a reference type other than =
> >>> ADDRESS (This restriction is lifted in unsafe modules.), or
> >>> =95 T and U are ordinal types with at least one member in =
> >>> common.
> >>> 
> >>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> >>> 
> >>> We can simply rely on the third clause regarding their both being =
> >>> ordinal types with at least one member in common. Then assignment =
> >>> simply needs to test that the values are in range.
> >>> 
> >> Are you sure about this for INTEGER and LONGINT? I.e., are 0 and 0L
> >> the same "member"?
> >> By a similar argument, you could make REAL and LONGREAL assignable.
> >> Are 0.0d0 and 0.0e0 the same "thing"? (On almost all machines they have
> >> the same bit patterns, same as 0 and 0L for that matter, and I can add
> >> that the way you do single-precision floating point on Alpha is by zeroing
> >> a big chunk in the middle of your double-precision fp registers...)
> >> I think I am with you on removing LONGINT from the language. The proper
> >> way of handling file sizes (or anything else that might be a bigger number
> >> than a machine word) is through abstraction. I have a suspicion that it's
> >> probably a severe micro-optimization to worry about the efficiency of
> >> operations on file sizes. The thought that someone is adding automatic
> >> type conversion to Modula-3, a la C, makes me feel slightly sick to
> >> my stomach...
> > 
> > I agree, I hate the horrible complexities of implicit type conversions
> > in other languages. But this doesn't have to be done by automatic type
> > conversion, just another instance of Modula-3's existing superior concept of
> > assignability between non-disjoint types.
> > 
> >> I confess that my position is influenced by the fact that I have written
> >> many programs that generate Modula-3 code as an "intermediate language".
> >> I really really really need M3 to be easy to understand to get this to
> >> work well. Also being able to parse interfaces and know precisely what
> >> they mean is important to me. If the rules start getting sloppy.. that
> >> would really upset me. On the other hand this means that if I'm faced
> >> with a problem that doesn't really fit into M3 well, say, working in
> >> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> >> to the language definition but to write a code generator that takes
> >> appropriate infix (or maybe more likely prefix) code and turns it into
> >> the appropriate calls through the Word interface. It's a pain, yes, but in the long run that's the right way, because you can do so much
> >> more with that approach than just unsigned integers.
> >> Mika
> > 
> > In my original proposal, I said:
> > -------------------------------------------------------------------------
> > This proposal satisfies (I believe) the following principles:
> > 
> > The static correctness and type analysis of existing code written to
> > the current language definition will not change with the new
> > definition. This also implies that the new language definition will
> > not introduce new type mismatches that would make existing pickles
> > unreadable.
> > 
> > The runtime semantics and time and space efficiency of existing code
> > written to the current language definition will also not change with
> > the new definition, if the native word size of the implementation does
> > not change. Of course, porting existing code to an implementation
> > with different native word size can change the runtime semantics by
> > changing the supported value range, with or without language change.
> > 
> > The static type analysis of programs written to the modified language
> > definition will be independent of the implementation, particularly, of
> > the native word size. This prevents inadvertently writing code that
> > is highly nonportable among different native word sizes.
> > 
> > The new, not-necessarily-native integer type does not extend to
> > certain existing uses of INTEGER and CARDINAL that are of unlikely
> > utility and would add complexity.
> > 
> > 
> > -------------------------------------------------------------------------
> > 
> > I still believe we can do these things, and also that the changes
> > to the language are not too drastic. They are mostly just more
> > instances of existing concepts.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0ec29705/attachment-0002.html>

From hendrik at topoi.pooq.com  Sat Jan  9 00:05:05 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:05:05 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108215028.40A651A207A@async.async.caltech.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
Message-ID: <20100108230505.GC9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
> 
> Hendrik, do you mean:
> 
> "INTEGER is that subrange of LONGINT that happens to be efficiently 
> implementable on the target architecture"?
> 
> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
> choose it as I please when I configure/compile the compiler?
> 
>     Mika

I've just been thinking of that.  Why even have a size for LONGINT?  Why 
not allow the programmer to use only subranges of LONGINT?  The 
arithmetic operations all have the property that you can compute 
subranges for the reults given subranges for the operands.  So 
intermediate results are all bounded in size, you can compute without 
overflow happening ... until you get to narrow the final result for 
assignment to whatever variable you want to 
assign it to.

I suspect there are compiler optimisations (well, let's ne honest, 
call them ameliorations) that could be performed to move the final 
range-truncate-check backward through the series of operations and limit 
the number of unnecessary bits that have been computed.  These 
ameliorations are likely to be more effective if no range check need be 
performed on final assignment (but there's always a conflict between 
amelioration and run-time checks, isn't there?)

We could do this for LONGINT completely independent of whatever we do 
with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
INTEGER is what you use when you particularly want to use 
machine-efficient data and operations.  LONGINT is what you use when 
that's not enough, and you want to statically specify the size of 
integer you need, and pay the price.  What with machines having carry 
and overflow flags, add-with-carry instructions, it chould be possible 
to generate reasonably efficient code anyway, without the full overhead 
of run-time-determined number sizes.

Most machines already have integer multiply instructions that return a 
double-length product.  It's such a pity to waste them.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 00:11:54 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 18:11:54 -0500
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>
	<35FA329C-9EF2-4325-8C1E-CA45F88D930F@cs.purdue.edu>
	<COL101-W212F5039BAD18411808E0CE6700@phx.gbl>
Message-ID: <20100108231154.GD9749@topoi.pooq.com>

On Fri, Jan 08, 2010 at 10:30:57PM +0000, Jay K wrote:
> 
>  > The question remains: is LONGINT necessary or simply a kludge 
>  > better satisfied by arbitrary precision arithmetic like 
>  > BigInteger.T?
> 
> 
> Two of us addressed this.
> 
> The answer is not technically/scientifically pleasing.
> The answer is simply that in-fix operators are more convenient and 
> libraries are not.
> 
> Obviously the general clean answer is either:
> 
>    operator overloading on user defined types, making the library convenient 
> 
>    or maybe a language feature for fixed but arbitrary precision integers

Why not make LONGINT the base type for all these fixed but arbitrary 
precision integers.  But don't allow anyone to declare a variable of 
type LONGINT, so we never have to specify a size for it, and its 
subranges can be as large as anyone pleases.

>     e.g. 
      e.g. 
> 
> 
>      int1024 = BITS 1024 for INTEGER
       int1024 = BITS 1024 for LONGINT
 
>      or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]
       or uint1024 = BITS 1024 for [0..Word.LShift(1L, 1024)]
> 
>      or uint1024 = [0..Word.LShift(1, 1024)]
       or uint1024 = [0..Word.LShift(1L, 1024)]
> 
> and the compiler would be compelled to generate code for any precision.
> 
> These are both more work.
> 
> LONGINT is indeed a special case.

But if we let it be finite but unbounded it's a rather different special 
case.

-- hendrik


From hosking at cs.purdue.edu  Sat Jan  9 01:53:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 19:53:07 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100108230505.GC9749@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
Message-ID: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>

I think what you are advocating is Rodney's proposal + assignability of INTEGER and LONGINT + mixed arithmetic.

On 8 Jan 2010, at 18:05, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
>> 
>> Hendrik, do you mean:
>> 
>> "INTEGER is that subrange of LONGINT that happens to be efficiently 
>> implementable on the target architecture"?
>> 
>> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
>> choose it as I please when I configure/compile the compiler?
>> 
>>    Mika
> 
> I've just been thinking of that.  Why even have a size for LONGINT?  Why 
> not allow the programmer to use only subranges of LONGINT?  The 
> arithmetic operations all have the property that you can compute 
> subranges for the reults given subranges for the operands.  So 
> intermediate results are all bounded in size, you can compute without 
> overflow happening ... until you get to narrow the final result for 
> assignment to whatever variable you want to 
> assign it to.
> 
> I suspect there are compiler optimisations (well, let's ne honest, 
> call them ameliorations) that could be performed to move the final 
> range-truncate-check backward through the series of operations and limit 
> the number of unnecessary bits that have been computed.  These 
> ameliorations are likely to be more effective if no range check need be 
> performed on final assignment (but there's always a conflict between 
> amelioration and run-time checks, isn't there?)
> 
> We could do this for LONGINT completely independent of whatever we do 
> with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
> INTEGER is what you use when you particularly want to use 
> machine-efficient data and operations.  LONGINT is what you use when 
> that's not enough, and you want to statically specify the size of 
> integer you need, and pay the price.  What with machines having carry 
> and overflow flags, add-with-carry instructions, it chould be possible 
> to generate reasonably efficient code anyway, without the full overhead 
> of run-time-determined number sizes.
> 
> Most machines already have integer multiply instructions that return a 
> double-length product.  It's such a pity to waste them.
> 
> -- hendrik

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

From hendrik at topoi.pooq.com  Sat Jan  9 02:33:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:33:42 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
Message-ID: <20100109013342.GA23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> I think what you are advocating is Rodney's proposal + assignability 
> of INTEGER and LONGINT + mixed arithmetic.

I thought Rodney's propsal still had the compiler impose a bound on the 
size of LONGINT.  Or did I miss something?

I'm proposing to let the programmer use subranges of LONGINT that are as 
long as he wishes.  And if the computer runs out of virtual memory to 
store one of the programmer's long integers, well, that's the computer 
imposing the limit, not the language.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 02:40:31 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:40:31 -0500
Subject: [M3devel] Integers
In-Reply-To: <7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<889CD037-4BB0-47E7-B346-72C87C42A0AB@cs.purdue.edu>
	<20100108215033.GB9749@topoi.pooq.com>
	<7A00A010-D0C2-42C0-84ED-52B849A50F7A@cs.purdue.edu>
Message-ID: <20100109014030.GB23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 04:53:29PM -0500, Tony Hosking wrote:
> Then the base type of INTEGER would be LONGINT.
> 
> Thus, INTEGER operations would incur the expense of unnatural LONGINT 
> operations.

I get it.  It's not a matter of the size of the INTEGERs; it's a matter 
of the operations on them -- that operations on INTEGERs are limited to 
whatever size the computer processes efficiently, and that this limit is 
*checked* (at least in principle) for reliability.

-- hendrik

> 
> That is unacceptable.


From hendrik at topoi.pooq.com  Sat Jan  9 02:44:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 20:44:37 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <20100109014437.GC23519@topoi.pooq.com>

On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > I think what you are advocating is Rodney's proposal + assignability 
> > of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).

-- hendrik
> 
> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.


From jay.krell at cornell.edu  Sat Jan  9 03:09:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:09:13 +0000
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>,
	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>, <20100108190409.GF14151@topoi.pooq.com>,
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>,
	<20100108213923.GA9749@topoi.pooq.com>,
	<20100108215028.40A651A207A@async.async.caltech.edu>,
	<20100108230505.GC9749@topoi.pooq.com>,
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>,
	<20100109013342.GA23519@topoi.pooq.com>,
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <COL101-W8A809232A5F6A9D4948D2E66F0@phx.gbl>


I hear Hendrik proposing that "LONGINT" is the name for fixed arbitrary precision integers.

That it might even have a name. Or the user has to mention it in order to acknowledge

he is using something potentially inefficient.

 

 

 FileSize = BITS 64 FOR LONGINT;

 FileSize = [1..LongInt.LShift(1, 63)];

 FileSize = LONGINT[64];

 or such 

 

This is not a bad idea.

 

I think the "real" problem here is a multitude of options/scenarios and

a lack of vocabulary.

As I said, there is a time/place for "silent wraparound", for trapping overflow,

for extending precision to fit.

 

Also I'm surprised you can't mix REAL and LONGREAL.

 

Also I don't think INTEGER + LONGINT is all that confusing or, as I said, subtle.

It isn't /immediately/ obvious how to deal with MIN, MAX, MOD, DIV, but

it is still not that tricky.

 

MIN(INTEGER, LONGINT) is INTEGER. Not that difficult to figure out why.

 At least one of the inputs fits in an integer and the result is the smaller input.

 

MAX(INTEGER, LONGINT) is LONGINT, ditto.

  One of the inputs might not fit in an INTEGER and the result is the larger input.

 

INTEGER DIV LONGINT is INTEGER

BIG DIV SMALL1 is SMALL2

SMALL DIV BIG is 0 remainder SMALL.

 

LONGINT DIV INTEGER is LONGINT

Prove with one simple case:

BIG1 DIV 2 is BIG2.

Easier BIG1 DIV 1 is BIG1.

 

Consider: LONGINT MOD INTEGER and INTEGER MOD LONGINT

SMALL divided by BIG is, again, 0 remainder SMALL, INTEGER

BIG divided by SMALL1 is SMALL2, remainder [0..SMALL1 - 1] which is INTEGER.

 

That is, division either gives you 0 and remainder = first number.

Or it gives you non-zero and remainder is less than the second number.

  50 divided by 100 is 0 remainder 50.

  109 divided by 10 is 10 remainder 9

 

FOR loops also should allow mixing.

 

 - Jay

 
> Date: Fri, 8 Jan 2010 20:44:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT (was: Re: Integers
> 
> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> > > I think what you are advocating is Rodney's proposal + assignability 
> > > of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT. Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
> > 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes. And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/49c07b7c/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jan  9 03:16:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:16:57 +0000
Subject: [M3devel] still need a branch for longint changes?
Message-ID: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>


Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay

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

From hosking at cs.purdue.edu  Sat Jan  9 03:23:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:23:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
Message-ID: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>

Please hold off on mainline changes.  I don't think we have reached consensus yet...

The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.

On 8 Jan 2010, at 21:16, Jay K wrote:

> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 

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

From hosking at cs.purdue.edu  Sat Jan  9 03:28:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:28:59 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109014437.GC23519@topoi.pooq.com>
References: <40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<20100109014437.GC23519@topoi.pooq.com>
Message-ID: <7A1B4E83-A69C-43CA-9932-38B974B22B60@cs.purdue.edu>

I'm not sure how this would all work exactly...  It would make LONGINT a very strange beast indeed, compared to the other ordinal types.

On 8 Jan 2010, at 20:44, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 08:33:42PM -0500, hendrik at topoi.pooq.com wrote:
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability 
>>> of INTEGER and LONGINT + mixed arithmetic.
>> 
>> I thought Rodney's propsal still had the compiler impose a bound on the 
>> size of LONGINT.  Or did I miss something?
> 
> In particular, I would have there be no FIRST(LONGINT) or LAST(LONGINT).
> 
> -- hendrik
>> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as 
>> long as he wishes.  And if the computer runs out of virtual memory to 
>> store one of the programmer's long integers, well, that's the computer 
>> imposing the limit, not the language.

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

From hosking at cs.purdue.edu  Sat Jan  9 03:32:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 8 Jan 2010 21:32:47 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <20100109013342.GA23519@topoi.pooq.com>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
Message-ID: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>

On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>> I think what you are advocating is Rodney's proposal + assignability 
>> of INTEGER and LONGINT + mixed arithmetic.
> 
> I thought Rodney's propsal still had the compiler impose a bound on the 
> size of LONGINT.  Or did I miss something?

Yes, it would.

> I'm proposing to let the programmer use subranges of LONGINT that are as 
> long as he wishes.  And if the computer runs out of virtual memory to 
> store one of the programmer's long integers, well, that's the computer 
> imposing the limit, not the language.

But there is still the question as to what *representation* is used to decide the particular operation to apply.

I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.

Just for fun, I suggest you take some time to watch the talk Growing a Language, by Guy Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/f9495a09/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jan  9 03:36:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 02:36:54 +0000
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>


I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.

And mixed arithmetic is available, and assignability INTEGER to LONGINT.

I have that implemented. It is a little onerous for Rd/Wr uses, but ok.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 8 Jan 2010 21:23:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] still need a branch for longint changes?


Please hold off on mainline changes.  I don't think we have reached consensus yet...


The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.



On 8 Jan 2010, at 21:16, Jay K wrote:

Still need a branch for longint changes?
 I doubt what I have is where we are going, though it is a step toward it.
 Just wait for Tony to implement Rodney's proposal?
 Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.

Or maybe just take my stuff to the mainline and then refine/reduce it later?

 - Jay


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

From hendrik at topoi.pooq.com  Sat Jan  9 04:00:41 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:00:41 -0500
Subject: [M3devel] Unbounded but finite LONGINT (was: Re:  Integers
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100108040333.GB9556@topoi.pooq.com> <4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <20100109030040.GA28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:32:47PM -0500, Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com wrote:
> 
> > On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >> I think what you are advocating is Rodney's proposal + assignability 
> >> of INTEGER and LONGINT + mixed arithmetic.
> > 
> > I thought Rodney's propsal still had the compiler impose a bound on the 
> > size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
> > I'm proposing to let the programmer use subranges of LONGINT that are as 
> > long as he wishes.  And if the computer runs out of virtual memory to 
> > store one of the programmer's long integers, well, that's the computer 
> > imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine 
> representation based on the range of values in the subrange (much as 
> it does currently).

That's exactly what I propose.

> But if you really want to have an arbitrary range type I would argue 
> it is much better to implement it as a library than as a primitive 
> type.

That's fine if I have no static limit on the size of the integers.  Like 
if I want to have an open array.  Or even an array that I can resize 
dynamically.  But for the common case where I know exactly what the 
limits are, static is better.

(and that's the case with file offsets, for example)

What's easier for the compiler writer is another matter, of course.

> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele

I'll try and find it.  I seem to remember seeing the text somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan  9 04:03:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 8 Jan 2010 22:03:15 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
Message-ID: <20100109030314.GB28707@topoi.pooq.com>

On Fri, Jan 08, 2010 at 09:23:15PM -0500, Tony Hosking wrote:
> Please hold off on mainline changes.  I don't think we have reached 
> consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  
> I'm leaning towards allowing it, but want to hear from others.

Not to mention the question whether the conpiler should impose a static 
bound on LONGINT.

-- hendrik


From jay.krell at cornell.edu  Sat Jan  9 04:54:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 03:54:31 +0000
Subject: [M3devel] mixing INTEGER and LONGINT?
In-Reply-To: <20100108142811.GA14151@topoi.pooq.com>
References: <COL101-W29DA47C8148BA33B3DEBFAE6700@phx.gbl>,
	<20100108142811.GA14151@topoi.pooq.com>
Message-ID: <COL101-W1340FFFD0FCE25D04F7C2EE66F0@phx.gbl>


Oops, of course, thank you.
I'll update my changes...maybe check them into a branch..

 - Jay

> From: hendrik

>     MIN( 5, -1000000000000000L) = -1000000000000000L
>     So the result really needs to be LONGINT.

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

From hosking at cs.purdue.edu  Sat Jan  9 06:06:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:06:07 -0500
Subject: [M3devel] still need a branch for longint changes?
In-Reply-To: <COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
References: <COL101-W4570A86C38E913CC82ADCFE66F0@phx.gbl>,
	<920B991F-A50E-43D9-86AB-1E387DE24DA9@cs.purdue.edu>
	<COL101-W736FD967D98EAFC8DACE3E66F0@phx.gbl>
Message-ID: <77A73750-12DF-4BB2-B6AF-6919FC2687FE@cs.purdue.edu>

So, thinking about things some more I am very much less inclined to believe that mixed operand arithmetic makes any sense, though assignability with run-time range checks seems fine.

With mixed operand arithmetic we get to some very strange places:

LAST(INTEGER) + 1 = FIRST(INTEGER)

is true because of overflow under the standard Modula-3 implementation.

But,

LAST(INTEGER) + 1L = FIRST(INTEGER)

is false because the arithmetic will be performed as LONGINT.

The trivial presence of "1L" instead of "1" has a huge impact on the semantics.  That seems really dangerous.

Much better (if wordier) to require explicit conversion (as currently implemented) to preserve sanity.

Thus,

VAL(LAST(INTEGER), LONGINT) + 1L = VAL(FIRST(INTEGER), LONGINT)

is false, as the programmer rightly expects, because he/she will be explicitly (because of the conversions) aware that LONGINT arithmetic is taking place.

On 8 Jan 2010, at 21:36, Jay K wrote:

> I'm fine with a compromise that requires no runtime checks and users use ORD() to narrow LONGINT to INTEGER.
> And mixed arithmetic is available, and assignability INTEGER to LONGINT.
> I have that implemented. It is a little onerous for Rd/Wr uses, but ok.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 21:23:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] still need a branch for longint changes?
> 
> Please hold off on mainline changes.  I don't think we have reached consensus yet...
> 
> The issue remains: mixed arithmetic + checked assignability or not?  I'm leaning towards allowing it, but want to hear from others.
> 
> On 8 Jan 2010, at 21:16, Jay K wrote:
> 
> Still need a branch for longint changes?
>  I doubt what I have is where we are going, though it is a step toward it.
>  Just wait for Tony to implement Rodney's proposal?
>  Or I work on it in a branch? It doesn't look too difficult to at least mostly do. I already have "mixed" stuff compiling and assignability INTEGER to LONGINT. I didn't yet do anything requiring runtime checks, but it's not that hard to do, given that there are already checks for assignment involving only partly overlapping ranges.
> 
> Or maybe just take my stuff to the mainline and then refine/reduce it later?
> 
>  - Jay
> 
> 
> 



From hosking at cs.purdue.edu  Sat Jan  9 06:37:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 00:37:42 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>
Message-ID: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>

Looking at your code, I think the assignability test for ordinals should be more like:

      IF (IsEqual (Base(a), Base(b), NIL)
          OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
          OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

That way CARDINAL and other subranges fall right out.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 8 Jan 2010, at 06:13, Jay K wrote:

> Attached is my latest work here.
> With the compiler changes (in the diff), I was able to
> elminate most uses of VAL(expr, LONGINT).
> There's something slightly off such that I had
> to add a very small number, like two.
>  
>  
> The compiler change is newer than earlier.
> For example you can now assign CARDINAL to LONGINT.
> I didn't do it, but you should also be able to add/subtract/etc.
> mixing CARDINAL and LONGINT.
>  
> 
> FOR statements also don't allow the level of mixing
> that they should.
> 
>  
> I'm hoping to get agreement soon just from the diffs
> but if necessary I'll look how to create a branch.
> My general worry about branches is developers just
> go off on their own in a branch and it's impossible to
> get anyone to look at it, they are busy enough with one branch,
> let alone multiple..
>  
> 
>  - Jay
> <dif8.txt>



From jay.krell at cornell.edu  Sat Jan  9 06:50:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 05:50:06 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
Message-ID: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>


I don't know the precedence but agreed:


>           OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>           OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Also, I really think mixed arithmetic is ok.

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
>       IF (IsEqual (Base(a), Base(b), NIL)
>           OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>           OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> >  
> >  
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> >  
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> >  
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> >  
> > 
> >  - Jay
> > <dif8.txt>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/f180057b/attachment-0002.html>

From hosking at cs.purdue.edu  Sat Jan  9 07:03:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 01:03:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>
Message-ID: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>

On 9 Jan 2010, at 00:50, Jay K wrote:

> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.

> Also, I really think mixed arithmetic is ok.

But are you ok with:

(LAST(INTEGER) + 1) = FIRST(INTEGER)

while

(LAST(INTEGER) + 1L) # FIRST(INTEGER)

?

I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 

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

From jay.krell at cornell.edu  Sat Jan  9 07:59:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 06:59:52 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>


I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 08:01:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:01:47 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
Message-ID: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>


 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 08:52:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 07:52:29 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>,
	, , <1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W589E03B28FAE7C3BAF1521E66F0@phx.gbl>


ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];

VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs








 > (LAST(INTEGER) + 1) = FIRST(INTEGER)
ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000








I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs



On 9 Jan 2010, at 00:50, Jay K wrote:I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.

Yes, that would be why.
Also, I really think mixed arithmetic is ok.

But are you ok with:
(LAST(INTEGER) + 1) = FIRST(INTEGER)
while
(LAST(INTEGER) + 1L) # FIRST(INTEGER)
?
I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!

 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 10:04:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:04:03 +0000
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
Message-ID: <COL101-W177E347253C078605A975CE66F0@phx.gbl>


Uh, maybe all ordinal types that overlap in any values are assignable?

 

 

PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if they have at least one member in common. *)
      IF GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;
    ELSIF IsSubtype (a, b) THEN
      (* may be ok, but must narrow rhs before doing the assignment *)
      RETURN IsSubtype (b, Reff.T)
          OR ArrayType.Split (b, i, e)
          OR (IsSubtype (b, Addr.T)
              AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
    ELSE
      RETURN FALSE;
    END;
  END IsAssignable;


 

?

I'll try it out.

 

 

What is an ordinal type?, I wonder, the compiler implementation:

 

 

PROCEDURE IsOrdinal (t: T): BOOLEAN =
  VAR u := Check (t);  c := u.info.class;
  BEGIN
    RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
           OR (c = Class.Enum) OR (c = Class.Error)
           OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
  END IsOrdinal;


 

 - Jay





 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 07:52:29 +0000



ok, yeah, it does bug me.

With 8 bit integer, 16 bit longint.

Let's replace 128 with 127 + 1.

 (127 + 1) > 127 

either:
  is true
  or false 
  or raises an exception 

"Obviously" it should be true, but implementing that is..uncertain.
Though, again, it should really raise the exception before the comparison is made.
  Maybe it does.

Where (127 + 1L) > 127 

is simply true, no controversy..except for the difference with 127 + 1.

But Rodney said something..that mixed operations fall out of
assignability. Right??


I have an idea..I mean..an obvious guess/experiment.
I can try providing only for bidirectional assignability
and see what the affect on rd/wr is.
Maybe bidirectional assignability is enough to
keep the diff small?
Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
   Clearly it will be allowed by any of the proposals, it
   just might not be necessary.


Also, btw, I think we should warn for truncating assignment.
Any time a range check is put in, perhaps.
Except maybe not on array indexing.
Which might leave this suggestion completely ambiguous as
to when a warning should be issued.

But as has been pointed out, while it may be "annoying" and
"inconvenient" to put ORD and VAL everywhere, or at least ORD,
it does force us to revisit all those locations where a change
is being induced.

Notice that that the warning may or may not be platform specific.
It might trigger only on 32bit platforms.
Or the compiler targeting 64bit platforms might "know" about
the truncation potential on other platforms and warn.
In a specific concrete way, assignment of LONGINT to INTEGER
might warn, no matter their current exact sizes.


Extending that rule to subranges might be tricky.
TYPE A = [0..LAST(INTEGER)/2];
TYPE B = [0..LAST(LONGINT)/2];
VAR a: A; b:B;

a := b;   warn?

Implementing that, maybe, would require, like a bit carried along
with type definitions in the compiler, as to if the definition
contains a platform independent size in it...er..
if the size is dependent on bitsize(integer) or not, and
mixing of that type with any? other type is a warning?
Clearly no. Mixing with a type dependent on bitsize(longint)?
Maybe.

I'm not sure what the rule is, but, you know, it'd be nice
if above code did warn on 64bit targets, in order to
encourage portability to 32bit targets.


 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 07:01:47 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




 > (LAST(INTEGER) + 1) = FIRST(INTEGER)

ps: a beginner wouldn't necessarily expect this.
He might expect an error or widening of precision as needed.
Eventually faced with the cruel realities of what can be efficiently implemented,
he might accept any of our answers. :)

 - Jay



From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] latest longint file size diffs
Date: Sat, 9 Jan 2010 06:59:52 +0000



I'll admit to being a little unsure.


I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.


You might classify me more as a lazy user than a language designing deep thinker.


But I'm curious even about your assertion.


Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
It is easier for me.


  INTEGER max := 16_7F;   
  INTEGER first := 16_80; 
  INTEGER p1 := max + 1; 
  LONGINT p1L := max + 1L; 


So, what happens if we compare p1 with first and p1L with first?
Again remember INTEGER is 8 bits, LONGINT is 16 bits.

p1 will be -128, 0x80.
p1L will be 128, 0x0080.


What then happens when you compare 0x0080 to 0x80?
Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?


And heck, shouldn't max + 1 already throw an exception?


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 01:03:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] latest longint file size diffs




On 9 Jan 2010, at 00:50, Jay K wrote:


I don't know the precedence but agreed:


> OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))

I was being sort of lazy.
I've never touched the front end and it was critical I be able to make
a small change and see fairly precisely the expected change, even
if I didn't get all cases.

This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
in the Win32 code to INTEGER or LONGINT.



Yes, that would be why.


Also, I really think mixed arithmetic is ok.



But are you ok with:


(LAST(INTEGER) + 1) = FIRST(INTEGER)


while


(LAST(INTEGER) + 1L) # FIRST(INTEGER)


?


I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!



 - Jay


> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 00:37:42 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> Looking at your code, I think the assignability test for ordinals should be more like:
> 
> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN
> (* check for a non-empty intersection *)
> min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> RETURN TInt.LE (min, max);
> ELSE
> RETURN FALSE;
> END;
> 
> That way CARDINAL and other subranges fall right out.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 8 Jan 2010, at 06:13, Jay K wrote:
> 
> > Attached is my latest work here.
> > With the compiler changes (in the diff), I was able to
> > elminate most uses of VAL(expr, LONGINT).
> > There's something slightly off such that I had
> > to add a very small number, like two.
> > 
> > 
> > The compiler change is newer than earlier.
> > For example you can now assign CARDINAL to LONGINT.
> > I didn't do it, but you should also be able to add/subtract/etc.
> > mixing CARDINAL and LONGINT.
> > 
> > 
> > FOR statements also don't allow the level of mixing
> > that they should.
> > 
> > 
> > I'm hoping to get agreement soon just from the diffs
> > but if necessary I'll look how to create a branch.
> > My general worry about branches is developers just
> > go off on their own in a branch and it's impossible to
> > get anyone to look at it, they are busy enough with one branch,
> > let alone multiple..
> > 
> > 
> > - Jay
> > <dif8.txt>
> 

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

From jay.krell at cornell.edu  Sat Jan  9 10:34:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 09:34:06 +0000
Subject: [M3devel] index array by longint?
Message-ID: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>


Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

  Or really, with runtime bounds check against the array size.

 

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

 

 

 - Jay





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

From jay.krell at cornell.edu  Sat Jan  9 11:22:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 10:22:21 +0000
Subject: [M3devel] another longint variant
Message-ID: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>


[attached]

In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.

 


Specifically:

  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)

 


  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length

   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then

 


  no VAL or ORD needed


 

  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"

 


  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/b722da0f/attachment-0002.txt>

From hosking at cs.purdue.edu  Sat Jan  9 19:24:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:24:08 -0500
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <0D79BD22-2EB9-4EC8-A453-CC2E0A66AA8C@cs.purdue.edu>

The patch I sent to you yesterday will achieve checked assignment of LONGINT to/from INTEGER.

On 9 Jan 2010, at 04:04, Jay K wrote:

> Uh, maybe all ordinal types that overlap in any values are assignable?
>  
>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127 
> 
> either:
>   is true
>   or false 
>   or raises an exception 
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127 
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;   
>   INTEGER first := 16_80; 
>   INTEGER p1 := max + 1; 
>   LONGINT p1L := max + 1L; 
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign extend to LONGINT and compare), or you get an exception (upon narrowing the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
> I don't know the precedence but agreed:
> 
> 
> > OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
> > OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
> I was being sort of lazy.
> I've never touched the front end and it was critical I be able to make
> a small change and see fairly precisely the expected change, even
> if I didn't get all cases.
> 
> This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
> in the Win32 code to INTEGER or LONGINT.
> 
> Yes, that would be why.
> 
> Also, I really think mixed arithmetic is ok.
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer.  Modula-3 was designed using the "principle of least surprise" and I frankly find the above to be very surprising!
> 
> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sat, 9 Jan 2010 00:37:42 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] latest longint file size diffs
> > 
> > Looking at your code, I think the assignability test for ordinals should be more like:
> > 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> > (* check for a non-empty intersection *)
> > min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
> > max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
> > RETURN TInt.LE (min, max);
> > ELSE
> > RETURN FALSE;
> > END;
> > 
> > That way CARDINAL and other subranges fall right out.
> > 
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> > 
> > 
> > 
> > 
> > On 8 Jan 2010, at 06:13, Jay K wrote:
> > 
> > > Attached is my latest work here.
> > > With the compiler changes (in the diff), I was able to
> > > elminate most uses of VAL(expr, LONGINT).
> > > There's something slightly off such that I had
> > > to add a very small number, like two.
> > > 
> > > 
> > > The compiler change is newer than earlier.
> > > For example you can now assign CARDINAL to LONGINT.
> > > I didn't do it, but you should also be able to add/subtract/etc.
> > > mixing CARDINAL and LONGINT.
> > > 
> > > 
> > > FOR statements also don't allow the level of mixing
> > > that they should.
> > > 
> > > 
> > > I'm hoping to get agreement soon just from the diffs
> > > but if necessary I'll look how to create a branch.
> > > My general worry about branches is developers just
> > > go off on their own in a branch and it's impossible to
> > > get anyone to look at it, they are busy enough with one branch,
> > > let alone multiple..
> > > 
> > > 
> > > - Jay
> > > <dif8.txt>
> > 
> 
> 

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

From hosking at cs.purdue.edu  Sat Jan  9 19:25:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:25:23 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <CC8493F7-82F9-4004-8B0F-D470B1FFDCC1@cs.purdue.edu>

I think having assignability let's you do what you need.  The range check on assignment will then allow you to index...

On 9 Jan 2010, at 04:34, Jay K wrote:

> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sat Jan  9 19:30:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 13:30:55 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>
Message-ID: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...

On 9 Jan 2010, at 05:22, Jay K wrote:

> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>

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

From jay.krell at cornell.edu  Sat Jan  9 20:33:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 19:33:45 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
Message-ID: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>


I don't believe that suffices but I can check again.

 

 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/992ac302/attachment-0002.html>

From hosking at cs.purdue.edu  Sat Jan  9 20:52:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 14:52:19 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>
Message-ID: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>

It should suffice for assignability...

On 9 Jan 2010, at 14:33, Jay K wrote:

> I don't believe that suffices but I can check again.
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 

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

From rodney_bates at lcwb.coop  Sat Jan  9 20:50:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 13:50:25 -0600
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
Message-ID: <4B48DE01.8040303@lcwb.coop>



Tony Hosking wrote:
> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> <mailto:hendrik at topoi.pooq.com> wrote:
> 
>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>> I think what you are advocating is Rodney's proposal + assignability
>>> of INTEGER and LONGINT + mixed arithmetic.
>>
>> I thought Rodney's propsal still had the compiler impose a bound on the
>> size of LONGINT.  Or did I miss something?
> 
> Yes, it would.
> 
>> I'm proposing to let the programmer use subranges of LONGINT that are as
>> long as he wishes.  And if the computer runs out of virtual memory to
>> store one of the programmer's long integers, well, that's the computer
>> imposing the limit, not the language.
> 
> But there is still the question as to what *representation* is used to 
> decide the particular operation to apply.
> 
> I suppose the compiler could choose a particular machine representation 
> based on the range of values in the subrange (much as it does currently).
> But if you really want to have an arbitrary range type I would argue it 
> is much better to implement it as a library than as a primitive type.

This I agree with wholeheartedly.  Don't we already have some math libraries
for things like this, or maybe rational arithmetic, etc?


> 
> Just for fun, I suggest you take some time to watch the talk Growing a 
> Language, by Guy Steele 
> <http://video.google.com/videoplay?docid=-8860158196198824415>


From jay.krell at cornell.edu  Sat Jan  9 21:17:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:17:32 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
Message-ID: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>


[replacing periods with semicolons to avoid truncation..]

 

 

Right..I was going to say..as an overall change, like if we

want mixed operations, it really doesn't suffice;

Many of my m3front changes were in direct response

to compilation errors and fixed them;

 

 

I'm sure as well that just allowing assignability doesn't make the rd/wr

change particuarly small/smooth. You need mixed operations,

indexing, new, or else sprinkle ORD around;

 

 

There's a particular characteristic I should point out in the rd/wr code;

Maybe rd/wr should be modified..but it probably can't;

In particular, my understanding of rd/wr is that the maintain two

"numbers" (integer or longint, depending on how everything is resolved);

These numbers indicate the file offset that is at the start of the buffer

and at the end of the buffer. In a new world they need to be LONGINT;

However their "span", their difference, describes an

in-memory buffer size. Therefore their difference is always INTEGER

or CARDINAL, not LONGINT. It'd be super cool, but probably not

possible, if the language let you declare this somehow.

THEN mixed operations and such wouldn't be needed,

if the compiler new that subtracting these two integers

yielded an INTEGER, and possibly inserted checks of that;

But this is probably just a lazy user view and not realistic

for the language.

 

 

For assignability I think your change does work but mine was less wordy

and maybe more general;

The preexisting code allowed I believe any non-LONGINT ordinal

type to be assigned to any non-LONGINT ordinal type if there

are any overlapping values. Specifically really,

non-ordinal types with same base type and anyoverlap.

I removed the base type check;

This makes enums <=> longint, integer subranges <=> longint, etc;

 

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 14:52:19 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant




It should suffice for assignability...


On 9 Jan 2010, at 14:33, Jay K wrote:

I don't believe that suffices but I can check again.
 
 - Jay

 


Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...





On 9 Jan 2010, at 05:22, Jay K wrote:

[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>

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

From jay.krell at cornell.edu  Sat Jan  9 21:20:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 20:20:32 +0000
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>
	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>
	<20100108040333.GB9556@topoi.pooq.com>,<4B476704.8010403@lcwb.coop>
	<20100108190409.GF14151@topoi.pooq.com>
	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>
	<20100108213923.GA9749@topoi.pooq.com>
	<20100108215028.40A651A207A@async.async.caltech.edu>
	<20100108230505.GC9749@topoi.pooq.com>
	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>
	<20100109013342.GA23519@topoi.pooq.com>,
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>,
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <COL101-W417229BE8A4B934A7D89EBE66F0@phx.gbl>


Yes we have some such libraries;

The "problem" is that libraries are inconvenient and in-fix operatores are convenient;

You either need to:

   accept that and use what works

   or make the language amenable to more convenient libraries

    (i.e. provide for operator overloading in the language)

   or make more stuff "built in" / "special"

 

 

We will probably just do the first.

LONGINT will probably just always be exactly 64bits, no more, no less,

and have the same overflow features as INTEGER;

 

It'd be nifty for me if the frontend learned to do arbitrary precision

integer arithmetic, because then NT386 would get a working LONGINT that way;

But that's not a valid reason. :)

 

 - Jay


 
> Date: Sat, 9 Jan 2010 13:50:25 -0600
> From: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT
> 
> 
> 
> Tony Hosking wrote:
> > On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> > <mailto:hendrik at topoi.pooq.com> wrote:
> > 
> >> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >>> I think what you are advocating is Rodney's proposal + assignability
> >>> of INTEGER and LONGINT + mixed arithmetic.
> >>
> >> I thought Rodney's propsal still had the compiler impose a bound on the
> >> size of LONGINT. Or did I miss something?
> > 
> > Yes, it would.
> > 
> >> I'm proposing to let the programmer use subranges of LONGINT that are as
> >> long as he wishes. And if the computer runs out of virtual memory to
> >> store one of the programmer's long integers, well, that's the computer
> >> imposing the limit, not the language.
> > 
> > But there is still the question as to what *representation* is used to 
> > decide the particular operation to apply.
> > 
> > I suppose the compiler could choose a particular machine representation 
> > based on the range of values in the subrange (much as it does currently).
> > But if you really want to have an arbitrary range type I would argue it 
> > is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly. Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?
> 
> 
> > 
> > Just for fun, I suggest you take some time to watch the talk Growing a 
> > Language, by Guy Steele 
> > <http://video.google.com/videoplay?docid=-8860158196198824415>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3432e1d0/attachment-0002.html>

From hosking at cs.purdue.edu  Sat Jan  9 21:21:43 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:21:43 -0500
Subject: [M3devel] Unbounded but finite LONGINT
In-Reply-To: <4B48DE01.8040303@lcwb.coop>
References: <20100107164620.GA30061@topoi.pooq.com>	<40F21639-B895-4FA1-9027-F781608F9BFC@cs.purdue.edu>	<20100108040333.GB9556@topoi.pooq.com>
	<4B476704.8010403@lcwb.coop>	<20100108190409.GF14151@topoi.pooq.com>	<2733CF3C-639F-4DC7-85E6-624ED795BACC@cs.purdue.edu>	<20100108213923.GA9749@topoi.pooq.com>	<20100108215028.40A651A207A@async.async.caltech.edu>	<20100108230505.GC9749@topoi.pooq.com>	<B735EC51-7B58-4040-86DB-54FBF2F7B9B7@cs.purdue.edu>	<20100109013342.GA23519@topoi.pooq.com>
	<99206B8B-5004-4D0C-966B-0CBC0D6A6AD8@cs.purdue.edu>
	<4B48DE01.8040303@lcwb.coop>
Message-ID: <B79AEE7D-4178-44E1-AD26-29488EC8FC40@cs.purdue.edu>

On 9 Jan 2010, at 14:50, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com <mailto:hendrik at topoi.pooq.com> wrote:
>>> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
>>>> I think what you are advocating is Rodney's proposal + assignability
>>>> of INTEGER and LONGINT + mixed arithmetic.
>>> 
>>> I thought Rodney's propsal still had the compiler impose a bound on the
>>> size of LONGINT.  Or did I miss something?
>> Yes, it would.
>>> I'm proposing to let the programmer use subranges of LONGINT that are as
>>> long as he wishes.  And if the computer runs out of virtual memory to
>>> store one of the programmer's long integers, well, that's the computer
>>> imposing the limit, not the language.
>> But there is still the question as to what *representation* is used to decide the particular operation to apply.
>> I suppose the compiler could choose a particular machine representation based on the range of values in the subrange (much as it does currently).
>> But if you really want to have an arbitrary range type I would argue it is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly.  Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?

Yes, the arithmetic package (m3-libs/arithmetic).

From hosking at cs.purdue.edu  Sat Jan  9 21:54:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 15:54:22 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>

On 9 Jan 2010, at 15:17, Jay K wrote:

> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;

I'd like precise examples.

>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.

>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.

That would be tricky...

>  For assignability I think your change does work but mine was less wordy
> and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.

> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;

That's what broke it.

> This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?

I really want to see the impact of not allowing mixed arithmetic while having assignability.

> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 

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

From rodney_bates at lcwb.coop  Sat Jan  9 23:15:16 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 16:15:16 -0600
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
Message-ID: <4B48FFF4.8050307@lcwb.coop>



Tony Hosking wrote: (excerpted)
>........................................
>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
> 
> Currently, direct comparison between LONGINT and INTEGER is not 
> permitted.  If it were then this would be true.
> 


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

> 
>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>    like" (but is not equal to) [0..LAST(LONGINT)].
>>
>>      The current CARDINAL has an interesting history.  Originally, it
>>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>>      was later changed to be "just like" the subrange, i.e., the two
>>      are not the same type, but have the same properties in every
>>      other respect.  The only reason for the change had to do with
>>      reading pickles, which are completely defined and implemented as
>>      library code.  The change did affect the type analysis of the
>>      language, nevertheless.
>>
>>      We should preserve this property for LONGCARD too.
> 
> Currently there is no implementation of LONGCARD.  I argue that we don't 
> need LONGCARD (since, as discussed below, NUMBER should stay typed as 
> CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

>> 20. The statement that the upperbound of a FOR loop should not be
>>    LAST(INTEGER) also applies to LAST(LONGINT).
> 
> Agreed.
> 
>>      Note that the existing definition of FOR otherwise generalizes
>>      to LONGINT without change.
> 
> The current implementation does not permit the range values to be 
> different types (both must be INTEGER or LONGINT), and the step value 
> must also match.  Will we permit any mixing of values?  If so, I assume 
> that we use the maximal type of the expressions (LONGINT if any one is 
> LONGINT, INTEGER otherwise).
>

I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


>> 22. There is a new required interface LongWord.  It almost exactly
>>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>    new functions ToWord and FromWord, that conversion between the two
>>    types, using unsigned interpretations of the values.  ToInt may
>>    produce a checked runtime error, if the result value is not in the
>>    range of an unsigned interpretation of INTEGER.
> 
> This is the current implementation, but we do not support ToWord and 
> FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

> 
>>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>      consistency.  This means simple assignability tests and
>>      assignments between the types will use signed interpretations.
>>      So different functions are needed to do size changes with
>>      unsigned interpretation.
> 
> This is the current implementation.
> 
>


From hosking at cs.purdue.edu  Sat Jan  9 23:45:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:45:09 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <4B48FFF4.8050307@lcwb.coop>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
Message-ID: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>

Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote: (excerpted)
>> ........................................
>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
> 
> 
> I remember there was some vexing problem about what the result type
> should be for FIRST and LAST, but not the details.  It seems to
> me now that the only thing that makes any sense is to preserve the
> existing rule that it is the base type of the argument type.
> This is really necessary to preserve existing semantics of the
> language and of existing code.
> 
> This original proposal seems to be silent on the matter, which I suppose
> means I intended it as a NO CHANGE.  I guess, if
> mixed relations are allowed, then I can't think of a problem
> with this.  Even if mixed relations are disallowed, this range
> constraint could be expressed with explicit conversions, I suppose.
> 
> .......................................................................
> 
>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>> 
>>>     The current CARDINAL has an interesting history.  Originally, it
>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>     was later changed to be "just like" the subrange, i.e., the two
>>>     are not the same type, but have the same properties in every
>>>     other respect.  The only reason for the change had to do with
>>>     reading pickles, which are completely defined and implemented as
>>>     library code.  The change did affect the type analysis of the
>>>     language, nevertheless.
>>> 
>>>     We should preserve this property for LONGCARD too.
>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 
> LONGCARD is needed for pickles (and for no other reason, that I can
> think of).  The problem is that if a record or object has a field of
> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
> the type to be different on different target machines, making a pickle
> written on, say a 32-bit machine unreadable on a 64-bit machine.
> LONGCARD can be treated as the same type regardless of word size,
> allowing the automatic size changes pickles already does for INTEGER,
> CARDINAL, and LONGINT to extend to this subrange too.
> 
> (Note: If you try to extend this size-changing by pickles to arbitrary
> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
> are jumping head first into a tar pit.  I've thought about it just enough
> to conclude I wanted to step back.)
> 
> .......................................................................
> 
>>> 20. The statement that the upperbound of a FOR loop should not be
>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>> Agreed.
>>>     Note that the existing definition of FOR otherwise generalizes
>>>     to LONGINT without change.
>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>> 
> 
> I think allowing mixtures here is going too far.  Moreover, the existing
> rule for FOR already requires the same base type for the two bounds, unlike
> the assignability rule for operators, so unless we change an existing
> language rule here, this form of mixing is not allowed.
> 
> Note that the step value is "integer-valued" unconditionally, i.e.,
> even if the bounds have, say, an enumeration type.  Taken literally, I
> would say this would allow its type to be INTEGER, LONGINT, or any subrange
> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
> a use.
> 
> ......................................................................
> 
> 
>>> 22. There is a new required interface LongWord.  It almost exactly
>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>   new functions ToWord and FromWord, that conversion between the two
>>>   types, using unsigned interpretations of the values.  ToInt may
>>>   produce a checked runtime error, if the result value is not in the
>>>   range of an unsigned interpretation of INTEGER.
>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
> 
> All the operations in Word apply an unsigned interpretation to the bits
> of the word, whereas the operators and functions in the language apply
> signed.  Unsigned expansion is different(zero extend) from signed (sign
> extend).  FromWord would do the unsigned, while VAL would do the signed.
> 
> Similarly, for contracting, the value range check is different.  Signed
> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
> 32 are all zero.
> 
>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>     consistency.  This means simple assignability tests and
>>>     assignments between the types will use signed interpretations.
>>>     So different functions are needed to do size changes with
>>>     unsigned interpretation.
>> This is the current implementation.
>> 

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

From hosking at cs.purdue.edu  Sat Jan  9 23:48:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 17:48:05 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <337A4383-95A2-4767-8A9E-4C8EEE88B5AC@cs.purdue.edu>

Actually, that doesn't make sense -- it is an empty subrange.

On 9 Jan 2010, at 17:45, Tony Hosking wrote:

> Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:
> 
>> 
>> 
>> Tony Hosking wrote: (excerpted)
>>> ........................................
>>>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
>>> Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.
>> 
>> 
>> I remember there was some vexing problem about what the result type
>> should be for FIRST and LAST, but not the details.  It seems to
>> me now that the only thing that makes any sense is to preserve the
>> existing rule that it is the base type of the argument type.
>> This is really necessary to preserve existing semantics of the
>> language and of existing code.
>> 
>> This original proposal seems to be silent on the matter, which I suppose
>> means I intended it as a NO CHANGE.  I guess, if
>> mixed relations are allowed, then I can't think of a problem
>> with this.  Even if mixed relations are disallowed, this range
>> constraint could be expressed with explicit conversions, I suppose.
>> 
>> .......................................................................
>> 
>>>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>>>   like" (but is not equal to) [0..LAST(LONGINT)].
>>>> 
>>>>     The current CARDINAL has an interesting history.  Originally, it
>>>>     was just a predefined name for the type [0..LAST(INTEGER)].  It
>>>>     was later changed to be "just like" the subrange, i.e., the two
>>>>     are not the same type, but have the same properties in every
>>>>     other respect.  The only reason for the change had to do with
>>>>     reading pickles, which are completely defined and implemented as
>>>>     library code.  The change did affect the type analysis of the
>>>>     language, nevertheless.
>>>> 
>>>>     We should preserve this property for LONGCARD too.
>>> Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
>> 
>> LONGCARD is needed for pickles (and for no other reason, that I can
>> think of).  The problem is that if a record or object has a field of
>> type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
>> the type to be different on different target machines, making a pickle
>> written on, say a 32-bit machine unreadable on a 64-bit machine.
>> LONGCARD can be treated as the same type regardless of word size,
>> allowing the automatic size changes pickles already does for INTEGER,
>> CARDINAL, and LONGINT to extend to this subrange too.
>> 
>> (Note: If you try to extend this size-changing by pickles to arbitrary
>> subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
>> are jumping head first into a tar pit.  I've thought about it just enough
>> to conclude I wanted to step back.)
>> 
>> .......................................................................
>> 
>>>> 20. The statement that the upperbound of a FOR loop should not be
>>>>   LAST(INTEGER) also applies to LAST(LONGINT).
>>> Agreed.
>>>>     Note that the existing definition of FOR otherwise generalizes
>>>>     to LONGINT without change.
>>> The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).
>>> 
>> 
>> I think allowing mixtures here is going too far.  Moreover, the existing
>> rule for FOR already requires the same base type for the two bounds, unlike
>> the assignability rule for operators, so unless we change an existing
>> language rule here, this form of mixing is not allowed.
>> 
>> Note that the step value is "integer-valued" unconditionally, i.e.,
>> even if the bounds have, say, an enumeration type.  Taken literally, I
>> would say this would allow its type to be INTEGER, LONGINT, or any subrange
>> thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
>> a use.
>> 
>> ......................................................................
>> 
>> 
>>>> 22. There is a new required interface LongWord.  It almost exactly
>>>>   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>>>   new functions ToWord and FromWord, that conversion between the two
>>>>   types, using unsigned interpretations of the values.  ToInt may
>>>>   produce a checked runtime error, if the result value is not in the
>>>>   range of an unsigned interpretation of INTEGER.
>>> This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?
>> 
>> All the operations in Word apply an unsigned interpretation to the bits
>> of the word, whereas the operators and functions in the language apply
>> signed.  Unsigned expansion is different(zero extend) from signed (sign
>> extend).  FromWord would do the unsigned, while VAL would do the signed.
>> 
>> Similarly, for contracting, the value range check is different.  Signed
>> means leftmost 33 bits all equal to each other.  Unsigned means leftmost
>> 32 are all zero.
>> 
>>>>     Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>>>     consistency.  This means simple assignability tests and
>>>>     assignments between the types will use signed interpretations.
>>>>     So different functions are needed to do size changes with
>>>>     unsigned interpretation.
>>> This is the current implementation.
>>> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 00:47:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:47:16 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W503E27DAB92E218864CB0BE66F0@phx.gbl>


On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


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

From jay.krell at cornell.edu  Sun Jan 10 00:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Jan 2010 23:48:41 +0000
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>,
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>,
	<4B48FFF4.8050307@lcwb.coop>,
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <COL101-W345C207A34D36A982DD968E66F0@phx.gbl>


Sorry, right, I read 16_FFFFFFFF as 16_7FFFFFFFF.
Is this "not full range" thing we've been vaguly mentioning.
Guessing, I think it is easier to define with the "half range".
"All cardinals fit in integers" ?
Something like that?
No range check needed moving between them?

 - Jay






From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] LONGINT, my original proposal
Date: Sat, 9 Jan 2010 23:47:16 +0000








On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


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

From jay.krell at cornell.edu  Sun Jan 10 01:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:05:23 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
Message-ID: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>


Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:12:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:12:06 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	, , <C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>


 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From jay.krell at cornell.edu  Sun Jan 10 01:15:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:15:33 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,,
	, , <69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>


Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000








 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant








Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>


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

From hosking at cs.purdue.edu  Sun Jan 10 01:21:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 19:21:38 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
Message-ID: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>

On 9 Jan 2010, at 19:15, Jay K wrote:

> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.

I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 

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

From mika at async.async.caltech.edu  Sun Jan 10 01:25:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 09 Jan 2010 16:25:52 -0800
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl> 
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
Message-ID: <20100110002552.683AA1A2078@async.async.caltech.edu>

Jay K writes:
>--_953e6126-a89e-4966-8f22-5ccff92e7117_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
> > I believe Rodney said something like "mixed operations follow from assig=
>nability"=3B
> > and from a language point of view=2C that may be true=2C just not from t=
>he point of view=3B
>
>I meant to say=2C not from the language implementation point of view.
>
>Again=2C if I can assign and then add=2C might as well just allow add?
>Ditto assign and index=2C assign and multiply=2C etc.
>

The problem is that it's sometimes ambiguous what the result type is.

If you want to get into this kind of mess, why don't you just program in C...

I think this area is probably one of the reasons some people *like* Modula-3.
We don't want to have to guess what an expression means... it should be obvious.
If there are "promotion rules" it's just not that obvious.  I'm reminded of one
time when I was missing a prototype in a C program.............. ok that story
could go on and on.

    Mika



From jay.krell at cornell.edu  Sun Jan 10 01:31:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 00:31:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	,,<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	,,<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>,
	,,<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>,
	, , <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>


I noticed unary plus doesn't seem to be valid for LONGINT.
That is fixed among my other diffs.

I understand it matters little to take this "algorithmic" approach to determining
if an AddExpr is valid. We haven't yet agreed it will even change from current,
though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
and then add it, or vice versa, why not just allow the direct addition?
Force the programmer through hoops so the code is much clearer?
Or too verbose?

 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 19:21:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant



On 9 Jan 2010, at 19:15, Jay K wrote:Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000

 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.


With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.


I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.


I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;


You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?


VAR i1,i2:INTEGER;
       j1: LONGINT;


i1 := j1;
INC(i2, i1);


vs.
INC(i2, j1);


If the first is allowed, shouldn't the second?


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]
 
 
Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

 
Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.
 

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
 

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then
 

  no VAL or ORD needed

 
  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"
 

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>



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

From rodney_bates at lcwb.coop  Sun Jan 10 02:29:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 19:29:32 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>
	<COL101-W5476CBFE99DDED5178ADEDE66F0@phx.gbl>
Message-ID: <4B492D7C.9070800@lcwb.coop>



Jay K wrote:
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?

Whether mixed comparison is allowed or an explicit conversion is coded
before comparing, the representation conversion of the value of p1 to
LONGINT will do a sign extension, because INTEGER and LONGINT are
both signed.  Or rather, all the builtin operations apply signed
interpretation.

If instead, you converted p1 to LONGINT via the Long.FromWord I proposed,
then it would be a zero extension.  This can only be done explicitly.

The comparison would always be done in 16 bits, unless you explicitly
converted the LONGINT operand.down to 8 first.

> 
> 
> And heck, shouldn't max + 1 already throw an exception?

This is a separate issue.  I have always been very skeptical about silently
ignoring overflow.  But all the questions about INTEGER and LONGINT really
hinge only on the question of when does an overflow occur, not what happens
when it does.

> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From jay.krell at cornell.edu  Sun Jan 10 03:05:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 02:05:24 +0000
Subject: [M3devel] IsAssignable
Message-ID: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>


Current:


PROCEDURE IsAssignable (a, b: T): BOOLEAN =
  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
  BEGIN
    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
      RETURN TRUE;
    ELSIF IsOrdinal (a) THEN
      (* ordinal types:  OK if there is a common supertype
         and they have at least one member in common. *)
      IF IsEqual (Base(a), Base(b), NIL)
         AND GetBounds (a, min_a, max_a)
         AND GetBounds (b, min_b, max_b) THEN
        (* check for a non-empty intersection *)
        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
        RETURN TInt.LE (min, max);
      ELSE
        RETURN FALSE;
      END;

my proposed:




PROCEDURE IsAssignable (a, b: T): BOOLEAN =

  VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;

  BEGIN

    IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN

      RETURN TRUE;

    ELSIF IsOrdinal (a) THEN

      (* ordinal types:  OK if they have at least one member in common. *)

      IF GetBounds (a, min_a, max_a)

         AND GetBounds (b, min_b, max_b) THEN

        (* check for a non-empty intersection *)

        min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;

        max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;

        RETURN TInt.LE (min, max);

      ELSE

        RETURN FALSE;

      END;



Your proposed:

> IF (IsEqual (Base(a), Base(b), NIL)
> OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> AND GetBounds (a, min_a, max_a)
> AND GetBounds (b, min_b, max_b) THEN

What's the point of checking the types? Given that they are both ordinal?
To restrict certain assignments?
Aren't the base types of any ordinal type either Int.T or LInt.T?
 So the check will always be true?
I have to check.


 - Jay

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

From rodney_bates at lcwb.coop  Sun Jan 10 03:34:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:34:39 -0600
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <20100108185453.GD14151@topoi.pooq.com>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>	<20100107131117.GA22266@topoi.pooq.com>	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
Message-ID: <4B493CBF.4080302@lcwb.coop>



hendrik at topoi.pooq.com wrote:
>> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

And:

 > Is it even necessary for a compiler to implement -128..127 as more than
 > one byte?


And:

 >> One thing that is very much needed in a language (not the only thing)
 >> is a type that always matches the implementation's native arithmetic
 >> size, which is most efficient.  If you don't distinguish this type,
 >> it becomes either impossible or horribly convoluted to define arithmetic
 >> so native machine arithmetic can be usually used where possible,
 >> but multi-word arithmetic will be used where needed.
 >
 > Yes.  You do need this type.  And you can even call it INTEGER.  But is
 > there any reason it cannot be a predefined subrange type of LONGINT?

When storing a value in a variable, the compiler can store subranges in fields
just big enough to hold the value range, or somewhere between that size and
the size of the base type.  Sometimes, like -128..127, it probably should store
it in a byte, and if the type is BITS 10 FOR 0..1023 and it's a field or array
element, it must store in exactly 10 bits.

But the question that creates trouble is not how many bits to store variables
in, but how many bits to do arithmetic in.  This affects when/whether overflows
can occur.  I define an overflow as a case where the mathematically correct
value is, for whatever reason, not what you get.  By "mathematically
correct", I mean in the system of (unbounded) integers, not a modular arithmetic.
The usual reason you don't get the correct value is that it won't fit in the
field you are doing arithmetic in.

What happens then is an orthogonal question.  Is there an exception?  Do we
have a code like a NaN?  Does it wrap modulo the word size? random bits?
But our problems with INTEGER and LONGINT have only to do with when does an
overflow happen.

In Modula-3 and with only INTEGER and its subranges, the arithmetic is always
done in the full range of INTEGER, even if the operands have subrange types.
This follows from the facts that:

1) The language defines (for the + example) only + (x,y: INTEGER) : INTEGER,
    but not any + operations on any subrange(s) of INTEGER.

2) The operands of + have no parameter mode specified, which means the mode
    is VALUE.

3) The rule for VALUE mode is that the actual parameter need only be assignable
    to the formal, not necessarily of the same type.

So if we have VAR a: [0..10];  VAR b: [20..30];, then the expression a+b
is evaluated by effectively doing the assignments x:=a, y:=b to the formals
x and y of +, before evaluating the +.  At the machine level, the compiler will
have to do a representation conversion of each subrange by expanding it to
a full integer, then do the add on these, with an INTEGER result.  And the
range of INTEGER then determines when overflows occur.  Moreover, a reasonable
implementation will choose the range of INTEGER to match the native machine
arithmetic of the target machine, which is the most efficient arithmetic
available.

This is about as near to tidy a way as possible to cope with the very untidy
fact that computer arithmetic on what we call "integers" is different from the
integers of mathematics.

Now suppose we need a larger-than-native range arithmetic for selected purposes.
If we try to do it by just having one integer type that is as large as anybody
could want and then let programmers choose a subrange othat happens
to match the target's native arithmetic, whenever that is enough range,
it gets a lot uglier.  Storing variables of this subrange in native words
will work fine.

But the size arithmetic is done in is the problem.  The only way to preserve
the relative tidiness  of the system of subranges would be to have every
subrange value's representation expanded to the largest size, then do
the arithmetic in that size.  But this loses the efficiency of native
arithmetic on _every_ operation, something we just can't afford.

So INTEGER has to have some special properties that arbitrary subranges
do not, namely that it is a size arithmetic is done in, if neither operand
has a larger range.  Having two distinct base types is a lot cleaner
and less misleading than trying to pretend that INTEGER is just a particular
case of a subrange.

This is messy.  But it's about the best we can do, given the difference
between efficient hardware "integer" arithmetic and the integer arithmetic
of mathematics.

Note that you can't fix this by trying to use the value range of where the
final expression result is to be assigned/passed/whatever.  Then the rules
just get a whole lot more complicated (for programmer and compiler alike),
and the cases where overflow can occur get a lot harder to anticipate.  And the
likelihood they are what is wanted is not good either.  You might have a
distant chance at this if an expression could have at most one operator,
but multiple operators and intermediate results make it a tar pit.




From hendrik at topoi.pooq.com  Sun Jan 10 03:57:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 21:57:56 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
Message-ID: <20100110025755.GA17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
> Do you recall why CARDINAL is defined to behave like 
> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?

It's so that all CARDINALs are INTEGERs, presumably back when it was 
thought important to have only one base type on top of the type 
hierarchy.  I've always thought that was a mistake.

The simplest way to avoid that with LONGINT is to let programmers use 
only subranges of LONGINT, and to impose no limit on those subranges 
except for mamory capacity.

This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
either.

-- hendrik


From rodney_bates at lcwb.coop  Sun Jan 10 03:44:26 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:44:26 -0600
Subject: [M3devel] latest longint file size diffs
In-Reply-To: <COL101-W177E347253C078605A975CE66F0@phx.gbl>
References: <COL101-W6589885434F72540E58F5BE6700@phx.gbl>, , , ,
	<1A6881F8-8DFE-4931-9BFC-1BB4DB7D3E5B@cs.purdue.edu>, ,
	<COL101-W227DA63CDB23597FEEDDFCE66F0@phx.gbl>, ,
	<98228FAE-31EB-43CA-83CB-58FE7323A964@cs.purdue.edu>,
	<COL101-W49484AC8381918B22D9D9BE66F0@phx.gbl>
	<COL101-W177E347253C078605A975CE66F0@phx.gbl>
Message-ID: <4B493F0A.7030500@lcwb.coop>



Jay K wrote:
> Uh, maybe all ordinal types that overlap in any values are assignable?
>  

Yes, exactly.  From 2.3.1:

   "A type T is _assignable_ to a type U if:
   .. <two other cases,> ..
   or T and U are ordinal types with at least one member in common."

For an _expression_ to be assignable to T, some additional things must
be checked, some of them at runtime.

>  
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
>     ELSIF IsSubtype (a, b) THEN
>       (* may be ok, but must narrow rhs before doing the assignment *)
>       RETURN IsSubtype (b, Reff.T)
>           OR ArrayType.Split (b, i, e)
>           OR (IsSubtype (b, Addr.T)
>               AND (NOT Module.IsSafe() OR NOT IsEqual (b, Addr.T, NIL)));
>     ELSE
>       RETURN FALSE;
>     END;
>   END IsAssignable;
> 
>  
> ?
> I'll try it out.
>  
>  
> What is an ordinal type?, I wonder, the compiler implementation:
>  
>  
> PROCEDURE IsOrdinal (t: T): BOOLEAN =
>   VAR u := Check (t);  c := u.info.class;
>   BEGIN
>     RETURN (c = Class.Integer) OR (c = Class.Longint) OR (c = 
> Class.Subrange)
>            OR (c = Class.Enum) OR (c = Class.Error)
>            OR ((c = Class.Packed) AND IsOrdinal (StripPacked (t)));
>   END IsOrdinal;
> 
>  
>  - Jay
> 
> 
> 
> 
> 
>  
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 07:52:29 +0000
> 
> ok, yeah, it does bug me.
> 
> With 8 bit integer, 16 bit longint.
> 
> Let's replace 128 with 127 + 1.
> 
>  (127 + 1) > 127
> 
> either:
>   is true
>   or false
>   or raises an exception
> 
> "Obviously" it should be true, but implementing that is..uncertain.
> Though, again, it should really raise the exception before the 
> comparison is made.
>   Maybe it does.
> 
> Where (127 + 1L) > 127
> 
> is simply true, no controversy..except for the difference with 127 + 1.
> 
> But Rodney said something..that mixed operations fall out of
> assignability. Right??
> 
> 
> I have an idea..I mean..an obvious guess/experiment.
> I can try providing only for bidirectional assignability
> and see what the affect on rd/wr is.
> Maybe bidirectional assignability is enough to
> keep the diff small?
> Or, maybe my initial big diff with ORD/VAL everywhere is acceptable?
>    Clearly it will be allowed by any of the proposals, it
>    just might not be necessary.
> 
> 
> Also, btw, I think we should warn for truncating assignment.
> Any time a range check is put in, perhaps.
> Except maybe not on array indexing.
> Which might leave this suggestion completely ambiguous as
> to when a warning should be issued.
> 
> But as has been pointed out, while it may be "annoying" and
> "inconvenient" to put ORD and VAL everywhere, or at least ORD,
> it does force us to revisit all those locations where a change
> is being induced.
> 
> Notice that that the warning may or may not be platform specific.
> It might trigger only on 32bit platforms.
> Or the compiler targeting 64bit platforms might "know" about
> the truncation potential on other platforms and warn.
> In a specific concrete way, assignment of LONGINT to INTEGER
> might warn, no matter their current exact sizes.
> 
> 
> Extending that rule to subranges might be tricky.
> TYPE A = [0..LAST(INTEGER)/2];
> TYPE B = [0..LAST(LONGINT)/2];
> VAR a: A; b:B;
> 
> a := b;   warn?
> 
> Implementing that, maybe, would require, like a bit carried along
> with type definitions in the compiler, as to if the definition
> contains a platform independent size in it...er..
> if the size is dependent on bitsize(integer) or not, and
> mixing of that type with any? other type is a warning?
> Clearly no. Mixing with a type dependent on bitsize(longint)?
> Maybe.
> 
> I'm not sure what the rule is, but, you know, it'd be nice
> if above code did warn on 64bit targets, in order to
> encourage portability to 32bit targets.
> 
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 07:01:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
>  > (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> ps: a beginner wouldn't necessarily expect this.
> He might expect an error or widening of precision as needed.
> Eventually faced with the cruel realities of what can be efficiently 
> implemented,
> he might accept any of our answers. :)
> 
>  - Jay
> 
> ------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] latest longint file size diffs
> Date: Sat, 9 Jan 2010 06:59:52 +0000
> 
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?
> 
> 
> And heck, shouldn't max + 1 already throw an exception?
> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:04:13 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:04:13 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
References: <0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
Message-ID: <20100110030412.GB17629@topoi.pooq.com>

On Sun, Jan 10, 2010 at 12:05:23AM +0000, Jay K wrote:
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?

Let's add -16_080000003L to +16_7ffffffff.
The sum should be 4.
What you propose will give overflow when assigning LONGINT to INTEGER.
You have to do the addition as LONGINT and then assign the sum to 
INTEGER.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 10 04:07:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:07:25 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
References: <COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
Message-ID: <20100110030725.GC17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 07:21:38PM -0500, Tony Hosking wrote:
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> > Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> > However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> > FooExpr.m3 file, not just delegate to IsAssignable;
> > Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> > the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get 
> carried away thinking there'll be more.

There will be more, sooner or later.  Let's design for more, even if we 
don't implement it all right away.

-- hendrik



From rodney_bates at lcwb.coop  Sun Jan 10 03:54:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 09 Jan 2010 20:54:51 -0600
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
Message-ID: <4B49417B.7060806@lcwb.coop>

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
     denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
     designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
     to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>   Or really, with runtime bounds check against the array size.
>  
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a 
> common base...
>  
>  
>  - Jay
> 
> 
> 
> 
> 


From hendrik at topoi.pooq.com  Sun Jan 10 04:28:28 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 9 Jan 2010 22:28:28 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <4B493CBF.4080302@lcwb.coop>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>
	<20100107131117.GA22266@topoi.pooq.com>
	<20100107145210.0ooessu9wg8k48co@mail.elegosoft.com>
	<2E21F50B-4710-4123-BB1F-FDF77CDB8C59@cs.purdue.edu>
	<20100108114448.3fukoteb40og04og@mail.elegosoft.com>
	<20100108185453.GD14151@topoi.pooq.com>
	<4B493CBF.4080302@lcwb.coop>
Message-ID: <20100110032828.GD17629@topoi.pooq.com>

On Sat, Jan 09, 2010 at 08:34:39PM -0600, Rodney M. Bates wrote:
> 
> 
> But the question that creates trouble is not how many bits to store 
> variables
> in, but how many bits to do arithmetic in.  This affects when/whether 
> overflows
> can occur.  I define an overflow as a case where the mathematically correct
> value is, for whatever reason, not what you get.  By "mathematically
> correct", I mean in the system of (unbounded) integers, not a modular 
> arithmetic.
> The usual reason you don't get the correct value is that it won't fit in the
> field you are doing arithmetic in.
> 
> In Modula-3 and with only INTEGER and its subranges, the arithmetic is 
> always
> done in the full range of INTEGER, even if the operands have subrange types.
...
...
> 
> But the size arithmetic is done in is the problem.  The only way to preserve
> the relative tidiness  of the system of subranges would be to have every
> subrange value's representation expanded to the largest size, then do
> the arithmetic in that size.  But this loses the efficiency of native
> arithmetic on _every_ operation, something we just can't afford.
> 
> So INTEGER has to have some special properties that arbitrary subranges
> do not, namely that it is a size arithmetic is done in, if neither operand
> has a larger range.  Having two distinct base types is a lot cleaner
> and less misleading than trying to pretend that INTEGER is just a particular
> case of a subrange.
> 
> This is messy.  But it's about the best we can do, given the difference
> between efficient hardware "integer" arithmetic and the integer arithmetic
> of mathematics.
> 
> Note that you can't fix this by trying to use the value range of where the
> final expression result is to be assigned/passed/whatever.  Then the rules
> just get a whole lot more complicated (for programmer and compiler alike),
> and the cases where overflow can occur get a lot harder to anticipate.  And 
> the
> likelihood they are what is wanted is not good either.  You might have a
> distant chance at this if an expression could have at most one operator,
> but multiple operators and intermediate results make it a tar pit.
> 
> 

GOt that.  INTEGER is not a subrange of LONGINT because its arithmetic 
is different.

And the reason INTEGER has all its restrictions is simply to be 
able to use efficient machine arithmetic, and to make it clear that 
efficient machine arithmetic will be used.  This is why we don't 
expand "every subrange value's representation ... to the largest size, 
then do the arithmetic in that size."

But it is quite possible to performs operation on LONGINT subranges to 
produce results that are as long as necessary to be mathematically 
exact, because the whole point of LONGINT is to use it for numbers that 
do not fit the word size for the most efficient machine arithmetic.  
We're want to use subranges of LONGINT that match the requirements of 
an application, whether those subranges fit the most desirable machine 
word size or not.

-- hendrik



From hosking at cs.purdue.edu  Sun Jan 10 05:12:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:12:22 -0500
Subject: [M3devel] IsAssignable
In-Reply-To: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
References: <COL101-W136DDD066D445FEBDBCA21E66E0@phx.gbl>
Message-ID: <B816E60E-8AEB-4CD5-97C7-54FA0B235ED3@cs.purdue.edu>

Base type of an enumeration is itself!

On 9 Jan 2010, at 21:05, Jay K wrote:

> Current:
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if there is a common supertype
>          and they have at least one member in common. *)
>       IF IsEqual (Base(a), Base(b), NIL)
>          AND GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> my proposed:
> 
> 
> 
> PROCEDURE IsAssignable (a, b: T): BOOLEAN =
>   VAR i, e: T;  min_a, max_a, min_b, max_b, min, max: Target.Int;
>   BEGIN
>     IF IsEqual (a, b, NIL) OR IsSubtype (b, a) THEN
>       RETURN TRUE;
>     ELSIF IsOrdinal (a) THEN
>       (* ordinal types:  OK if they have at least one member in common. *)
>       IF GetBounds (a, min_a, max_a)
>          AND GetBounds (b, min_b, max_b) THEN
>         (* check for a non-empty intersection *)
>         min := min_a;  IF TInt.LT (min, min_b) THEN min := min_b; END;
>         max := max_a;  IF TInt.LT (max_b, max) THEN max := max_b; END;
>         RETURN TInt.LE (min, max);
>       ELSE
>         RETURN FALSE;
>       END;
> 
> 
> Your proposed:
> 
> > IF (IsEqual (Base(a), Base(b), NIL)
> > OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
> > OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
> > AND GetBounds (a, min_a, max_a)
> > AND GetBounds (b, min_b, max_b) THEN
> 
> What's the point of checking the types? Given that they are both ordinal?
> To restrict certain assignments?
> Aren't the base types of any ordinal type either Int.T or LInt.T?
>  So the check will always be true?
> I have to check.
> 
> 
>  - Jay
> 

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

From hosking at cs.purdue.edu  Sun Jan 10 05:13:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:13:13 -0500
Subject: [M3devel] LONGINT, my original proposal
In-Reply-To: <20100110025755.GA17629@topoi.pooq.com>
References: <4B476316.4000005@lcwb.coop>
	<961DBA0B-87E8-4683-A9E1-CB8A84D802B9@cs.purdue.edu>
	<4B48FFF4.8050307@lcwb.coop>
	<73144E4F-24FF-4CD3-BEB7-D015720CD74C@cs.purdue.edu>
	<20100110025755.GA17629@topoi.pooq.com>
Message-ID: <9CFA3CF7-98EE-430E-B0C3-8575FBF1A732@cs.purdue.edu>

That is a drastic (and I think fatal) departure from the spirit of the language.

On 9 Jan 2010, at 21:57, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 09, 2010 at 05:45:09PM -0500, Tony Hosking wrote:
>> Do you recall why CARDINAL is defined to behave like 
>> [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> It's so that all CARDINALs are INTEGERs, presumably back when it was 
> thought important to have only one base type on top of the type 
> hierarchy.  I've always thought that was a mistake.
> 
> The simplest way to avoid that with LONGINT is to let programmers use 
> only subranges of LONGINT, and to impose no limit on those subranges 
> except for mamory capacity.
> 
> This also means we don't have a FIRST(LONGINT) or a LAST(LONGINT) 
> either.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Sun Jan 10 05:14:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:14:57 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , , , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , , , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, , ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, , ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>, ,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>,
	<COL101-W11D8AFCB4741E550CB73CDE66E0@phx.gbl>,
	<DEBB6AA8-CB70-4E17-85F5-C357A5F070D0@cs.purdue.edu>
	<COL101-W50FBD58B70151E4701D1BFE66E0@phx.gbl>
Message-ID: <4440BF94-9372-4A3E-B0BF-03A5DFEA7E45@cs.purdue.edu>

On 9 Jan 2010, at 19:31, Jay K wrote:

> I noticed unary plus doesn't seem to be valid for LONGINT.
> That is fixed among my other diffs.
> 
> I understand it matters little to take this "algorithmic" approach to determining
> if an AddExpr is valid. We haven't yet agreed it will even change from current,
> though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
> and then add it, or vice versa, why not just allow the direct addition?
> Force the programmer through hoops so the code is much clearer?

Yes, clarity is important.

> Or too verbose?

Verbosity is sometimes valuable.  It spells things out.

> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 19:21:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 19:15, Jay K wrote:
> 
> Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
> However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
> FooExpr.m3 file, not just delegate to IsAssignable;
> Possibly the return type could be "calculated", like as being the "larger" type in most cases,
> the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;
> 
> It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
> 
> I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] another longint variant
> Date: Sun, 10 Jan 2010 00:12:06 +0000
> 
>  > I believe Rodney said something like "mixed operations follow from assignability";
>  > and from a language point of view, that may be true, just not from the point of view;
> 
> I meant to say, not from the language implementation point of view.
> 
> Again, if I can assign and then add, might as well just allow add?
> Ditto assign and index, assign and multiply, etc.
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 00:05:23 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> Sorry something wasn't clear.
> If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
> Annoying, voluminous, but should suffice.
> I'll do it again if you need.
> 
> 
> With mixed operations and assignability, the only change outside libm3 is
>  changing the signatures of Length and Seek
>  and the FOR change, though that's just because I didn't really finish
>    the mixed operation change.
> 
> 
> I just meant that assignability fix in the compiler doesn't suffice
>   to actually enable mixed operations.
> 
> 
> I believe Rodney said something like "mixed operations follow from assignability";
> and from a language point of view, that may be true, just not from the point of view;
> 
> 
> You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
> what is the difference vs. just allowing direct addition?
> 
> 
> VAR i1,i2:INTEGER;
>        j1: LONGINT;
> 
> 
> i1 := j1;
> INC(i2, i1);
> 
> 
> vs.
> INC(i2, j1);
> 
> 
> If the first is allowed, shouldn't the second?
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 15:54:22 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant
> 
> On 9 Jan 2010, at 15:17, Jay K wrote:
> 
> [replacing periods with semicolons to avoid truncation..]
>  
>  
> Right..I was going to say..as an overall change, like if we
> want mixed operations, it really doesn't suffice;
> Many of my m3front changes were in direct response
> to compilation errors and fixed them;
> 
> I'd like precise examples.
> 
>  I'm sure as well that just allowing assignability doesn't make the rd/wr
> change particuarly small/smooth. You need mixed operations,
> indexing, new, or else sprinkle ORD around;
> 
> I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
> 
>  There's a particular characteristic I should point out in the rd/wr code;
> Maybe rd/wr should be modified..but it probably can't;
> In particular, my understanding of rd/wr is that the maintain two
> "numbers" (integer or longint, depending on how everything is resolved);
> These numbers indicate the file offset that is at the start of the buffer
> and at the end of the buffer. In a new world they need to be LONGINT;
> However their "span", their difference, describes an
> in-memory buffer size. Therefore their difference is always INTEGER
> or CARDINAL, not LONGINT. It'd be super cool, but probably not
> possible, if the language let you declare this somehow.
> THEN mixed operations and such wouldn't be needed,
> if the compiler new that subtracting these two integers
> yielded an INTEGER, and possibly inserted checks of that;
> But this is probably just a lazy user view and not realistic
> for the language.
> 
> That would be tricky...
> 
>  For assignability I think your change does work but mine was less wordy
> and maybe more general;
> 
> No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
> 
> The preexisting code allowed I believe any non-LONGINT ordinal
> type to be assigned to any non-LONGINT ordinal type if there
> are any overlapping values. Specifically really,
> non-ordinal types with same base type and anyoverlap.
> I removed the base type check;
> 
> That's what broke it.
> 
> This makes enums <=> longint, integer subranges <=> longint, etc;
> 
> Can I convince you to work things up with my trivial change?
> 
> I really want to see the impact of not allowing mixed arithmetic while having assignability.
> 
> 
>  - Jay
> 
>  
> Subject: Re: [M3devel] another longint variant
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 13:30:55 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
> 
> On 9 Jan 2010, at 05:22, Jay K wrote:
> 
> [attached]
> In this variant, the compiler has been made
>  "maximally lenient" and the rd/wr changes are minimized.
>  
> 
> Specifically:
>   compiler allows assignment either way and various math
>   operations, including NEW array and array subscript.
>   mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)
>  
> 
>   rd/wr changes outside libm3 are only changing
>    the signatures of Seek and Length
>    pretty minimal, and hard to imagine they could be smaller,
>     though actually they could..well..the need to fix existing
>     rd/wr could be eliminated/delayed
>     rd/wr could introduce SeekL, LengthL which by default
>     call Seek/Length, and then rd/wr could gradually convert,
>     and not gain 4GB capability until then
>  
> 
>   no VAL or ORD needed
> 
>  
>   some rd/wr implementations might be artificially limited
>   to 4G simply because they don't chane some INTEGER to LONGINT;
>   "anything compiles"
>  
> 
>   some of the compiler changes are probably slightly off or incomplete
>    including a need to insert the checks for LONGINT => INTEGER
> 
> <dif3.txt>
> 
> 
> 
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sun Jan 10 05:16:37 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:16:37 -0500
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, , , ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>, , ,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <CD3E8BA5-E655-4253-A4CE-52A3FECBE3C2@cs.purdue.edu>

Hear, hear!

On 9 Jan 2010, at 19:25, Mika Nystrom wrote:

> Jay K writes:
>> --_953e6126-a89e-4966-8f22-5ccff92e7117_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>>> I believe Rodney said something like "mixed operations follow from assig=
>> nability"=3B
>>> and from a language point of view=2C that may be true=2C just not from t=
>> he point of view=3B
>> 
>> I meant to say=2C not from the language implementation point of view.
>> 
>> Again=2C if I can assign and then add=2C might as well just allow add?
>> Ditto assign and index=2C assign and multiply=2C etc.
>> 
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious.  I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
>    Mika

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

From hosking at cs.purdue.edu  Sun Jan 10 05:22:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:22:44 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <4B49417B.7060806@lcwb.coop>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>
	<4B49417B.7060806@lcwb.coop>
Message-ID: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>

That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.

For example:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

did not result in a run-time error.  I think I have fixed that now (commit to come).

But, even worse:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;

also does not give a run-time error.

The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!

On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
>> Index array by longint?
>> With runtime check that it is <= LAST(INTEGER)?
>>  Or really, with runtime bounds check against the array size.
>> Seems reasonable?
>> Aids the rd/wr change.
>> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>>   - Jay

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

From hosking at cs.purdue.edu  Sun Jan 10 05:33:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:33:57 -0500
Subject: [M3devel] Integer overflow
Message-ID: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>

So, in my experiments with range checking on integers, I have been playing with the overflow case:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;

Should this fail at runtime with a range check error?

The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).

If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From hosking at cs.purdue.edu  Sun Jan 10 05:38:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:38:42 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <B808326A-8BD2-416B-8F7D-032FCA29E05E@cs.purdue.edu>

One take on this is that it certainly lets you check for overflow explicitly! ;-)

On the other hand, it seems unreasonable that you could end up with a CARDINAL holding a negative value!

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 05:42:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 04:42:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
Message-ID: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>


There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?



That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
    designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
    to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
  Or really, with runtime bounds check against the array size.
 Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
   - Jay

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

From hosking at cs.purdue.edu  Sun Jan 10 05:45:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:45:29 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
Message-ID: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>

Even under the interpretation for INC that yields:

VAR s: CARDINAL := LAST(INTEGER);
BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;

the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.

In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.

On 9 Jan 2010, at 23:33, Tony Hosking wrote:

> So, in my experiments with range checking on integers, I have been playing with the overflow case:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> Should this fail at runtime with a range check error?
> 
> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
> 
> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 



From hosking at cs.purdue.edu  Sun Jan 10 05:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 9 Jan 2010 23:46:39 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>
Message-ID: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>

I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.

On 9 Jan 2010, at 23:42, Jay K wrote:

> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 07:11:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 06:11:18 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
Message-ID: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;
c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay



Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu



I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
On 9 Jan 2010, at 23:42, Jay K wrote:There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?

That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
 Or really, with runtime bounds check against the array size.
Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
  - Jay


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

From hosking at cs.purdue.edu  Sun Jan 10 08:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 02:37:45 -0500
Subject: [M3devel] index array by longint?
In-Reply-To: <COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>,
	<4B49417B.7060806@lcwb.coop>,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>
Message-ID: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>

Try to frame this in terms of assignability...

If the operators themselves were typed then there would be no problem.

But when they aren't we get into a real mess trying to remember what the promotion rules are.

On 10 Jan 2010, at 01:11, Jay K wrote:

> I don't think there is madness here.
> I believe the half range of CARDINAL helps avoid it.
> A confusing point in C is comparison that includes conversion
> is magnitude or sign preserving -- comparing int and unsigned.
> 
> Back to Modula-3:
> 
> a := b;
> c := a + d;
> 
> vs.
> 
> c := b + d;
> 
> 
> are different?
> Isn't that strange?
> 
> 
> Compare with
> a : = b;
> c := d[a];
> 
> and
> 
> c := d[b];
> 
> we have decided they are the same, among others.
> 
> 
> There's something about "kinda sorta transitive" here.
> Or, like, "why should I have to move values through temporaries in some
> cases but not others?"
> 
>  - Jay
> 
> 
> 
> Subject: Re: [M3devel] index array by longint?
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:46:39 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
> 
> On 9 Jan 2010, at 23:42, Jay K wrote:
> 
> There are more cases:
> 
> =, #, <, >, IN, etc. have this same "you can mix
> if they are assignable" rule.
> 
> http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html
> 
>      infix    =, #  (x, y: Any): BOOLEAN
> The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
> ...
> 
> 
> Other places demand equal types:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html
> 
> inc/dec sound looser:
> http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html
> 
> 
> I still think mixed operations are reasonable and the result types not so surprising.
> a := b;
> 
> vs. a := b + c;
> 
> The first is clear even if and b have different types, but the second is not, if b and c have different types?
> They seem pretty equally clear/unclear to me..
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 23:22:44 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] index array by longint?
> 
> That's very nice!  I like it.  I think we can use it....
> 
> Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
> 
> For example:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN INC(s) END;
> 
> did not result in a run-time error.  I think I have fixed that now (commit to come).
> 
> But, even worse:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
> 
> also does not give a run-time error.
> 
> The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
> 
> On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:
> 
> When writing my original proposal, I agonized at length over whether
> to allow (subranges of) LONGINT to be the index type of an array type.  In the
> end, I decided that gave a poor ratio of practical benefit to language
> and implementation complexity.
> 
> However, note, from 2.6.3, "Designators,
> 
> "a[i]
>    denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
>    designator if a is, and is writable if a is. The expression i must be assignable
> --------------------------------------------------------------------------^
>    to the index type of a. The type of a[i] is the element type of a."
> 
> So, by existing rules about assignability, when referring to an element of an
> array, the subscript expression could have base type LONGINT, and would just
> be "assigned" in the usual way to the index type, a subrange of INTEGER.
> This is one of the dozen or so places assignability is used in the language.
> 
> 
> 
> Jay K wrote:
> Index array by longint?
> With runtime check that it is <= LAST(INTEGER)?
>  Or really, with runtime bounds check against the array size.
> Seems reasonable?
> Aids the rd/wr change.
> A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
>   - Jay
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sun Jan 10 08:58:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 07:58:56 +0000
Subject: [M3devel] index array by longint?
In-Reply-To: <3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
References: <COL101-W25EB03400456BFD5F5BF16E66F0@phx.gbl>, ,
	<4B49417B.7060806@lcwb.coop>, ,
	<4F4DE877-9495-4E2D-910C-F55473E92F06@cs.purdue.edu>,
	<COL101-W592DB36017FDDCE39B703EE66E0@phx.gbl>, ,
	<2B01D3D0-70D5-4DDD-8778-965325B18588@cs.purdue.edu>,
	<COL101-W142FEA370EF819E63CD12EE66E0@phx.gbl>,
	<3D1F9FE5-412E-4F2F-9C6F-89DDA439D70F@cs.purdue.edu>
Message-ID: <COL101-W39FE16CBEE45212C4E6979E66E0@phx.gbl>


It is easy to frame in terms of assignability?

  a + b is legal if a is assignable to b, or b is assignable to a  

 

If you don't allow INTEGER := LONGINT,

then you can say, like:

 

a + b is legal if a is assignable to b or b is assignable a (or both);

if a and b are of different type, and only one is assignable to the

other, then the result type is that of the assignable-to type.

 

If INTEGER := LONGINT, then I'm not sure how to formally

define the result. Something informal:

a + b is legal if a or b is assignable to the other

the result type is the "larger" or "wider" type -- whatever that means;

However, I think there is an easy enough to define set of rules.

It varies for each operator though.

 

Basically, first, the notion of "larger" or "wider" isn't

all that unscientific. It needs a little honing though;

 

 

a + b is legal if a is assignable to b or b is assignable to a (or both).

If a and b are of the same type, that is the result type.

If a and b are of different types, but one of their types can

  represent without loss all the values of the other type,

  then that is the result type.

If a and b are of different types, and neither type can represent

  all of the values of the other type, then the result type is

   INTEGER if it can represent all the members of the types of a and b,

   else LONGINT.

 

 

The result type is stated in terms of the input types.

Not in terms of the output range.

This is a general fact of life with addition anyway.

The result of adding two integers is an integer, even though integer

cannot hold the output range.

 

 

I have a strong suspicion that we would be more satisified

with our rules if overflow checking was present.

 

 

Heck, maybe we'd have something wierd where INTEGER + INTEGER

actually yielded LONGINT, but then LONGINT is assignable to INTEGER?

The overflow check would actually be at the assignment/narrowing?

Heck, it's not like double precision arithmetic is even so expensive?

 

 

What do you mean by, reworded, "the operators aren't typed"

 

 

- Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 02:37:45 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




Try to frame this in terms of assignability...


If the operators themselves were typed then there would be no problem.


But when they aren't we get into a real mess trying to remember what the promotion rules are.


On 10 Jan 2010, at 01:11, Jay K wrote:


I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;

c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay





Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu


I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.





On 9 Jan 2010, at 23:42, Jay K wrote:

There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay




From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?




That's very nice!  I like it.  I think we can use it....

Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.


For example:


VAR s: CARDINAL := LAST(INTEGER);
BEGIN INC(s) END;


did not result in a run-time error.  I think I have fixed that now (commit to come).


But, even worse:


VAR s: CARDINAL := LAST(INTEGER);

BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;


also does not give a run-time error.


The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!



On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:

When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:

Index array by longint?

With runtime check that it is <= LAST(INTEGER)?

 Or really, with runtime bounds check against the array size.

Seems reasonable?

Aids the rd/wr change.

A little bit of pain to implement..unless INTEGER and LONGINT have a common base...

  - Jay



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

From jay.krell at cornell.edu  Sun Jan 10 09:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 08:55:31 +0000
Subject: [M3devel] another longint variant
In-Reply-To: <20100110002552.683AA1A2078@async.async.caltech.edu>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>,,, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	,,<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>, , ,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>, ,
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>, ,
	<0DA1F27C-363E-43C8-AC09-E5FD1BDED6BC@cs.purdue.edu>,
	<COL101-W44B3B0140A37B8C5E51899E66E0@phx.gbl>
	<COL101-W65B8ABC0DC3169EED89B84E66E0@phx.gbl>,
	<20100110002552.683AA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63918AA105D02C46D86E5AE66E0@phx.gbl>


> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.


You were using a bad compiler or at least bad switches:

C:\>type t.c


void F1()
{
 F2();
}

C:\>cl -c -W4 -WX t.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
t.c(5) : error C2220: warning treated as error - no 'object' file generated
t.c(5) : warning C4013: 'F2' undefined; assuming extern returning int

 

and C++ always errors.


 - Jay

 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] another longint variant 
> Date: Sat, 9 Jan 2010 16:25:52 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >--_953e6126-a89e-4966-8f22-5ccff92e7117_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> > > I believe Rodney said something like "mixed operations follow from assig=
> >nability"=3B
> > > and from a language point of view=2C that may be true=2C just not from t=
> >he point of view=3B
> >
> >I meant to say=2C not from the language implementation point of view.
> >
> >Again=2C if I can assign and then add=2C might as well just allow add?
> >Ditto assign and index=2C assign and multiply=2C etc.
> >
> 
> The problem is that it's sometimes ambiguous what the result type is.
> 
> If you want to get into this kind of mess, why don't you just program in C...
> 
> I think this area is probably one of the reasons some people *like* Modula-3.
> We don't want to have to guess what an expression means... it should be obvious.
> If there are "promotion rules" it's just not that obvious. I'm reminded of one
> time when I was missing a prototype in a C program.............. ok that story
> could go on and on.
> 
> Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5f4fff7d/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 10 10:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W115A210D309977FBB457E9E6710@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
Message-ID: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>


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/d57d8efd/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 10 10:52:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 09:52:32 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <COL101-W1505A74E8F75378C40431DE66E0@phx.gbl>


Well, I have to take that back.

I'm reading Rodney's proposal.

  https://mail.elegosoft.com/pipermail/m3devel/attachments/20100108/52ebf7d7/attachment.txt 

 

Notable so far:

  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.

  He defines ORD as possibly returning LONGINT. Which breaks my assertion below.

  But he doesn't allow indexing an array by LONGINT.

  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?

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 09:10:52 +0000
Subject: Re: [M3devel] what to do about file sizes being 32bits?



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/e9197775/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 10 11:26:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken
Message-ID: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>


Tony, with the recent changes:

 

1)

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...


 

2) If I fix that by removing cas/casp more completely:


 

C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3

(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>

 

looks like maybe an off by one problem?

Since the pointer is near valid memory?

Any ideas?

I'll poke around.

 

 

Going back to the release branch versions fixes this.

 

 

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

From jay.krell at cornell.edu  Sun Jan 10 11:38:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 10:38:52 +0000
Subject: [M3devel] m3front broken
In-Reply-To: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
References: <COL101-W44C843E478BCEB918B456EE66E0@phx.gbl>
Message-ID: <COL101-W56F490C4603C9ADBA56B01E66E0@phx.gbl>


nevermind, I see the problem, fix shortly

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; m3devel at elegosoft.com
Date: Sun, 10 Jan 2010 10:26:28 +0000
Subject: [M3devel] m3front broken



Tony, with the recent changes:
 
1)
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\misc\Scanner.m3", line 351
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f774   0x49c8e2  NoteReserved + 0x44 in ..\src\misc\Scanner.m3
 0x12f7ac   0x4cb247  Define + 0xf9 in ..\src\values\Procedure.m3
 0x12f7d4   0x517b7b  Initialize + 0xd5 in ..\src\builtinOps\Cas.m3
 0x12f7e8   0x4b0320  Initialize + 0x30 in ..\src\builtinOps\BuiltinOps.m3
 0x12f804   0x499341  Initialize + 0x9a in ..\src\misc\M3Front.m3
 0x12f834   0x498f81  ParseImports + 0x151 in ..\src\misc\M3Front.m3
 0x12f860   0x40a6eb  Pass0_CheckImports + 0xa4 in ..\src\Builder.m3
 0x12f8ac   0x409e87  RunM3 + 0x215 in ..\src\Builder.m3
 0x12f8e8   0x40862c  PushOneM3 + 0x10a in ..\src\Builder.m3
 0x12f918   0x4084f9  CompileM3 + 0x21d in ..\src\Builder.m3
.........  .........  ... more frames ...

 
2) If I fix that by removing cas/casp more completely:

 
C:\dev2\cm3.2\scripts\python>\bin\x86\cdb \cm3\bin\cm3
(254c.2440): Access violation - code c0000005 (first chance)
cm3!RTType__HashBrand+0x41:
0064630a 8a5600          mov     dl,byte ptr [esi]          ds:0023:00ebb000=??
0:000> r esi
esi=00ebb000
0:000> db @esi - 4
00ebaffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
0:000> .lines
Line number information will be loaded
0:000> k
ChildEBP RetAddr
0012fe4c 00644c90 cm3!RTType__HashBrand+0x41 [..\src\runtime\common\RTType.m3 @
815]
0012fe70 00644db2 cm3!RTType__NoteBrand+0x1b [..\src\runtime\common\RTType.m3 @
150]
0012fe94 00634928 cm3!RTTypeSRC__AddTypecell+0xa3 [..\src\runtime\common\RTType.
m3 @ 170]
0012fec4 006346d1 cm3!RTLinker__DeclareModuleTypes+0x101 [..\src\runtime\common\
RTLinker.m3 @ 287]
0012fef8 00634227 cm3!RTLinker__FixTypes+0x8a [..\src\runtime\common\RTLinker.m3
 @ 234]
0012ff0c 006342e5 cm3!RTLinker__AddUnitI+0xe2 [..\src\runtime\common\RTLinker.m3
 @ 113]
0012ff30 00633f72 cm3!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.m3
@ 122]
0012ff54 00401029 cm3!RTLinker__InitRuntime+0x92 [..\src\runtime\common\RTLinker
.m3 @ 42]
0012ff7c 00675fda cm3!main+0x29 [_m3main.mc @ 3]
0012ffc0 7c817077 cm3!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\cr
t\src\crtexe.c @ 582]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
0:000>
 
looks like maybe an off by one problem?
Since the pointer is near valid memory?
Any ideas?
I'll poke around.
 
 
Going back to the release branch versions fixes this.
 
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/82998d8b/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 10 12:29:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 11:29:21 +0000
Subject: [M3devel] yet another longint rendition -- just mutual
 assignability, result is very tedious
Message-ID: <COL101-W345041876AF820EABD01D9E66E0@phx.gbl>


These diffs show what you can do if you merely allow assignability between

integer and longint, both ways.

  The compiler diff is included.

This is just what it takes to get libm3 to compile, having

changed a few integer to longint.

It's pretty awful in my opinion.

No changed made outside m3front and libm3, and there

  would surely be "many" needed, like the first set of diffs I sent.

  (I think those were written with no compiler change at all.)

 

I believe people wanted to see what this looks like.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/5424d2a9/attachment-0002.txt>

From hosking at cs.purdue.edu  Sun Jan 10 15:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 09:30:00 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>
Message-ID: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>

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 | Mobile +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/280301a9/attachment-0002.html>

From rcolebur at SCIRES.COM  Sun Jan 10 21:00:58 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Sun, 10 Jan 2010 15:00:58 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100110051218.2F3C42474001@birch.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>

I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


From hosking at cs.purdue.edu  Sun Jan 10 21:23:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:23:28 -0500
Subject: [M3devel] Integer literals
Message-ID: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>

One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).

It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)

Here's how things would work with subrange types.

A subrange written as currently

[lo .. hi]

would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.

A subrange with base type LONGINT would be written explicitly:

[lo .. hi] OF LONGINT

The constants lo/hi must both be in range for LONGINT.

We could also support the form:

[lo .. hi] OF INTEGER

just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.

Here we are allowing the programmer to state explicitly what the base type of the subrange should be.

Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Sun Jan 10 21:34:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:34:59 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W6B928C524DCF7E4AF027AE66E0@phx.gbl>


> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 

 

Have you seen the resulting diffs?

 

 

Would we just say, that the initial rd/wr interface was so wrong, that there

is a lot of "incorrect" code, so the ugly diff is the result?

That newer code wouldn't be so initially wrong, so would remain not so ugly?

Maybe.

 

 

VAR a:LONGINT;

      b:INTEGER;

INC(a, b);

 

 

doesn't that make perfect sense to even the most casual reader?

Many current proposals don't allow it.

  Though Randy's does allow it.

 

 

Indexing by LONGINT is also trivial.

Just do the usual range check and go.

Indexing by INTEGER also has a range check.

One difference would be that a subrange of LONGINTs that are all greater than LAST(INTEGER) could be a stack error, just as some indexing by INTEGER subranges can also be a static error (e.g. if the array element size times the all the elements of the subrange or enum are larger than the address space).

 

 

 > We need correct and maintainable software, especially at the systems level

 

Nearly all systems level software is written in a language or languages that manage to zero extend or sign extend integers to wider integers.

The Modula-3 compiler/runtime/garbage collector is the biggest exception I can think of, but so far it can't really handle large files.

 

 

 - Jay

 
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sun, 10 Jan 2010 15:00:58 -0500
> Subject: [M3devel] the LONGINT proposal
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1. LONGINT should be a distinct type different from INTEGER.
> 
> 2. There should be no mixed arithmetic between the types. The programmer must code conversions using ORD/VAL to make explicit the intention. Don't rely on some ill-remembered built-in conversion rule.
> 
> 3. Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4. WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake. I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions. We need correct and maintainable software, especially at the systems level. Whatever is decided about LONGINT, we need to keep to the original design tenants of the language. 
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type. That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance. Programs should be written to run forever or until their job is completed or they are commanded to stop. 
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal. Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all? To me this keeps the discussion focused rather than the many different emails. Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects. Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing. Who should be involved in such votes? Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/a6f5921b/attachment-0002.html>

From hendrik at topoi.pooq.com  Sun Jan 10 21:38:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 15:38:32 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <20100110203832.GA16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

And what would be the type of 2000000000 + 2000000000?  Overflow because 
2000000000 is an INTEGER?
Whereas 3000000000 + 3000000000 would end up being LONGINT?

The only solutions I see for this problem are:

(a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

or

(b) Let operations on integers automatically produce values of 
sufficiently large ranges to be able to contain the results.

(b) seems to be incompatible with the use of the most efficient integer 
operations on a machinem=, which are of fixed bit-width.

(a) is what's proposed for the LONGINT extension.

It would be possible to combine (a) and (b), using (b) only for LONGINT, 
but you seem to be dead set against this.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Sun Jan 10 21:42:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:42:55 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:

> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn

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

From jay.krell at cornell.edu  Sun Jan 10 21:43:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:43:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>


Seems fine either way.

Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
 

 

And then, if that is true, mixing should be allowed..widen any constituents

in an expression to the widest type.

 

 

I realize mixing floating point and integer is less natural, nothing about

floating point is natural really, though on a 32bit platform

LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 

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

From jay.krell at cornell.edu  Sun Jan 10 21:45:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:45:23 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
Message-ID: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>


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/e5dd2ebf/attachment-0002.html>

From hosking at cs.purdue.edu  Sun Jan 10 21:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:48:21 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100110203832.GA16635@topoi.pooq.com>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<20100110203832.GA16635@topoi.pooq.com>
Message-ID: <63BBCB94-EB03-45FE-B13A-4AC4F273E538@cs.purdue.edu>

On 10 Jan 2010, at 15:38, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 10, 2010 at 03:23:28PM -0500, Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
>> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> 
>> Here's how things would work with subrange types.
>> 
>> A subrange written as currently
>> 
>> [lo .. hi]
>> 
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> 
>> A subrange with base type LONGINT would be written explicitly:
>> 
>> [lo .. hi] OF LONGINT
>> 
>> The constants lo/hi must both be in range for LONGINT.
>> 
>> We could also support the form:
>> 
>> [lo .. hi] OF INTEGER
>> 
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> 
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
>> 
>> Literals would be be range-checked when used as arithmetic operands or 
>> in assignment, with compile-time checks that they are in range 
>> ("compatible") with the types of the other operands or the destination 
>> of the assignment.
> 
> And what would be the type of 2000000000 + 2000000000?  Overflow because 
> 2000000000 is an INTEGER?

Constant expressions would retain their "value" nature so long as the expression can be computed at compile-time without overflow up to the precision of LONGINT.

> Whereas 3000000000 + 3000000000 would end up being LONGINT?
> 
> The only solutions I see for this problem are:
> 
> (a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

This is the current implementation.  0 and 0L are the same value as INTEGER and LONGINT.

> 
> or
> 
> (b) Let operations on integers automatically produce values of 
> sufficiently large ranges to be able to contain the results.

Problematic because it imposes expensive operations on natural integers.

> (b) seems to be incompatible with the use of the most efficient integer 
> operations on a machinem=, which are of fixed bit-width.

Right.

> (a) is what's proposed for the LONGINT extension.

Not just proposed.  Implemented now for over a year.

> It would be possible to combine (a) and (b), using (b) only for LONGINT, 
> but you seem to be dead set against this.

Indeed, I am.

> 
> -- hendrik
> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 



From hosking at cs.purdue.edu  Sun Jan 10 21:51:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:51:17 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>
Message-ID: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>

No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.

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

> Seems fine either way.
> Assignability gives us, which we were missing before, VAR a:LONGINT := 0;
> 
> 
>  > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
>  > do have incompatible value representations).
>  
>  
> I keep seeing this and am surprised.
> Isn't it the case that REAL <= LONGREAL <= EXTENDED
> in terms of precision and range?
> LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
> EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
>  
>  
> And then, if that is true, mixing should be allowed..widen any constituents
> in an expression to the widest type.
>  
>  
> I realize mixing floating point and integer is less natural, nothing about
> floating point is natural really, though on a 32bit platform
> LONGREAL can hold all INTEGERS..
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 15:23:28 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] Integer literals
> 
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> 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
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sun Jan 10 21:52:16 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 15:52:16 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <ED3D3FD1-0327-4B52-9559-864AD7BEEE52@cs.purdue.edu>

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>

From jay.krell at cornell.edu  Sun Jan 10 21:53:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 20:53:12 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>,
	, , <COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
Message-ID: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>


(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>

From jay.krell at cornell.edu  Sun Jan 10 22:00:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 21:00:15 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<COL101-W496D5B1C1D0916C8DE31D8E66E0@phx.gbl>,
	<95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
Message-ID: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>


Hm..these hardware conversions..yeah they do exist.

But they are fast and lossless.

Depending on the instruction set, they aren't even avoidable.

  e.g. x86 I think usually does double arithmetic.

        68K maybe extended.

But to be clear, they tend to be a single instruction each, load or move.

Every INTEGER can be represented in a LONGINT, by sign extension.

Every REAL can be represented as LONGREAL. 

And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

 I was surprised by that actually, stepping through some hash table code,

   but it is just the way it is. There's I guess no integer division and

   the floating point is done with 64 or more bits of precision, so it works.

 

 

As long as conversion is fast and lossless..?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:51:17 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Integer literals




No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.


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

Seems fine either way.
Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not); 
 
And then, if that is true, mixing should be allowed..widen any constituents
in an expression to the widest type.
 
 
I realize mixing floating point and integer is less natural, nothing about
floating point is natural really, though on a 32bit platform
LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



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 


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

From hosking at cs.purdue.edu  Sun Jan 10 22:06:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:06:06 -0500
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>
Message-ID: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>

Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.

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

> (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/a37318d7/attachment-0002.html>

From hosking at cs.purdue.edu  Sun Jan 10 22:08:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 10 Jan 2010 16:08:18 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
References: <20100110164332.0c09a257.dimonax@att.net>
Message-ID: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>

This guy is trying to subscribe to m3devel.  Can someone help him?

Begin forwarded message:

> From: Chris <dimonax at att.net>
> Date: 10 January 2010 16:43:32 EST
> To: Tony Hosking <hosking at cs.purdue.edu>
> Subject: Re: CM3 development Inquiry.
> 
> On Fri, 8 Jan 2010 13:01:21 -0500
> Tony Hosking <hosking at cs.purdue.edu> wrote:
> 
>> Did you manage to subscribe?
> 
> I put in another subscription request just after your previous reply, and I'm still waiting. I wonder if the confirmation e-mail is getting through. Nonetheless, I'll keep trying.
> 
> 
> -- 
> Chris <dimonax at att.net>

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

From jay.krell at cornell.edu  Sun Jan 10 23:02:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:02:33 +0000
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, ,
	,,<COL101-W115A210D309977FBB457E9E6710@phx.gbl>,
	,,<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>,
	, , <C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
Message-ID: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>


Is it really just me who finds the choices all fairly obvious?

You do the math in the wider type. Is that really surprising?

  Am I just, like, brain washed with years of assumptions?

That's what Rodney's proposal said.

In the case of MOD and DIV, you can pause for thought

and maybe make them return a narrower type, but

if you just want to be simple and stay wide, that's ok.

 

 - Jay


 


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




Consider the following:  + is overloaded to perform both INTEGER and LONGINT addition.  When invoking + we choose the appropriate operation based on its operand types.  Why do you think it is reasonable to assume that LONGINT+INTEGER should perform LONGINT + instead of INTEGER +?  It is an *arbitrary* choice that you make which should give us pause in imposing that arbitrary choice in the language because it violates the principle of least surprise.  Don't impose arbitrary choices that may confuse the programmer.
Prohibiting mixed-operand operations prevents bugs arising when one programmer inadvertently assumes that his personal arbitrary choice is not the one that the language actually implements.

Assignability is different in that the assignment operation is unambiguously tied to the type of its left-hand-side.  Assignment forces a value into a particular representation -- that of the pre-allocated "storage" designated by the LHS.  If the value is not compatible with that representation then we can raise a run-time error.


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

(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      +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      +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/085ab3d2/attachment-0002.html>

From hendrik at topoi.pooq.com  Sun Jan 10 23:11:37 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 10 Jan 2010 17:11:37 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>
Message-ID: <20100110221137.GB16635@topoi.pooq.com>

On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> 
> And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

Just for clarity, do you mean the Itanium here?

-- hendrik


From jay.krell at cornell.edu  Sun Jan 10 23:22:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Jan 2010 22:22:00 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100110221137.GB16635@topoi.pooq.com>
References: <95DC398D-37D2-4B11-98F7-ED87D1CC9895@cs.purdue.edu>,
	<COL101-W55AEA29A547A9B7B4E3392E66E0@phx.gbl>,
	<20100110221137.GB16635@topoi.pooq.com>
Message-ID: <COL101-W30198A34B16863265449FCE66E0@phx.gbl>


Yes of course.

  echo %PROCESSOR_ARCHITECTURE%  

 

 - Jay


 
> Date: Sun, 10 Jan 2010 17:11:37 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> On Sun, Jan 10, 2010 at 09:00:15PM +0000, Jay K wrote:
> > 
> > And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?
> 
> Just for clarity, do you mean the Itanium here?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/0fab823d/attachment-0002.html>

From jayk123 at hotmail.com  Mon Jan 11 05:58:13 2010
From: jayk123 at hotmail.com (jayk123 at hotmail.com)
Date: Sun, 10 Jan 2010 20:58:13 -0800
Subject: [M3devel] what to do about file sizes being 32bits?
In-Reply-To: <COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
References: <COL101-W40DD982FB57B0809E31105E6710@phx.gbl>, , , ,
	<COL101-W115A210D309977FBB457E9E6710@phx.gbl>, , ,
	<COL101-W97E66360FD1B6AC5E03FBE66E0@phx.gbl>, , ,
	<C164BECE-2584-4AEF-8D7E-2670A8BA941F@cs.purdue.edu>, ,
	<COL101-W41D1A833237EA1AD561CCE66E0@phx.gbl>,
	<COL101-W4146C3008C27DC54397B9FE66E0@phx.gbl>,
	<FFF0F178-1513-434E-BB9C-9BA0FA29067B@cs.purdue.edu>
	<COL101-W18D0E5293674A6BB6329F8E66E0@phx.gbl>
Message-ID: <BLU0-SMTP21D313FA40787E6A124A47E66D0@phx.gbl>

To repeat myself: you can reason about + via assignability, sort of.  
Of the two input types, you see which is assignable to which, and  
conceptually assign the inputs to two temporaries of that type.  
Assuming longint *not* assignable to integer, done. If it is  
assignable, pick the type that can guaranteeably hold all values of  
the two inputs.

In terms of implict vs. explict..I fallback to my usual claim: what  
people already probably think of as simple very often is not. The "red  
flag" of "complexity", I find, is raised very quickly, when people  
just don't like something.

I think there might be another way though. What if rd/wr users had to  
change *lots* of types from integer and cardinal to longint..and index  
by longint allowed? Maybe maybe that'd have a "pleasant" outcome. But  
still, given that NUMBER returns CARDINAL, still must end up mixing  
somehow, either via implicit or explicit conversion/assignment.


Btw are C's rules really so different or complicated? Don't they look  
like "assignability" too? The one problem I know of is in comparison  
if "full range" unsigned types with signed types. There are two  
equally good/bad options: I think called "sign preserving" and  
"magnitude preserving" aka "magnitude losing" and "sign losing".  
Either a large positive number becomes negative or a negative number  
becomes a large positive. I believe avoidance of this problem is why  
CARDINAL is "half range".


  - Jay (phone)

On Jan 10, 2010, at 2:02 PM, Jay K <jay.krell at cornell.edu> wrote:

> Is it really just me who finds the choices all fairly obvious?
> You do the math in the wider type. Is that really surprising?
>   Am I just, like, brain washed with years of assumptions?
> That's what Rodney's proposal said.
> In the case of MOD and DIV, you can pause for thought
> and maybe make them return a narrower type, but
> if you just want to be simple and stay wide, that's ok.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 16:06:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>
> Consider the following:  + is overloaded to perform both INTEGER and  
> LONGINT addition.  When invoking + we choose the appropriate  
> operation based on its operand types.  Why do you think it is  
> reasonable to assume that LONGINT+INTEGER should perform LONGINT +  
> instead of INTEGER +?  It is an *arbitrary* choice that you make  
> which should give us pause in imposing that arbitrary choice in the  
> language because it violates the principle of least surprise.  Don't  
> impose arbitrary choices that may confuse the programmer.
> Prohibiting mixed-operand operations prevents bugs arising when one  
> programmer inadvertently assumes that his personal arbitrary choice  
> is not the one that the language actually implements.
>
> Assignability is different in that the assignment operation is  
> unambiguously tied to the type of its left-hand-side.  Assignment  
> forces a value into a particular representation -- that of the pre- 
> allocated "storage" designated by the LHS.  If the value is not  
> compatible with that representation then we can raise a run-time  
> error.
>
> On 10 Jan 2010, at 15:53, Jay K wrote:
>
> (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 
>       +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 
>       +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/b9b6e1d0/attachment-0002.html>

From rcolebur at SCIRES.COM  Mon Jan 11 07:11:52 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 01:11:52 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:


I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn

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

From wagner at elegosoft.com  Mon Jan 11 10:51:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 10:51:34 +0100
Subject: [M3devel] Truncation problem fixed,
	was: Re:  another longint	variant
In-Reply-To: <COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
References: <COL101-W28EDF86B00B302D3174763E66F0@phx.gbl>, ,
	<69E00635-6D2B-4079-82DE-8FE041ED5095@cs.purdue.edu>,
	<COL101-W41D6709DC19ED25479CA44E66F0@phx.gbl>,
	<C575DED2-F7FC-4A8F-AB5C-AD24DB16666D@cs.purdue.edu>
	<COL101-W50FB9B4E7302FDFC39148CE66F0@phx.gbl>
Message-ID: <20100111105134.4zr9fs0lc00wsok8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> [replacing periods with semicolons to avoid truncation..]

Mike has made a change some days ago that should fix the truncation
of mails at certain periods. If anybody experiences this again,
you should let him know.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Mon Jan 11 11:52:57 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 11 Jan 2010 11:52:57 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
Message-ID: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> This guy is trying to subscribe to m3devel.  Can someone help him?
>
> Begin forwarded message:
>
>> From: Chris <dimonax at att.net>
>> Date: 10 January 2010 16:43:32 EST
>> To: Tony Hosking <hosking at cs.purdue.edu>
>> Subject: Re: CM3 development Inquiry.
>>
>> On Fri, 8 Jan 2010 13:01:21 -0500
>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>
>>> Did you manage to subscribe?
>>
>> I put in another subscription request just after your previous   
>> reply, and I'm still waiting. I wonder if the confirmation e-mail   
>> is getting through. Nonetheless, I'll keep trying.

Unfortunately the address does not work:

This is the mail system at host mx0.elegosoft.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
     521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
     Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
     command)

If he really wants to join, he needs another mail address, but I cannot
tell him that.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Jan 11 13:17:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:17:56 +0000
Subject: [M3devel] some more "crazy" proposals
Message-ID: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>


1) change file/rd/wr sizes to be BigInteger.T

and/or

2) Introduce SeekL, IndexL, StatusL, etc.
default implementation calls Seek/Index/Status and does checked truncation.
Clients gradually port to LONGINT or BigInteger.T.
Completely source compatible.


3) BigInteger.T is The multiple-INTEGER precision type??
No compiler/language change??


I might try these out, and then go the extra step and port the file dialog to avoid the exception..
see what it all looks like...

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/3b5d2620/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jan 11 13:14:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Jan 2010 12:14:06 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>


Randy I won't cover everything but on some of these matters you are not alone.
In particular, INTEGER and LONGINT are different types, in the current
implementation, and I think in all proposals.


It is quite striking how the current implemtation makes them completely different.
However many proposals do allow assignability which does make it a bit
blurry to a user what different types mean.
One thing that I bet will always remain though, is that VAR parameters of INTEGER
cannot "bind" to LONGINT, and vice versa.
The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
without a cast, even if int and long are both 32bit.
That is, in C and C++, int and long are different types, just as in Modula-3,
INTEGER and LONGINT are different types.


Which goes to show one of my agendas: C isn't as bad as people think.
It isn't safe, granted. There is no formal module system, but
people are actually usually rigorous in their use of the informal system.
As well, one of the goals I have espoused is that UNSAFE Modula-3 be
not more unsafe than C. Which is why I don't like procedures to return ADDRESS
and expect every caller to cast/loophole -- that is just more unsafe than things should be.


I have some familiarity with 8 and 16 bit integers.
We can perhaps claim that there is a hypothetical system
with 16bit INTEGER and 32bit LONGINT?
And that our proposals do work in such a system?


There is some disagreement floating around apparently on even what
to call the INTEGER <=> LONGINT conversions.
Currently ORD converts to INTEGER.
Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.


I believe I saw a proposal that the converesions be named after the type:
  INTEGER(expr), LONGINT(expr).

That kind of smacks to me of "too hard to search for".

Here is a crazy verbose suggestion:
 LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

and allow it in safe modules?
At least it is existing syntax with roughly the desired meaning,
except that LOOPHOLE is and sounds unsafe.

CAST(expr, type)
CONVERT(expr, type)
?

I'm just making up words here of course.
VAL or ORD seem sufficient, esp. if you can specify the type.

gotta go,
 - Jay


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 01:11:52 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal
















Tony:

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope (see below).  Using differently named conversion operators would
lesson some of the ugliness of ORD/VAL and also prevent confusion with their
intended use as enumeration/INTEGER conversions.

 

Read on for the long-winded version?

 

According to NELSON (SPwM3), ORD and VAL convert between enumerations
and INTEGERs, and INTEGER is all integers represented by the implementation. 
So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit
processors.  

 

Today we see 32-bit and 64-bit processors as predominant, but I
remember the day when 8-bit and 16-bit were the norm.  Someday we may see
128-bit processors as the norm.  

 

(I?ve been cleaning up my basement office and ran across a
box of 8-inch floppy disks.  When I showed them to my daughter she
understood the meaning of ?floppy? as opposed to the rigid 3.5-inch
floppies of today.  But, I digress.)

 

On a 64-bit processor, this whole idea of LONGINT as 64-bits then
becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine
(assuming we had an implementation for one) the native word size would be less
than the 32-bits we seem to take for granted now.

 

One problem is that one doesn?t really know the range of
LONGINT unless we define it as some number of bits.  Rodney?s
proposal simply stated that LONGINT was at least as big as INTEGER but could be
larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same
in terms of implementation?, whereas on a 32-bit the LONGINT would have an
additional 32-bits more than INTEGER?  What about a 128-bit machine?

 

I say all this to point out the obvious, namely that LONGINT and
INTEGER are different types.  

 

Therefore, IMO the language must make it clear how these
different types interact.

 

I would argue that 

   x: LONGINT := 23;

is wrong!  The programmer should have to write

   x: LONGINT := 23L;

instead.

 

A subrange of LONGINT would be written as [23L..4200L] and would
be a different type than the integer subrange [23..4200] even though the ranges
are identical.

 

Likewise, IMO mixed arithmetic with the compiler deciding what
to do is wrong.  The programmer should have to explicitly write
conversions to a common type for arithmetic.

 

I have no problem with extending the existing operators to deal
with LONGINT; it?s just that the result should be LONGINT.

Given x: LONGINT := 49L;

   INC(x) yields 50L

   INC(x, 3L) yields 52L

      note that INC(x, 3) would be a
syntax error since 3 is an INTEGER and x is a LONGINT

   (x + 20L) yields 69L

      note that (x + 20) would be a
syntax error since 20 is an INTEGER and x is a LONGINT

   LAST(LONGINT) yields a LONGINT

 

Now that I think about it more, I have a problem using ORD/VAL
for the conversion since NELSON defines these as converting between enumerations
and INTEGERs, and since LONGINT is a different type than INTEGER and quite
possibly has a greater range than INTEGER.  Is the proposal to also allow
enumerations to use the range of LONGINT ?  Enumerations currently are
defined as having a range no greater than INTEGER.  To extend them to
LONGINT would lose the obvious performance benefits of keeping them same range
as native INTEGER.

 

Maybe we should invent new names for the conversions between
INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These
are probably bad names, but I use them below simply to illustrate (feel free to
come up with better names):

   Given longInt: LONGINT;   and  
int: INTEGER;

   int := DEMOTE(longInt); would perform the
conversion from LONGINT to INTEGER and would give a runtime range check error if
longInt is too big/small to fit in an INTEGER.

   longInt := PROMOTE(int) would always succeed in
performing the conversion from INTEGER to LONGINT but would make the conversion
explicit

   int + DEMOTE(longInt) would yield an INTEGER result
with all arithmetic being done in the range of INTEGER

   longInt + PROMOTE(int) would yield a LONGINT result
with all arithmetic being done in the range of LONGINT

 

Now if we were to allow checked assignability (as Tony is
leaning toward), I think we begin to get on the slippery slope.  How far
do we extend this to the point that it is not clear in the expression of the
code what is happening?  If I can write ?int := longInt;? why
not ?int := 23L;? and why not ?int := longInt + 57;?
and is this different than ?int := longInt + 57L;?? etc. etc.

 

I agree the ORD/VAL syntax is ugly, so that is another reason
(besides them applying to enumerations only) we should use different names for
the INTEGER/LONGINT conversions.

 

Sorry, I have been too long-winded here.  To answer your
questions succinctly:  

 

1.  I can relax on the requirement for overflow
checking, but programmers should never count on it silently wrapping around.

 

2.  I think checked assignability gets us onto the slippery
slope.  Using differently named conversion operators would lesson some of
the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER
conversions.

 

Regards,

Randy Coleburn

 





From: Tony Hosking [mailto:hosking at cs.purdue.edu]


Sent: Sunday, January 10, 2010 3:43 PM

To: Randy Coleburn

Cc: m3devel

Subject: Re: [M3devel] the LONGINT proposal





 



Hi Randy,





 





As someone who has actually written
Modula-3 programs for a living your opinions are always highly valued.  I
agree with you in principle and aims, except for requiring overflow to be a
checked run-time error.  The language definition already has a mechanism
for handling this in the require FloatMode interface.  It is not something
that the compiler should be involved in.  I also just now raised
a question about perhaps having integer literals adapt their type to the
context in which they are used.





 





I should point out that the current
mainline implementation does exactly what you propose (except overflow
checking).  It captures the fundamental spirit of Rodney's proposal but
does not permit mixed arithmetic or assignment.  Can I ask what your issue
is w.r.to checked assignability?  I am still leaning in favor.  It is
not much different from assignment from an INTEGER to a subrange, which
requires no explicit check, though of course there is a run-time range check.  Having
programmers explicitly write:





 





x: INTEGER := ORD(longint,
INTEGER);





 





seems unnecessary when they could
just write





 





x: INTEGER := longint;





 









This
is similar in spirit to:









 





x: [lo..hi] := integer;





 





 







On 10 Jan 2010, at 15:00, Randy
Coleburn wrote:











I've been trying to follow along on
this topic.



Here are my thoughts:



1.  LONGINT should be a distinct type different from INTEGER.



2.  There should be no mixed arithmetic between the types.  The
programmer must code conversions using ORD/VAL to make explicit the intention.
 Don't rely on some ill-remembered built-in conversion rule.



3.  Overflow should be a checked run-time error, not silently wrapped
around.



4.  WRT assignability, I think explicit conversions should be used.



These statements may make me unpopular with some who don't like to type much,
but I've always hated the tradeoff of understandability for brevity in
expression.



The important thing is not how fast we can type up a program, it is rather how
hard is it to make a mistake.  I think the spirit of Modula-3 is that the
language makes you a better programmer by forcing you to make your intentions
explicit rather than relying on the compiler to infer your intentions.  We
need correct and maintainable software, especially at the systems level.
 Whatever is decided about LONGINT, we need to keep to the original design
tenants of the language.  



And yes, I do think we need a LONGINT type, not just to deal with large file
sizes.



But even for long-lived readers/writers, whatever type you choose for the index
will eventually be insufficient, so you have to code for the possibility that
the range of the long lived reader/writer exceeds the range of your index type.
 That is just good programming.



I think sometimes that the new generation of programmers has been warped by
what I call the "Microsoft Mentality" where you must expect that you
need to reboot/restart every so often to maintain proper performance.
 Programs should be written to run forever or until their job is completed
or they are commanded to stop.  



As "we" begin to converge on the design changes, I like having
something concrete to look at, ala Rodney's proposal.  Can we take that
and keep tweaking it in these emails until we reach a final version acceptable
to all?  To me this keeps the discussion focused rather than the many
different emails.  Thus, what I am trying to say is put forth a numbered
proposal and each subsequent email must show adjustment to that proposal rather
than just a bunch of emails discussing various aspects.  Perhaps we should
vote on each proposed change, then decide to call a final vote on the whole
thing.  Who should be involved in such votes?  Right now the main
persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.



My two cents.



Regards,

Randy Coleburn





 

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

From hendrik at topoi.pooq.com  Mon Jan 11 17:23:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Mon, 11 Jan 2010 11:23:01 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <20100111162301.GA23072@topoi.pooq.com>

On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.
> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
> 
> 
> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).
> 
> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
> 
> and allow it in safe modules?
> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.
> 
> CAST(expr, type)
> CONVERT(expr, type)
> ?
> 
> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

NARROW?  WIDEN?

And TRUNCATE if you really want to chop off the high-order bits without 
overflow check?

-- hendrik


From hosking at cs.purdue.edu  Mon Jan 11 18:12:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:12:25 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
Message-ID: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>

Actually, that diagnostic indicates that scc-mailrelay.att.net is blocking messages from the Elegosoft mail server (it is blacklisted!).

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 11 Jan 2010, at 05:52, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> This guy is trying to subscribe to m3devel.  Can someone help him?
>> 
>> Begin forwarded message:
>> 
>>> From: Chris <dimonax at att.net>
>>> Date: 10 January 2010 16:43:32 EST
>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>> Subject: Re: CM3 development Inquiry.
>>> 
>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>> 
>>>> Did you manage to subscribe?
>>> 
>>> I put in another subscription request just after your previous  reply, and I'm still waiting. I wonder if the confirmation e-mail  is getting through. Nonetheless, I'll keep trying.
> 
> Unfortunately the address does not work:
> 
> This is the mail system at host mx0.elegosoft.com.
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> For further assistance, please send mail to postmaster.
> 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> 
>                   The mail system
> 
> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>    command)
> 
> If he really wants to join, he needs another mail address, but I cannot
> tell him that.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Mon Jan 11 18:32:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:32:13 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:

> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.

>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.

>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 

Correct.  The current implementation treats them as completely separate.

>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.

This is what we currently implement.

>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.

>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.

>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.

>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.

>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...

>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

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

From hosking at cs.purdue.edu  Mon Jan 11 18:42:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:00 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
Message-ID: <90520DA3-BD5C-494F-875B-F77910088E0B@cs.purdue.edu>

On 11 Jan 2010, at 07:14, Jay K wrote:

> Randy I won't cover everything but on some of these matters you are not alone.
> In particular, INTEGER and LONGINT are different types, in the current
> implementation, and I think in all proposals.
> 
> 
> It is quite striking how the current implemtation makes them completely different.
> However many proposals do allow assignability which does make it a bit
> blurry to a user what different types mean.
> One thing that I bet will always remain though, is that VAR parameters of INTEGER
> cannot "bind" to LONGINT, and vice versa.
> The equivalent is true in C and C++: pointers to int and long cannot be interchanged,
> without a cast, even if int and long are both 32bit.
> That is, in C and C++, int and long are different types, just as in Modula-3,
> INTEGER and LONGINT are different types.

But C has a much looser design philosophy than Modula-3.  We should not compromise Modula-3 by veering towards C.

> Which goes to show one of my agendas: C isn't as bad as people think.
> It isn't safe, granted. There is no formal module system, but
> people are actually usually rigorous in their use of the informal system.
> As well, one of the goals I have espoused is that UNSAFE Modula-3 be
> not more unsafe than C. Which is why I don't like procedures to return ADDRESS
> and expect every caller to cast/loophole -- that is just more unsafe than things should be.
> 
> 
> I have some familiarity with 8 and 16 bit integers.
> We can perhaps claim that there is a hypothetical system
> with 16bit INTEGER and 32bit LONGINT?
> And that our proposals do work in such a system?
> 
> 
> There is some disagreement floating around apparently on even what
> to call the INTEGER <=> LONGINT conversions.
> Currently ORD converts to INTEGER.

I suppose ORD could convert to the underlying type, but given the intention that it be used to convert from an enumeration to an integer, then I think hardwiring it to return INTEGER is OK, since no enumeration will/should contain more elements than can be indexed by an INTEGER.  On the other hand, I see no real problem if ORD(longint) returns LONGINT.  It just means you have to do one more step to get an integer using VAL.

> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.

Yes, this is what we also currently implement.

> I believe I saw a proposal that the converesions be named after the type:
>   INTEGER(expr), LONGINT(expr).

I proposed that originally, but then decided that reusing VAL seemed much more intuitive.  After all, we are asking to treat a typed expression in one domain as a *value* in some other type domain, so long as the value has a representative in that domain.

> That kind of smacks to me of "too hard to search for".
> 
> Here is a crazy verbose suggestion:
>  LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)

LOOPHOLE implies an unsafe operation!

> and allow it in safe modules?

Yuck!!!!!!!!!!!!!!!!

> At least it is existing syntax with roughly the desired meaning,
> except that LOOPHOLE is and sounds unsafe.

I vote we stick with VAL.

> CAST(expr, type)
> CONVERT(expr, type)
> ?

Yuck!


> I'm just making up words here of course.
> VAL or ORD seem sufficient, esp. if you can specify the type.

Agreed!

> 
> gotta go,
>  - Jay
> 
> 
> From: rcolebur at SCIRES.COM
> To: hosking at cs.purdue.edu
> Date: Mon, 11 Jan 2010 01:11:52 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] the LONGINT proposal
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  

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

From hosking at cs.purdue.edu  Mon Jan 11 18:42:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 12:42:34 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <20100111162301.GA23072@topoi.pooq.com>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W65255219A7DD9FD439E6D0E66D0@phx.gbl>
	<20100111162301.GA23072@topoi.pooq.com>
Message-ID: <06DE4262-4D34-4908-9367-C277E1556416@cs.purdue.edu>

We have Word.T and Long.T to handle masking the higher-order bits.

On 11 Jan 2010, at 11:23, hendrik at topoi.pooq.com wrote:

> On Mon, Jan 11, 2010 at 12:14:06PM +0000, Jay K wrote:
>> 
>> There is some disagreement floating around apparently on even what
>> to call the INTEGER <=> LONGINT conversions.
>> Currently ORD converts to INTEGER.
>> Randy's proposal I believe converts to the underlying type: INTEGER or LONGINT.
>> And I think uses VAL(expr, INTEGER or LONGINT) to convert to INTEGER or LONGINT.
>> 
>> 
>> I believe I saw a proposal that the converesions be named after the type:
>>  INTEGER(expr), LONGINT(expr).
>> 
>> That kind of smacks to me of "too hard to search for".
>> 
>> Here is a crazy verbose suggestion:
>> LOOPHOLE(integer or subrange or enumeration or longint, INTEGER or LONGINT)
>> 
>> and allow it in safe modules?
>> At least it is existing syntax with roughly the desired meaning,
>> except that LOOPHOLE is and sounds unsafe.
>> 
>> CAST(expr, type)
>> CONVERT(expr, type)
>> ?
>> 
>> I'm just making up words here of course.
>> VAL or ORD seem sufficient, esp. if you can specify the type.
> 
> NARROW?  WIDEN?
> 
> And TRUNCATE if you really want to chop off the high-order bits without 
> overflow check?
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Mon Jan 11 19:39:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 13:39:21 -0500
Subject: [M3devel] some more "crazy" proposals
In-Reply-To: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
References: <COL101-W35F9780CF058CB73411AF3E66D0@phx.gbl>
Message-ID: <69F1DBED-115F-44A5-93D6-7C2375EC3E8E@cs.purdue.edu>

Jay, as you'll note from the commit messages, I've made ORD/VAL consistent with Rodney's proposal.
I think this is much more consistent, in treating VAL as the only *conversion* operator for ordinals.
ORD is really just there to allow conversion of enumerations to INTEGER, but for consistency it makes sense to have ORD return the underlying value without any conversion.  This makes the equality:

ORD(n) = VAL(ORD(n), T) = n

where T is the type of n.

Unfortunately, it also means that your uses of ORD in the Rd/Wr code must now turn into VAL(n, INTEGER).

On 11 Jan 2010, at 07:17, Jay K wrote:

> 1) change file/rd/wr sizes to be BigInteger.T
> 
> and/or
> 
> 2) Introduce SeekL, IndexL, StatusL, etc.
> default implementation calls Seek/Index/Status and does checked truncation.
> Clients gradually port to LONGINT or BigInteger.T.
> Completely source compatible.
> 
> 
> 3) BigInteger.T is The multiple-INTEGER precision type??
> No compiler/language change??
> 
> 
> I might try these out, and then go the extra step and port the file dialog to avoid the exception..
> see what it all looks like...
> 
>  - Jay



From rodney_bates at lcwb.coop  Tue Jan 12 01:18:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:18:46 -0600
Subject: [M3devel] Mixed arithmetic
Message-ID: <4B4BBFE6.1090701@lcwb.coop>

Well, I have been mistaken.  I finally found the statement about argument
types of builtin operators.  Every time I go looking for this, I have trouble
finding it.  I had remembered it wrongly.  It does not say an actual argument must
be assignable to the type in the signature, it says it must be a _subtype_
of the type in the signature.  Actually, it says the overloading is resolved
using the subtype relation, but this has the same effect on what is and
isn't statically legal.

(2.6.1):  The particular operation will be selected so that each actual
           argument type is a subtype of the corresponding formal type or
           a member of the formal type class.

So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
rules.  We would have to insert 4 different overloaded signatures for
+, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
language changes for LONGINT a lot simpler.

This weakens my support of mixed arithmetic.

However, there is still some messiness to be resolved.  The relations do use
assignability rather than subtyping, in such a way that mixed comparisons
do fall out of the existing rules.  (The overload resolution is done on
type class, not type, and doesn't, by itself, preclude mixed INTEGER/
LONGINT comparisons.)  Then there are a lot of other places
that use assignability.  They are:

- assignment statements
- passing parameters to VALUE or READONLY formals
- passing VAR open array parameters (a different kind of assignability, not
      really relevant)
- RAISE statements
- RETURN statements
- Initial value assignment in a VAR declaration
- array subscripts in designators a[i]
- elements of set, array, and record constructors
- relational operators, including IN
- ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)

I too am generally a fan of syntactic explicitness, rather than having things
happen behind the scenes, without the programmer's coding them.  But if we
disallow mixed arithmetic operations, it seems to me that it becomes
quite arbitrary where we are allowing assignability and where we are
requiring explicit type conversions.

Without LONGINT in the picture, this arbitrariness didn't happen, because
there was no case where assignability vs. subtyping for the arguments of
the arithmetic operators made any difference.

I do think it would be particularly inconsistent to disallow the mixed
arithmetic but allow mixed relations.  As Tony has pointed out, these
two differ from the other uses of assignability in having two expressions
whose types must be used to infer a common value range to do the operation
in.  All the other uses of assignability have only one "target" type to
assign to.


From rodney_bates at lcwb.coop  Tue Jan 12 01:25:37 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:25:37 -0600
Subject: [M3devel] Integer overflow
In-Reply-To: <3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
Message-ID: <4B4BC181.8020807@lcwb.coop>

If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
I think wrapping around to the maximal negative value would be reasonable.  Even for
CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
done in the full INTEGER range).  But then the assignment of the result back to the
CARDINAL variable really must do a range check.  This derives from the assignment
x:= ... in the WITH equivalent, not from the + 1 operation.

Mainly, there is a pervasive principle in the safety of the language that you can
never get a bit pattern stored in a variable that does not map back to an abstract
value of its type.  We really need to preserve this.

Tony Hosking wrote:
> Even under the interpretation for INC that yields:
> 
> VAR s: CARDINAL := LAST(INTEGER);
> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
> 
> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
> 
> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
> 
> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
> 
>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN INC(s) END;
>>
>> Should this fail at runtime with a range check error?
>>
>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>
>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
> 
> 


From rodney_bates at lcwb.coop  Tue Jan 12 01:45:27 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 11 Jan 2010 18:45:27 -0600
Subject: [M3devel] Integer literals
In-Reply-To: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
Message-ID: <4B4BC627.6030103@lcwb.coop>



Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is 
> the need for distinct literal forms.  This strikes me as odd, since 
> literals are really just ways of writing values, rather than stating 
> anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, 
> but they really do have incompatible value representations).

I agree, the need for distinctly typed literals is much greater for the
floating types than the integer types, because they can't be viewed
as having overlapping value sets in any reasonable way.

> 
> It strikes me that with checked assignability for INTEGER/LONGINT we 
> could also potentially treat integer literals as essentially "untyped" 
> (neither INTEGER nor LONGINT). (I still strongly resist going the route 
> of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants 
> lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be 
> unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base 
> type of the subrange should be.

This would eliminate _one_ reason for needing distinct integer literals.

> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

The reason I proposed the distinct literals is because of feeling very
badly burned by Ada.  It has a type "universal integer", which is builtin,
and all integer literals have this type.  They have unbounded range and
a complete set of arithmetic operators, which can only be evaluated at
compile time.  The type "universal integer" can't be named in source
code.

The rules for when they are converted to a type having a runtime representation
are complicated, messy, highly surprising, and a huge complication of the
language.  Static type information can propagate a long way through
language constructs.  The programmer's dilemma in figuring out just what
is happening is much worse than arithmetic operators that accept mixed
sizes and do the computation in the larger size.

Maybe the semantics of this idea could be done better than in Ada, but I spent
a lot of time trying, and didn't come up with anything that wasn't both too
complicated and not worth the gain, IMO.

We should come up with a complete language proposal before going this way.


> 

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 


From hosking at cs.purdue.edu  Tue Jan 12 02:02:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 20:02:01 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <DB1A2DAE-CCAD-44EF-9687-DAD88C216DF3@cs.purdue.edu>

My firm position now is that we continue to disallow both mixed arithmetic *and* assignability, and stick with the status quo as described at:

http://www.cs.purdue.edu/~hosking/m3/reference/index.html
http://www.cs.purdue.edu/homes/hosking/m3/reference/complete/m3-defn-complete.pdf

On 11 Jan 2010, at 19:18, Rodney M. Bates wrote:

> Well, I have been mistaken.  I finally found the statement about argument
> types of builtin operators.  Every time I go looking for this, I have trouble
> finding it.  I had remembered it wrongly.  It does not say an actual argument must
> be assignable to the type in the signature, it says it must be a _subtype_
> of the type in the signature.  Actually, it says the overloading is resolved
> using the subtype relation, but this has the same effect on what is and
> isn't statically legal.
> 
> (2.6.1):  The particular operation will be selected so that each actual
>          argument type is a subtype of the corresponding formal type or
>          a member of the formal type class.
> 
> So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
> rules.  We would have to insert 4 different overloaded signatures for
> +, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
> language changes for LONGINT a lot simpler.
> 
> This weakens my support of mixed arithmetic.
> 
> However, there is still some messiness to be resolved.  The relations do use
> assignability rather than subtyping, in such a way that mixed comparisons
> do fall out of the existing rules.  (The overload resolution is done on
> type class, not type, and doesn't, by itself, preclude mixed INTEGER/
> LONGINT comparisons.)  Then there are a lot of other places
> that use assignability.  They are:
> 
> - assignment statements
> - passing parameters to VALUE or READONLY formals
> - passing VAR open array parameters (a different kind of assignability, not
>     really relevant)
> - RAISE statements
> - RETURN statements
> - Initial value assignment in a VAR declaration
> - array subscripts in designators a[i]
> - elements of set, array, and record constructors
> - relational operators, including IN
> - ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)
> 
> I too am generally a fan of syntactic explicitness, rather than having things
> happen behind the scenes, without the programmer's coding them.  But if we
> disallow mixed arithmetic operations, it seems to me that it becomes
> quite arbitrary where we are allowing assignability and where we are
> requiring explicit type conversions.
> 
> Without LONGINT in the picture, this arbitrariness didn't happen, because
> there was no case where assignability vs. subtyping for the arguments of
> the arithmetic operators made any difference.
> 
> I do think it would be particularly inconsistent to disallow the mixed
> arithmetic but allow mixed relations.  As Tony has pointed out, these
> two differ from the other uses of assignability in having two expressions
> whose types must be used to infer a common value range to do the operation
> in.  All the other uses of assignability have only one "target" type to
> assign to.

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

From jay.krell at cornell.edu  Tue Jan 12 02:18:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:18:26 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>


>> One thing I've really struggled with over the introduction of LONGINT is
>> the need for distinct literal forms. This strikes me as odd, since
>> literals are really just ways of writing values, rather than stating
>> anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct,
>> but they really do have incompatible value representations).
>
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.

 
Huh? This seems to me to be directly opposite of the truth.
LONGREAL is a strict superset of REAL in what it can represent.
There is *complete* overlap.
Am I really mistaken here?
Floating point is indeed very wierd, but it isn't this wierd.
Right?
 
 
 - Jay




---------------------------------------- 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 02:21:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 01:21:34 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <4B4BBFE6.1090701@lcwb.coop>
References: <4B4BBFE6.1090701@lcwb.coop>
Message-ID: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>


> rather than having things
> happen behind the scenes, without the programmer's coding them
 
 
Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.
  It is two or three function calls.
Look at the garbage collector. 
Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
 I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.
 
 
Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
 
 
It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.
 
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 03:11:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:11:23 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <4B4BC627.6030103@lcwb.coop>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>
	<4B4BC627.6030103@lcwb.coop>
Message-ID: <4405421D-C606-4DC4-B6D4-4C50DA03992B@cs.purdue.edu>

Yes, I agree.  I am now convinced that relaxing the current spec to allow assignability and mixed operand arithmetic is a swamp that we should steer well clear of.

On 11 Jan 2010, at 19:45, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
>> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> I agree, the need for distinctly typed literals is much greater for the
> floating types than the integer types, because they can't be viewed
> as having overlapping value sets in any reasonable way.
> 
>> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
>> Here's how things would work with subrange types.
>> A subrange written as currently
>> [lo .. hi]
>> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
>> A subrange with base type LONGINT would be written explicitly:
>> [lo .. hi] OF LONGINT
>> The constants lo/hi must both be in range for LONGINT.
>> We could also support the form:
>> [lo .. hi] OF INTEGER
>> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
>> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> This would eliminate _one_ reason for needing distinct integer literals.
> 
>> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> The reason I proposed the distinct literals is because of feeling very
> badly burned by Ada.  It has a type "universal integer", which is builtin,
> and all integer literals have this type.  They have unbounded range and
> a complete set of arithmetic operators, which can only be evaluated at
> compile time.  The type "universal integer" can't be named in source
> code.
> 
> The rules for when they are converted to a type having a runtime representation
> are complicated, messy, highly surprising, and a huge complication of the
> language.  Static type information can propagate a long way through
> language constructs.  The programmer's dilemma in figuring out just what
> is happening is much worse than arithmetic operators that accept mixed
> sizes and do the computation in the larger size.
> 
> Maybe the semantics of this idea could be done better than in Ada, but I spent
> a lot of time trying, and didn't come up with anything that wasn't both too
> complicated and not worth the gain, IMO.
> 
> We should come up with a complete language proposal before going this way.
> 
> 
> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484

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

From hosking at cs.purdue.edu  Tue Jan 12 03:09:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:09:39 -0500
Subject: [M3devel] Integer overflow
In-Reply-To: <4B4BC181.8020807@lcwb.coop>
References: <2A81ABBC-A070-4857-86CF-AA16C7D4AE15@cs.purdue.edu>
	<3F29FE3F-617D-493E-B687-C53B9D30D6C3@cs.purdue.edu>
	<4B4BC181.8020807@lcwb.coop>
Message-ID: <8432422C-A96C-4A0A-A8F9-9EC10963548A@cs.purdue.edu>

If the type were INTEGER instead of CARDINAL then the current implementation *does* allow wrap-around.  I've fixed the range check so that overflow does not permit the bits for FIRST(INTEGER) to be stored in the CARDINAL.

On 11 Jan 2010, at 19:25, Rodney M. Bates wrote:

> If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
> I think wrapping around to the maximal negative value would be reasonable.  Even for
> CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
> done in the full INTEGER range).  But then the assignment of the result back to the
> CARDINAL variable really must do a range check.  This derives from the assignment
> x:= ... in the WITH equivalent, not from the + 1 operation.
> 
> Mainly, there is a pervasive principle in the safety of the language that you can
> never get a bit pattern stored in a variable that does not map back to an abstract
> value of its type.  We really need to preserve this.
> 
> Tony Hosking wrote:
>> Even under the interpretation for INC that yields:
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
>> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
>> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
>> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
>>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>> 
>>> VAR s: CARDINAL := LAST(INTEGER);
>>> BEGIN INC(s) END;
>>> 
>>> Should this fail at runtime with a range check error?
>>> 
>>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>> 
>>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>> 
>>> 
>>> 
>>> 

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

From hosking at cs.purdue.edu  Tue Jan 12 03:18:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 21:18:00 -0500
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>

On 11 Jan 2010, at 20:21, Jay K wrote:

> 
>> rather than having things
>> happen behind the scenes, without the programmer's coding them
> 
> 
> Just a reminder that things happen behind the scenes *all the time*.
> It is the norm, not the exception.
> Look at what "try" does.
>  It is two or three function calls.

Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.

> Look at the garbage collector. 

Again, that is not visible to the programmer.  Same again re programmer reasoning.

> Look at layering in various places.
> The system is not simple.
> This isn't a bad thing necessarily.
> Getting things done often requires complexity.
> I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.

His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.

> Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.
> 
> 
> It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.

What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?

Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.

I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.

I strongly support the status quo.

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

From jay.krell at cornell.edu  Tue Jan 12 04:02:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:02:55 +0000
Subject: [M3devel] 64bit file sizes now?
Message-ID: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expr).

 

 

And this is already in place.

 

 

?

 

 

So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.

Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

 

 

I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.

Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

 

 

 - Jay

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

From hosking at cs.purdue.edu  Tue Jan 12 04:10:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:10:06 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>

On 11 Jan 2010, at 22:02, Jay K wrote:

> So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).

That's what I think makes most sense.

>  And this is already in place.

Yes, it's in place.

> ?
>  
> So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
> Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?

>  I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
> Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

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

From jay.krell at cornell.edu  Tue Jan 12 04:10:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:10:52 +0000
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
References: <4B4BBFE6.1090701@lcwb.coop>,
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>,
	<69ECEB1D-AAE2-4C98-8BEE-7F06824C8485@cs.purdue.edu>
Message-ID: <COL101-W65EDF1A26440E2A141F67FE66C0@phx.gbl>


The limited range of efficient integers will always be a problem.

 

 

After all, in the real world, there is no such thing as LAST(INTEGER), nor the notion that + can fail, but even in Modula-3 we have both of these unfortunate things for efficiency.

 

 

It is a wierd system already.

 

 

Having LAST(INTEGER) + 1 fail or be FIRST(INTEGER) but LAST(INTEGER) + 1L provide a more sensible result I'm skeptical makes it any worse or wierder than it already is.

 

 

On the other hand, rd/wr/file ugliness is also fairly unavoidable, and just would have been there from the start had things been done right.

 

 

It is the unavoidable case that "large" files, even if they do fit in address space, are hard to deal with efficiently. Programmers are very used to efficient random access and often don't design for sequential access. And heck, with the rise of SSDs replacing spinning magnetic disks, it isn't going to matter any longer anyway.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 21:18:00 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Mixed arithmetic




On 11 Jan 2010, at 20:21, Jay K wrote:




rather than having things

happen behind the scenes, without the programmer's coding them


Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.

 It is two or three function calls.



Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.


Look at the garbage collector. 



Again, that is not visible to the programmer.  Same again re programmer reasoning.


Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.



His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.


Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.




It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.


What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?


Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.


I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.


I strongly support the status quo.

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

From rcolebur at SCIRES.COM  Tue Jan 12 04:11:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 22:11:51 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>

Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)
then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).  Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);
but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

So, at this point, to summarize, I think you are advocating:

1.      Distinct types INTEGER and LONGINT.

2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.

3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).

4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.

5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.

6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Now, what to do about converting from LONGINT to INTEGER?

a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

e.      Any other ideas?

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:


Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.



2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.


 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.


 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.


 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.


 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.


 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.


 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.


 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...


 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:



I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn


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

From jay.krell at cornell.edu  Tue Jan 12 04:16:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:16:42 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
Message-ID: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>


Large files (64bit file sizes) are very old.

Windows 95 had them in the released API 14+ years ago (1995), NT a few years before that (1993?), betas earlier. I heard VMS had 64bit file sizes but I haven't confirmed.

 

 > If the use-case is typically INTEGER then perhaps we
 > need to think of alternatives using abstraction?
 

Hm. StatusLong, SeekLong, IndexLong, LengthLong?

Default calls Seek/Index/Length, range checked truncation?

Kind of an annoying duplicity of APIs though.

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 22:10:06 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] 64bit file sizes now?




On 11 Jan 2010, at 22:02, Jay K wrote:


So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).



That's what I think makes most sense.


 And this is already in place.



Yes, it's in place.



?
 
So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.



If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?


 I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

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

From dabenavidesd at yahoo.es  Tue Jan 12 04:27:23 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 12 Jan 2010 03:27:23 +0000 (GMT)
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>
Message-ID: <420956.32527.qm@web23605.mail.ird.yahoo.com>

Hi all:
forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
(LAST(INTEGER) + 1) = FIRST (INTEGER)
This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
Please let me know if I'm wrong about this issue on current discussions. 

--- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] 64bit file sizes now?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 11 de enero, 2010 22:02
> 
> 
> 
> 
>  
> So.. LONGINT as I understand will remain roughly as it was,
> except VAL(expr, INTEGER) is how you convert expr to
> INTEGER, instead of ORD(expr).
> 
>  
> 
>  
> 
> And this is already in place.
> 
>  
> 
>  
> 
> ?
> 
>  
> 
>  
> 
> So I should go ahead and update File.i3/Status/size and
> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> the consequences"? The consequences are roughly the
> first diff I sent out, with the caveats that I used ORD()
> instead of VAL(,INTEGER), and a few packages were left to
> fix. It is mechanical and simple and predictable, just
> tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes"
> anyway, but a few might gain capacity.
> 
> Classic simple example is the mklib and libdump code, they
> read the entire file into memory and then deal with that.
> 
>  
> 
>  
> 
> I can send the diffs ahead of time, but there's really
> no choices left as to what they'll look like, it is
> forced by the limited capability of LONGINT.
> 
> Had they used LONGINT in the first place, of course,
> there'd be no diff at this time, the ugliness would have
> been builtin from the start.
> 
>  
> 
>  
> 
>  - Jay
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Tue Jan 12 04:40:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:40:28 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:

> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.

>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.

>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)

No, enumerations map only onto INTEGER.

> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.

>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.

>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)

> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 

This captures the identities precisely, which is why I reverted to the original formulation.

> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.

>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);

That is what is now implemented.

> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.

>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.

>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.

>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.

> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!

> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

> e.      Any other ideas?

I think we are done...

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  

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

From hosking at cs.purdue.edu  Tue Jan 12 04:50:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:50:05 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <0EB89E7A-0804-4D07-9F80-CB1F5A343471@cs.purdue.edu>

Overflow checking is a whole other ball of wax... ;-)
The language reference provides for controlling the behavior of integer operations regarding overflow and divide by zero through the interface FloatMode.i3.  Unfortunately, the implementation of this interface on many targets is incomplete and the default behaviour is to allow integer operations to silently overflow.
Range checks are still injected by the compiler to ensure that no variable has a bit representation that is not a legal value for that variable.  Thus, for example:

VAR x: INTEGER := LAST(INTEGER)+1

will leave x with the value -1.

But,

VAR x: CARDINAL := LAST(INTEGER)+1

will cause a range fault because the overflowed result is not a legal CARDINAL.

It would be great if someone could devote some time to implementing this interface for x86 or x86_64 as they are the most widely used these days.  Of course, each OS target will probably need a different implementation.

On 11 Jan 2010, at 22:27, Daniel Alejandro Benavides D. wrote:

> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: [M3devel] 64bit file sizes now?
>> Para: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 11 de enero, 2010 22:02
>> 
>> 
>> 
>> 
>> 
>> So.. LONGINT as I understand will remain roughly as it was,
>> except VAL(expr, INTEGER) is how you convert expr to
>> INTEGER, instead of ORD(expr).
>> 
>> 
>> 
>> 
>> 
>> And this is already in place.
>> 
>> 
>> 
>> 
>> 
>> ?
>> 
>> 
>> 
>> 
>> 
>> So I should go ahead and update File.i3/Status/size and
>> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
>> the consequences"? The consequences are roughly the
>> first diff I sent out, with the caveats that I used ORD()
>> instead of VAL(,INTEGER), and a few packages were left to
>> fix. It is mechanical and simple and predictable, just
>> tedious and ugly.
>> Most Rd/Wr users are limited to INTEGER "sizes"
>> anyway, but a few might gain capacity.
>> 
>> Classic simple example is the mklib and libdump code, they
>> read the entire file into memory and then deal with that.
>> 
>> 
>> 
>> 
>> 
>> I can send the diffs ahead of time, but there's really
>> no choices left as to what they'll look like, it is
>> forced by the limited capability of LONGINT.
>> 
>> Had they used LONGINT in the first place, of course,
>> there'd be no diff at this time, the ugliness would have
>> been builtin from the start.
>> 
>> 
>> 
>> 
>> 
>> - Jay
>> 
>> 		 	   		  
>> 
> 
> 
> 



From jay.krell at cornell.edu  Tue Jan 12 04:46:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 03:46:13 +0000
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <420956.32527.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>


True that:

 

> (LAST(INTEGER) + 1) = FIRST (INTEGER)


 

many folks would like to see fail before it gets to the "=".

 

The dilemna remains though because:

 

> (LAST(INTEGER) + 1L) = FIRST (INTEGER)


 

would not fail.


So, you can either look at it as they produce different values, or one succeeds and one fails.

Either way people don't like two different expressions doing two different things.

Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.

 

There something here about "transitivity" or "replacement":

 

j2 := VAL(i1, LONGINT) + j3;

vs.

j2 := i1 + j3;

 

pretty clearly have the same meaning.

The conversion is always trivial and always succeeds.

Does anyone really find it ambiguous?

 

 - Jay

 
> Date: Tue, 12 Jan 2010 03:27:23 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] 64bit file sizes now?
> 
> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: [M3devel] 64bit file sizes now?
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: lunes, 11 de enero, 2010 22:02
> > 
> > 
> > 
> > 
> > 
> > So.. LONGINT as I understand will remain roughly as it was,
> > except VAL(expr, INTEGER) is how you convert expr to
> > INTEGER, instead of ORD(expr).
> > 
> > 
> > 
> > 
> > 
> > And this is already in place.
> > 
> > 
> > 
> > 
> > 
> > ?
> > 
> > 
> > 
> > 
> > 
> > So I should go ahead and update File.i3/Status/size and
> > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > the consequences"? The consequences are roughly the
> > first diff I sent out, with the caveats that I used ORD()
> > instead of VAL(,INTEGER), and a few packages were left to
> > fix. It is mechanical and simple and predictable, just
> > tedious and ugly.
> > Most Rd/Wr users are limited to INTEGER "sizes"
> > anyway, but a few might gain capacity.
> > 
> > Classic simple example is the mklib and libdump code, they
> > read the entire file into memory and then deal with that.
> > 
> > 
> > 
> > 
> > 
> > I can send the diffs ahead of time, but there's really
> > no choices left as to what they'll look like, it is
> > forced by the limited capability of LONGINT.
> > 
> > Had they used LONGINT in the first place, of course,
> > there'd be no diff at this time, the ugliness would have
> > been builtin from the start.
> > 
> > 
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/f3bf331f/attachment-0002.html>

From hosking at cs.purdue.edu  Tue Jan 12 04:57:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 11 Jan 2010 22:57:38 -0500
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>
Message-ID: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>

On 11 Jan 2010, at 22:46, Jay K wrote:

> True that:
>  
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> 
>  
> many folks would like to see fail before it gets to the "=".

WIthout overflow checking the addition will not fail.

>  
> The dilemna remains though because:
>  
> > (LAST(INTEGER) + 1L) = FIRST (INTEGER)

Actually, you mean VAL(LAST(INTEGER), LONGINT) + 1L

> would not fail.
> 
> So, you can either look at it as they produce different values, or one succeeds and one fails.

The point is that the type explicitly tells you whether you might be in trouble with overflow.

> Either way people don't like two different expressions doing two different things.
> Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.
>  
> There something here about "transitivity" or "replacement":
>  
> j2 := VAL(i1, LONGINT) + j3;
> vs.
> j2 := i1 + j3;

It is not referentially transparent.  It requires innate knowledge about promotion rules to understand.  That's what "not referentially transparent" means!

>  
> pretty clearly have the same meaning.
> The conversion is always trivial and always succeeds.
> Does anyone really find it ambiguous?
>  
>  - Jay
> 
>  
> > Date: Tue, 12 Jan 2010 03:27:23 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com; jay.krell at cornell.edu
> > Subject: Re: [M3devel] 64bit file sizes now?
> > 
> > Hi all:
> > forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> > This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> > Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. 
> > Please let me know if I'm wrong about this issue on current discussions. 
> > 
> > --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribi?:
> > 
> > > De: Jay K <jay.krell at cornell.edu>
> > > Asunto: [M3devel] 64bit file sizes now?
> > > Para: "m3devel" <m3devel at elegosoft.com>
> > > Fecha: lunes, 11 de enero, 2010 22:02
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So.. LONGINT as I understand will remain roughly as it was,
> > > except VAL(expr, INTEGER) is how you convert expr to
> > > INTEGER, instead of ORD(expr).
> > > 
> > > 
> > > 
> > > 
> > > 
> > > And this is already in place.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So I should go ahead and update File.i3/Status/size and
> > > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> > > the consequences"? The consequences are roughly the
> > > first diff I sent out, with the caveats that I used ORD()
> > > instead of VAL(,INTEGER), and a few packages were left to
> > > fix. It is mechanical and simple and predictable, just
> > > tedious and ugly.
> > > Most Rd/Wr users are limited to INTEGER "sizes"
> > > anyway, but a few might gain capacity.
> > > 
> > > Classic simple example is the mklib and libdump code, they
> > > read the entire file into memory and then deal with that.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > I can send the diffs ahead of time, but there's really
> > > no choices left as to what they'll look like, it is
> > > forced by the limited capability of LONGINT.
> > > 
> > > Had they used LONGINT in the first place, of course,
> > > there'd be no diff at this time, the ugliness would have
> > > been builtin from the start.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > 
> > 
> > 

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

From rcolebur at SCIRES.COM  Tue Jan 12 05:09:46 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:09:46 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>

Tony:

I'm sorry, I missed the fact that you changed the type to "Integer" vs. "INTEGER" and defined "Integer" to be "INTEGER" or "LONGINT".

I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be "happy" with this state of affairs.

I am confused though by your last set of statements, namely:

>I don't think we need to do this, assuming you understand what I have said above.
>
>ORD(x: INTEGER): LONGINT
>ORD(x: LONGINT): INTEGER
>ORD(x: Enumeration): INTEGER
>ORD(x: Subrange): Base(Subrange)
>
>ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

Didn't you mean:
                ORD(x:INTEGER): INTEGER
                ORD(x:LONGINT): LONGINT

Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
"m3-libs\m3core"
"m3-libs\libm3"
"m3-tools\m3tk"
So some recent changes have caused a problem.

Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 10:40 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

On 11 Jan 2010, at 22:11, Randy Coleburn wrote:


Tony et al:

Yes, I think I am supporting the "status quo", which seems to be Rodney's proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this "discomfort" and the problem I see with converting from LONGINT to INTEGER.)

When I said we don't know the range of LONGINT, I meant that in the context of documenting the language we weren't specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.

Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?

Sorry, my error.  I realised after writing that I had mis-spoken.


 I've only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.

That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):

55,56c55,56
<               ORD  (element: Ordinal): INTEGER
<               VAL  (i: INTEGER; T: OrdinalType): T
---
>               ORD  (element: Ordinal): Integer
>               VAL  (i: Integer; T: OrdinalType): T
74c74
< If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
---
> If n is an integer of type T, ORD(n) = VAL(n, T) = n.

Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.


 Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don't favor this.)

No, enumerations map only onto INTEGER.


Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references "enumerations" (see 4th major paragraph in 2.2.1, "The operators ORD and VAL convert between ...").

I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.


 The syntax of ORD/VAL is:
ORD  (element: Ordinal): Integer
VAL  (i: Integer; T: OrdinalType): T
and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.

BTW:  I think the above identity should say that n is a non-negative integer!

Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.


 So, using these, you propose one would write
                longInt := VAL(int, LONGINT);
                int := ORD(longInt)

No,

longint := VAL(integer, LONGINT)
integer := VAL(longint, INTEGER)
int := ORD(int)
longint := ORD(longint)


then, the identity doesn't exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER).

This captures the identities precisely, which is why I reverted to the original formulation.


Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?

IMO, ORD/VAL make more sense in the case of enumerations.  For example:
                Color = (Red, Blue, Green);
                ORD(Color.Blue) = 1
                VAL(1, Color) = Color.Blue
(Note that the identity doesn't apply here since n isn't an integer when applied to ORD, or to the result of VAL.)

Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.


 I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
                longInt := VAL(int, LONGINT);
                int := VAL(longInt, INTEGER);

That is what is now implemented.


but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.

No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.


 I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase "integers" (should really be "non-negative integers") so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON's book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.

ORD now can never cause a checked runtime error, just as with Nelson.


 So, at this point, to summarize, I think you are advocating:
1.      Distinct types INTEGER and LONGINT.
2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
6.      Allow VAL to convert INTEGER to LONGINT.

Am I correct so far?

Yes, correct.  This is what is now implemented in the CVS head.


 Now, what to do about converting from LONGINT to INTEGER?
a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn't fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn't preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.

See above.


b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.

See above.

c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.

No assignability!


d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.

I don't think we need to do this, assuming you understand what I have said above.

ORD(x: INTEGER): LONGINT
ORD(x: LONGINT): INTEGER
ORD(x: Enumeration): INTEGER
ORD(x: Subrange): Base(Subrange)

ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.

e.      Any other ideas?

I think we are done...



Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 11, 2010 12:32 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Quick summary:

I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/

On 11 Jan 2010, at 01:11, Randy Coleburn wrote:



Tony:

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

Agreed.




2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Read on for the long-winded version...

According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors.

Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm.

(I've been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of "floppy" as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)

On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.

One problem is that one doesn't really know the range of LONGINT unless we define it as some number of bits.  Rodney's proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?

What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.



 I say all this to point out the obvious, namely that LONGINT and INTEGER are different types.

Correct.  The current implementation treats them as completely separate.



 Therefore, IMO the language must make it clear how these different types interact.

I would argue that
   x: LONGINT := 23;
is wrong!  The programmer should have to write
   x: LONGINT := 23L;
instead.

This is what we currently implement.



 A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.

Also what we currently implement.



 Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.

I agree, and this is the current implementation.



 I have no problem with extending the existing operators to deal with LONGINT; it's just that the result should be LONGINT.
Given x: LONGINT := 49L;
   INC(x) yields 50L
   INC(x, 3L) yields 52L
      note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
   (x + 20L) yields 69L
      note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
   LAST(LONGINT) yields a LONGINT

This is exactly the current implementation.



 Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.

I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.



 Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
   Given longInt: LONGINT;   and   int: INTEGER;
   int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
   longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
   int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
   longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT

I think ORD/VAL suffice...



 Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write "int := longInt;" why not "int := 23L;" and why not "int := longInt + 57;" and is this different than "int := longInt + 57L;"? etc. etc.

I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.

Sorry, I have been too long-winded here.  To answer your questions succinctly:

1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.

2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Sunday, January 10, 2010 3:43 PM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] the LONGINT proposal

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:




I've been trying to follow along on this topic.

Here are my thoughts:

1.  LONGINT should be a distinct type different from INTEGER.

2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.

3.  Overflow should be a checked run-time error, not silently wrapped around.

4.  WRT assignability, I think explicit conversions should be used.

These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.

The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.

And yes, I do think we need a LONGINT type, not just to deal with large file sizes.

But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.

I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.

As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.

My two cents.

Regards,
Randy Coleburn



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

From jdp at polstra.com  Tue Jan 12 05:43:50 2010
From: jdp at polstra.com (John Polstra)
Date: Mon, 11 Jan 2010 20:43:50 -0800
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <4B4BFE06.5010400@polstra.com>

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From jay.krell at cornell.edu  Tue Jan 12 05:55:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 04:55:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
Message-ID: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>


I thought FloatMode was only related to floating point.

So I looked:

 

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

 

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


 

This part of it should be easy to implement for all architectures.

The entire thing probably isn't too difficult either on many platforms either.

 

However...I was surprised by this.

I thought the real "intent" in Modula-3 to not have this be configurable

and endeavor for overflow and divide by zero to always immediately

raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

 

For the floating point stuff:

 

Probably like other per-platform code, this should be done in #ifdefed C.

 

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx

http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html

etc.

 

 - Jay

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

From rcolebur at SCIRES.COM  Tue Jan 12 05:59:01 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Mon, 11 Jan 2010 23:59:01 -0500
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <4B4BFE06.5010400@polstra.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>

I also took the liberty of contacting him.  Shown below is my message and his response:
Regards,
Randy

On Mon, 11 Jan 2010 12:19:26 -0500
Randy Coleburn <rcolebur at SCIRES.COM> wrote:

> Just want to let you know that the folks hosting the mail list service are trying to fulfill your request to be added to the m3devel mail list.
> 
> The problem seems to be blacklisting of one of the hosts.  At first it seemed your email address was blacklisted, but upon further investigation it seems your email server (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has blacklisted the mail list server at elegosoft.  Note that the elegosoft server is based in Germany.
> 
> The server admins are working on the problem, but not sure if/when it will be resolved.
> 
> I'm one of the developers and also subscribe to the list and noticed the traffic about your request, so thought I would try and send you an email to see if it gets thru and to let you know of the problem.
> 
> Regards,
> Randy
> 

Thanks for the heads up. I'll give them a call to see what the problem is.

AT&T actually does it's mail hosting through Yahoo mail, so they might actually be the ones doing the blacklisting. I'm going to do some poking around on this end; and I'll send you an email if I find anything noteworthy.

Thank you.

-- 
Chris <dimonax at att.net>


-----Original Message-----
From: John Polstra [mailto:jdp at polstra.com] 
Sent: Monday, January 11, 2010 11:44 PM
To: Tony Hosking
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] Fwd: CM3 development Inquiry.

I forwarded this to him, and my mail log says it was delivered.

John

Tony Hosking wrote:
> Actually, that diagnostic indicates that scc-mailrelay.att.net 
> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft 
> mail server (it is blacklisted!).
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
> 
>> Quoting Tony Hosking <hosking at cs.purdue.edu 
>> <mailto:hosking at cs.purdue.edu>>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>> 
>>>> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous 
>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail 
>>>>  is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com 
>> <http://mx0.elegosoft.com>.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net <mailto:dimonax at att.net>>: host 
>> scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 
>> DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 
>> 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
>> DE163214194
>>
> 


From rcolebur at SCIRES.COM  Tue Jan 12 06:18:51 2010
From: rcolebur at SCIRES.COM (Randy Coleburn)
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>

Jay,

I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.

This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.

Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.

I agree that lumping the integer overflow control into an interface named "FloatMode" makes it a bit hard to find since "FloatMode" would make one think that the interface deals only with floating point.

So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won't care and his code will eventually break.  See the comments about long-lived readers/writers for an example.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode

I thought FloatMode was only related to floating point.
So I looked:

   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.

   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}


This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.

However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

For the floating point stuff:

Probably like other per-platform code, this should be done in #ifdefed C.

http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.

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

From jay.krell at cornell.edu  Tue Jan 12 06:32:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 05:32:35 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD12@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W55FC6ED07465737B2146C4E66C0@phx.gbl>


Rewrite code to avoid overflow?

 That seems..difficult.

 Write it in a typical normal straightfoward

   fashion and rely on overflow checking to avoid bugs, imho.

 

I think relying on silent wrap is bad but relying on overflow

checks is appropriate.

 

Really what I think is you need multiple types or interfaces.

So that you can request silent wraparound for certain code

and overflow checking for other code. It's not a per-thread

setting, but a type thing.

It is more "statically bound" than a runtime per thread setting.

 

In the absence of this profusion of

types though, a good safe compromise is the INTEGER/Word

split. INTEGER is signed and should check overflow.

 

Word is unsigned and silently wraps.

 

Really this isn't everything. You also want unsigned

with overflow checks, maybe signed with silent wraparound.

Maybe the arithmetic library provides all this.

I need to check.

 

 

Testing your code one way and shipping it another way

is a bad recipe. The checks need to be preserved

in the shipping version because testing is never complete.

Also because the checks might have unintended side effects.

Ship what you test.

 

 

Again though, isn't silent wraparound a safety hole?

Or maybe not, maybe given that we have array bounds checking,

maybe safety is preserved?

(You know, what would happen incorrectly when positive + positive

yields negative?)

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Tue, 12 Jan 2010 00:18:51 -0500
Subject: Re: [M3devel] FloatMode





Jay, 
 
I think the documented intent in Modula-3 is that the programmer should write his code under the premise that any operation that could produce an overflow should be rewritten so as to avoid that problem.  Further, that the implementation may or may not actually check for this condition, but to rely on it working a certain way (e.g., silent wrap) would be wrong.  Further, if FloatMode were implemented, it would be possible to force the overflow check on.
 
This situation does not prohibit a programmer from writing something that could produce overflow, and the fact that on some implementations overflow is not checked is considered ok for performance reasons.  It is just that if the programmer were to rely on silent wrap, this reliance is NOT supported by the language and at some point will probably cause a checked runtime error.
 
Indeed, folks often turn on extra checking during program testing to find as many programming faults as possible, then turn off the extra checking for production/delivery code to gain performance.  So Modula-3 as a language supports this concept, though not all implementations may provide the ability to turn certain checks on or off.
 
I agree that lumping the integer overflow control into an interface named ?FloatMode? makes it a bit hard to find since ?FloatMode? would make one think that the interface deals only with floating point.
 
So, in Modula-3 a good programmer will add appropriate logic to prevent overflow by explicitly coding wrap-around or using some other method appropriate to the task at hand.  A sloppy programmer won?t care and his code will eventually break.  See the comments about long-lived readers/writers for an example.
 
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, January 11, 2010 11:55 PM
To: Tony; m3devel
Subject: [M3devel] FloatMode
 
I thought FloatMode was only related to floating point.
So I looked:
 
   "IntOverflow" = an integer operation produced a result whose
   absolute value is too large to be represented.
 
   "IntDivByZero" = integer "DIV" or "MOD" by zero.
\end{quote}

 
This part of it should be easy to implement for all architectures.
The entire thing probably isn't too difficult either on many platforms either.
 
However...I was surprised by this.
I thought the real "intent" in Modula-3 to not have this be configurable
and endeavor for overflow and divide by zero to always immediately
raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
 
For the floating point stuff:
 
Probably like other per-platform code, this should be done in #ifdefed C.
 
http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
etc.
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/57b85e47/attachment-0002.html>

From mika at async.async.caltech.edu  Tue Jan 12 06:46:03 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:46:03 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>
Message-ID: <20100112054603.A07EA1A2078@async.async.caltech.edu>

Jay K writes:
>
>>> One thing I've really struggled with over the introduction of LONGINT is
>>> the need for distinct literal forms. This strikes me as odd=2C since
>>> literals are really just ways of writing values=2C rather than stating
>>> anything about how they should be represented.
>>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
>=2C
>>> but they really do have incompatible value representations).
>>
>> I agree=2C the need for distinctly typed literals is much greater for the
>> floating types than the integer types=2C because they can't be viewed
>> as having overlapping value sets in any reasonable way.
>
>=20
>Huh? This seems to me to be directly opposite of the truth.
>LONGREAL is a strict superset of REAL in what it can represent.
>There is *complete* overlap.
>Am I really mistaken here?
>Floating point is indeed very wierd=2C but it isn't this wierd.
>Right?
>=20
>=20
> - Jay

Jay, I think if you have hardware that's strictly compliant with IEEE
754, you're right.  Or at least there exists an interpretation of the
values that have this property.  I alluded earlier to the fact that
Alpha represents single-precision by zeroing out the middle of the
double-precision register (some of the mantissa and some of the exponent).

However I'm sure there are systems for which this is not true.  Is 
Modula-3 forbidden from being ported to such machines?

    Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:47:25 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:47:25 -0800
Subject: [M3devel] Mixed arithmetic
In-Reply-To: <COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl> 
References: <4B4BBFE6.1090701@lcwb.coop>
	<COL101-W508C3D8A22C9DFCA49C621E66C0@phx.gbl>
Message-ID: <20100112054725.2C8ED1A207C@async.async.caltech.edu>

Jay K writes:
>
>> rather than having things
>> happen behind the scenes=2C without the programmer's coding them
>=20
>=20
>Just a reminder that things happen behind the scenes *all the time*.
>It is the norm=2C not the exception.
>Look at what "try" does.
>  It is two or three function calls.
>Look at the garbage collector.=20
>Look at layering in various places.

These things are not visible to the programmer.

     Mika


From mika at async.async.caltech.edu  Tue Jan 12 06:53:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 21:53:49 -0800
Subject: [M3devel] 64bit file sizes now?
In-Reply-To: <COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<185464DB-5CA9-4D5B-BCF7-9F7048D9FA05@cs.purdue.edu>
	<COL101-W73C6D98789B184C19F1F8E66C0@phx.gbl>
Message-ID: <20100112055349.CBEFE1A2080@async.async.caltech.edu>


Why not change the implementation to something using LONGINT (or
BigInteger.T...)  and then provide the old ones as a thin veneer over
the new implementation, marking the old ones as <*OBSOLETE*>...

    Mika


Jay K writes:
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Large files (64bit file sizes) are very old.
>
>Windows 95 had them in the released API 14+ years ago (1995)=2C NT a few ye=
>ars before that (1993?)=2C betas earlier. I heard VMS had 64bit file sizes =
>but I haven't confirmed.
>
>=20
>
> > If the use-case is typically INTEGER then perhaps we
> > need to think of alternatives using abstraction?
>=20
>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?
>
>Default calls Seek/Index/Length=2C range checked truncation?
>
>Kind of an annoying duplicity of APIs though.
>
>=20
>
> - Jay
>=20
>
>
>From: hosking at cs.purdue.edu
>Date: Mon=2C 11 Jan 2010 22:10:06 -0500
>To: jay.krell at cornell.edu
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] 64bit file sizes now?
>
>
>
>
>On 11 Jan 2010=2C at 22:02=2C Jay K wrote:
>
>
>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(ex=
>pr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire)=
>.
>
>
>
>That's what I think makes most sense.
>
>
> And this is already in place.
>
>
>
>Yes=2C it's in place.
>
>
>
>?
>=20
>So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Le=
>ngth to all be LONGINT=2C "whatever the consequences"? The consequences are=
> roughly the first diff I sent out=2C with the caveats that I used ORD() in=
>stead of VAL(=2CINTEGER)=2C and a few packages were left to fix. It is mech=
>anical and simple and predictable=2C just tedious and ugly.
>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few might g=
>ain capacity.
>Classic simple example is the mklib and libdump code=2C they read the entir=
>e file into memory and then deal with that.
>
>
>
>If the use-case is typically INTEGER then perhaps we need to think of alter=
>natives using abstraction?
>
>
> I can send the diffs ahead of time=2C but there's really no choices left a=
>s to what they'll look like=2C it is forced by the limited capability of LO=
>NGINT.
>Had they used LONGINT in the first place=2C of course=2C there'd be no diff=
> at this time=2C the ugliness would have been builtin from the start.
>
>When they originally wrote it large file sizes were only proposed not imple=
>mented.  I don't think C even had long long then.  (Yes=2C I am showing my =
>age! -- we are talking almost 20 years ago now!)  If they had used LONGINT =
>from the start then folks would have not had any ugliness because all would=
> have used LONGINT.    Now=2C to save some hassles in future=2C perhaps we =
>need a better abstraction!  Let's ponder that before you propagate your cha=
>nges.
>
> 		 	   		  =
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Large files (64bit file sizes) are very old.<BR>
>Windows 95 had them in the released&nbsp=3BAPI 14+ years ago (1995)=2C NT a=
> few years before that (1993?)=2C betas earlier. I heard VMS had 64bit file=
> sizes but I haven't confirmed.<BR>
>&nbsp=3B<BR>
><DIV>&nbsp=3B&gt=3B If the use-case is typically INTEGER then perhaps we</D=
>IV>
><DIV>&nbsp=3B&gt=3B need to think of alternatives using abstraction?</DIV>
>&nbsp=3B<BR>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?<BR>
>Default calls Seek/Index/Length=2C range checked truncation?<BR>
>Kind of an annoying duplicity of APIs though.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>
><HR id=3DstopSpelling>
>From: hosking at cs.purdue.edu<BR>Date: Mon=2C 11 Jan 2010 22:10:06 -0500<BR>T=
>o: jay.krell at cornell.edu<BR>CC: m3devel at elegosoft.com<BR>Subject: Re: [M3de=
>vel] 64bit file sizes now?<BR><BR><BASE>
><DIV><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLL=
>APSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPA=
>CING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxAppl=
>e-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BOR=
>DER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LE=
>TTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=
>=3DecxApple-style-span>
><DIV style=3D"WORD-WRAP: break-word"><SPAN style=3D"TEXT-TRANSFORM: none=3B=
> TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B W=
>HITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WO=
>RD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TRANSFORM:=
> none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvet=
>ica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C=
>0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TR=
>ANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12p=
>x Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(=
>0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D=
>"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B F=
>ONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COL=
>OR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN =
>style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separ=
>ate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: norma=
>l=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-spa=
>n><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPS=
>E: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACIN=
>G: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-s=
>tyle-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER=
>-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTE=
>R-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3Dec=
>xApple-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=
>=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: norma=
>l=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" =
>class=3DecxApple-style-span>
><DIV><SPAN style=3D"FONT-SIZE: medium" class=3DecxApple-style-span>On 11 Ja=
>n 2010=2C at 22:02=2C Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN>=
></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
><DIV><BR class=3DecxApple-interchange-newline>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(e=
>xpr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire=
>).<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>That's what I think makes most sense.</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BAnd this is already in place.<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>Yes=2C it's in place.</DIV>
><DIV><BR></DIV>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>?<BR>&nbsp=3B<BR>So I should go ahead and update File.i3/Status/size and R=
>d/Wr/Index/Seek/Length to all be LONGINT=2C "whatever the consequences"? Th=
>e consequences are roughly the first diff I sent out=2C with the caveats th=
>at I used ORD() instead of VAL(=2CINTEGER)=2C and a few packages were left =
>to fix. It is mechanical and simple and predictable=2C just tedious and ugl=
>y.<BR>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few m=
>ight gain capacity.<BR>Classic simple example is the mklib and libdump code=
>=2C they read the entire file into memory and then deal with that.<BR></DIV=
>></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>If the use-case is typically INTEGER then perhaps we need to think of =
>alternatives using abstraction?</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BI can send the diffs ahead of time=2C but there's really no choice=
>s left as to what they'll look like=2C it is forced by the limited capabili=
>ty of LONGINT.<BR>Had they used LONGINT in the first place=2C of course=2C =
>there'd be no diff at this time=2C the ugliness would have been builtin fro=
>m the start.</DIV></SPAN></BLOCKQUOTE><BR></DIV>
><DIV>When they originally wrote it large file sizes were only proposed not =
>implemented. &nbsp=3BI don't think C even had <FONT class=3DecxApple-style-=
>span face=3DCourier>long long</FONT>&nbsp=3Bthen. &nbsp=3B(Yes=2C I am show=
>ing my age! -- we are talking almost 20 years ago now!) &nbsp=3BIf they had=
> used LONGINT from the start then folks would have not had any ugliness bec=
>ause all would have used LONGINT. &nbsp=3B &nbsp=3BNow=2C to save some hass=
>les in future=2C perhaps we need a better abstraction! &nbsp=3BLet's ponder=
> that before you propagate your changes.</DIV>
><DIV><BR></DIV> 		 	   		  </body>
></html>=
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_--


From jay.krell at cornell.edu  Tue Jan 12 07:19:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:19:45 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>


When do you forsee any non-IEEE 754 floating point environments coming into existance?

 

Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?

For that matter, probably Perl and Python, but I'd have to check.

Chances are high they only expose 64bit float and nothing else.

 

 

The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?

 

 

I know, I know "never say never", but sometimes....?

 

 

Certainly there are also 80bit formats on x86 and 68K.

 Though x86 is moving away from this with SSE/SSE2.

And I think 128bit formats on PowerPC.

And something beyond 64bits on IA64 (Itanium).

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/a8d6a0f6/attachment-0002.html>

From jay.krell at cornell.edu  Tue Jan 12 07:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:21:43 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112054603.A07EA1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
Message-ID: <COL101-W608B0F5C8B52AB95E8D61E66C0@phx.gbl>


And even these 80 bit and 128 bit formats I'm sure can represent all values losslessly of the smaller types. I have to look into this stuff though.

 

 - Jay

 


From: jay.krell at cornell.edu
To: mika at async.async.caltech.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Integer literals
Date: Tue, 12 Jan 2010 06:19:45 +0000



When do you forsee any non-IEEE 754 floating point environments coming into existance?
 
Or for that matter, simple efficient compatibility with all the C, C++, Java, Modula-3, JavaScript, etc. code in the world not being a feature of all CPUs, at least ones that have any floating point support? Or any software floating point library?
For that matter, probably Perl and Python, but I'd have to check.
Chances are high they only expose 64bit float and nothing else.
 
 
The precisions and magnitudes of 32bit float and 64bit double are *really old* and in no apparent danger of going away. I think over 25 years and counting (consider the "SANE" environment of the Macintosh in 1984 and the similarly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might have used a different format, but the processor had no floating point support.) I think the only system with different formats is VAX. And Alpha supports IEEE-754 and VAX. ?
 
 
I know, I know "never say never", but sometimes....?
 
 
Certainly there are also 80bit formats on x86 and 68K.
 Though x86 is moving away from this with SSE/SSE2.
And I think 128bit formats on PowerPC.
And something beyond 64bits on IA64 (Itanium).
 
 
 - Jay
 
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals 
> Date: Mon, 11 Jan 2010 21:46:03 -0800
> From: mika at async.async.caltech.edu
> 
> Jay K writes:
> >
> >>> One thing I've really struggled with over the introduction of LONGINT is
> >>> the need for distinct literal forms. This strikes me as odd=2C since
> >>> literals are really just ways of writing values=2C rather than stating
> >>> anything about how they should be represented.
> >>> (Yes=2C I know that the REAL/LONGREAL/EXTENDED literals are all distinct=
> >=2C
> >>> but they really do have incompatible value representations).
> >>
> >> I agree=2C the need for distinctly typed literals is much greater for the
> >> floating types than the integer types=2C because they can't be viewed
> >> as having overlapping value sets in any reasonable way.
> >
> >=20
> >Huh? This seems to me to be directly opposite of the truth.
> >LONGREAL is a strict superset of REAL in what it can represent.
> >There is *complete* overlap.
> >Am I really mistaken here?
> >Floating point is indeed very wierd=2C but it isn't this wierd.
> >Right?
> >=20
> >=20
> > - Jay
> 
> Jay, I think if you have hardware that's strictly compliant with IEEE
> 754, you're right. Or at least there exists an interpretation of the
> values that have this property. I alluded earlier to the fact that
> Alpha represents single-precision by zeroing out the middle of the
> double-precision register (some of the mantissa and some of the exponent).
> 
> However I'm sure there are systems for which this is not true. Is 
> Modula-3 forbidden from being ported to such machines?
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/656c93c9/attachment-0002.html>

From mika at async.async.caltech.edu  Tue Jan 12 07:42:43 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 11 Jan 2010 22:42:43 -0800
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl> 
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
Message-ID: <20100112064243.6828D1A2078@async.async.caltech.edu>

Jay K writes:
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?

x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
done in extended and then truncated by a store/load pair, if I remember
correctly).  That's not a non-IEEE format.  And I find it puzzling that
we don't expose the x87 native format in Modula-3 as EXTENDED.

One common completely non-IEEE format is Cray floating point.

In any case writing IEEE floating point into the specification of a
systems language like Modula-3 seems completely wrong to me.
Who knows what tomorrow will bring?

    Mika

>
>=20
>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>ature of all CPUs=2C at least ones that have any floating point support? Or=
> any software floating point library?
>
>For that matter=2C probably Perl and Python=2C but I'd have to check.
>
>Chances are high they only expose 64bit float and nothing else.
>
>=20
>
>=20
>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?
>
>=20
>
>=20
>
>I know=2C I know "never say never"=2C but sometimes....?
>
>=20
>
>=20
>
>Certainly there are also 80bit formats on x86 and 68K.
>
> Though x86 is moving away from this with SSE/SSE2.
>
>And I think 128bit formats on PowerPC.
>
>And something beyond 64bits on IA64 (Itanium).
>
>=20
>
>=20
>
> - Jay
>=20
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Integer literals=20
>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>> From: mika at async.async.caltech.edu
>>=20
>> Jay K writes:
>> >
>> >>> One thing I've really struggled with over the introduction of LONGINT=
> is
>> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>e
>> >>> literals are really just ways of writing values=3D2C rather than stat=
>ing
>> >>> anything about how they should be represented.
>> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>tinct=3D
>> >=3D2C
>> >>> but they really do have incompatible value representations).
>> >>
>> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
>r the
>> >> floating types than the integer types=3D2C because they can't be viewe=
>d
>> >> as having overlapping value sets in any reasonable way.
>> >
>> >=3D20
>> >Huh? This seems to me to be directly opposite of the truth.
>> >LONGREAL is a strict superset of REAL in what it can represent.
>> >There is *complete* overlap.
>> >Am I really mistaken here?
>> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
>> >Right?
>> >=3D20
>> >=3D20
>> > - Jay
>>=20
>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>> 754=2C you're right. Or at least there exists an interpretation of the
>> values that have this property. I alluded earlier to the fact that
>> Alpha represents single-precision by zeroing out the middle of the
>> double-precision register (some of the mantissa and some of the exponent)=
>.
>>=20
>> However I'm sure there are systems for which this is not true. Is=20
>> Modula-3 forbidden from being ported to such machines?
>>=20
>> Mika
> 		 	   		  =
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>When do you forsee any non-IEEE 754 floating point environments coming into=
> existance?<BR>
>&nbsp=3B<BR>
>Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>ng a feature of all CPUs=2C at least ones that have any floating point supp=
>ort? Or any software floating point library?<BR>
>For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>Chances are high they only expose 64bit float and nothing else.<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>The precisions and magnitudes of 32bit float and 64bit double are *really o=
>ld* and in no apparent danger of going away. I think over 25 years and coun=
>ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>e used a different format=2C but the processor had no floating point suppor=
>t.) I think the only system with different formats is VAX. And Alpha suppor=
>ts IEEE-754 and VAX. ?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>I know=2C I know "never say never"=2C but sometimes....?<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>Certainly there are also 80bit formats on x86 and 68K.<BR>
>&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>And I think 128bit formats on PowerPC.<BR>
>And something beyond 64bits on IA64 (Itanium).<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>=3B literals are really just ways of writing values=3D2C rather than statin=
>g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>  		  </body>
></html>=
>
>--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--


From jay.krell at cornell.edu  Tue Jan 12 07:55:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 06:55:27 +0000
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>, ,
	<4B4BC627.6030103@lcwb.coop>,
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>, ,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>,
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>,
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>


IEEE-754 is extremely long standing.

 

But it isn't the issue anyway.

 

The issue is if there exist good candiates for REAL and LONGREAL

such that LONGREAL can losslessly represent all values of REAL.

 

C systems are gradually supporting 3 or more floating point formats.

PowerPC has an optional 128 bit long double.

http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00365.html

 

I wonder if ultimately we should provide "pieces" for people

to define their own types:

 

TYPE Int1 = BITS 32, unsigned, integer, trap overflow;

TYPE Int2 = BITS 64, signed, integer, silent overflow;

TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;

TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;

 

and then provide just a few "canned" "popular" types so that

a lot of code can interoperate with a lot of code, but if a programmer

really needs something else, he has a chance of defining it.

 

Or maybe we can only define what is efficient in hardware, but still

do so with a syntax like this??

 

 

 - Jay
 
> To: jay.krell at cornell.edu
> Date: Mon, 11 Jan 2010 22:42:43 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Integer literals
> 
> Jay K writes:
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?
> 
> x86 (well, x87) is actually very much IEEE 754. It's almost the reference
> implementation. Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly). That's not a non-IEEE format. And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.
> 
> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?
> 
> Mika
> 
> >
> >=20
> >
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
> >ature of all CPUs=2C at least ones that have any floating point support? Or=
> > any software floating point library?
> >
> >For that matter=2C probably Perl and Python=2C but I'd have to check.
> >
> >Chances are high they only expose 64bit float and nothing else.
> >
> >=20
> >
> >=20
> >
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?
> >
> >=20
> >
> >=20
> >
> >I know=2C I know "never say never"=2C but sometimes....?
> >
> >=20
> >
> >=20
> >
> >Certainly there are also 80bit formats on x86 and 68K.
> >
> > Though x86 is moving away from this with SSE/SSE2.
> >
> >And I think 128bit formats on PowerPC.
> >
> >And something beyond 64bits on IA64 (Itanium).
> >
> >=20
> >
> >=20
> >
> > - Jay
> >=20
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Integer literals=20
> >> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
> >> From: mika at async.async.caltech.edu
> >>=20
> >> Jay K writes:
> >> >
> >> >>> One thing I've really struggled with over the introduction of LONGINT=
> > is
> >> >>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
> >e
> >> >>> literals are really just ways of writing values=3D2C rather than stat=
> >ing
> >> >>> anything about how they should be represented.
> >> >>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
> >tinct=3D
> >> >=3D2C
> >> >>> but they really do have incompatible value representations).
> >> >>
> >> >> I agree=3D2C the need for distinctly typed literals is much greater fo=
> >r the
> >> >> floating types than the integer types=3D2C because they can't be viewe=
> >d
> >> >> as having overlapping value sets in any reasonable way.
> >> >
> >> >=3D20
> >> >Huh? This seems to me to be directly opposite of the truth.
> >> >LONGREAL is a strict superset of REAL in what it can represent.
> >> >There is *complete* overlap.
> >> >Am I really mistaken here?
> >> >Floating point is indeed very wierd=3D2C but it isn't this wierd.
> >> >Right?
> >> >=3D20
> >> >=3D20
> >> > - Jay
> >>=20
> >> Jay=2C I think if you have hardware that's strictly compliant with IEEE
> >> 754=2C you're right. Or at least there exists an interpretation of the
> >> values that have this property. I alluded earlier to the fact that
> >> Alpha represents single-precision by zeroing out the middle of the
> >> double-precision register (some of the mantissa and some of the exponent)=
> >.
> >>=20
> >> However I'm sure there are systems for which this is not true. Is=20
> >> Modula-3 forbidden from being ported to such machines?
> >>=20
> >> Mika
> > =
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Verdana
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >When do you forsee any non-IEEE 754 floating point environments coming into=
> > existance?<BR>
> >&nbsp=3B<BR>
> >Or for that matter=2C simple efficient compatibility with all the C=2C C++=
> >=2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
> >ng a feature of all CPUs=2C at least ones that have any floating point supp=
> >ort? Or any software floating point library?<BR>
> >For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
> >Chances are high they only expose 64bit float and nothing else.<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >The precisions and magnitudes of 32bit float and 64bit double are *really o=
> >ld* and in no apparent danger of going away. I think over 25 years and coun=
> >ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
> >larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
> >e used a different format=2C but the processor had no floating point suppor=
> >t.) I think the only system with different formats is VAX. And Alpha suppor=
> >ts IEEE-754 and VAX. ?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >I know=2C I know "never say never"=2C but sometimes....?<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >Certainly there are also 80bit formats on x86 and 68K.<BR>
> >&nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
> >And I think 128bit formats on PowerPC.<BR>
> >And something beyond 64bits on IA64 (Itanium).<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
> > m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
> >R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
> >.async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
> >gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
> >oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
> >iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
> >=3B literals are really just ways of writing values=3D2C rather than statin=
> >g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
> >d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
> >ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
> >t=3B&gt=3B but they really do have incompatible value representations).<BR>=
> >&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
> >ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
> > types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
> >gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
> >=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
> >e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
> >rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
> >overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
> >g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
> >Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
> >R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
> >pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
> > interpretation of the<BR>&gt=3B values that have this property. I alluded =
> >earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
> >oing out the middle of the<BR>&gt=3B double-precision register (some of the=
> > mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
> >there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
> >den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> =
> > </body>
> ></html>=
> >
> >--_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/60619ac5/attachment-0002.html>

From jay.krell at cornell.edu  Tue Jan 12 09:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 08:00:41 +0000
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W53BC0E8E635AB782E72BD8E66C0@phx.gbl>


 > Also, in case anyone is interested
> the current HEAD fails to compile the following packages on Windows Vista:
> m3core, libm3, m3tk

 

It works for me. On XP, but same thing.

Be sure to run upgrade.py to first update the compiler.

An older compiler cannot build a current m3core and/or libm3.

I got errors in Convert.m3 for example.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 23:09:46 -0500
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] the LONGINT proposal





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

From jay.krell at cornell.edu  Tue Jan 12 10:23:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 09:23:00 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>


I propose that integer signed overflow always raise an immediate exception.

Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.

For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

 

 

I propose that FloatMode's integer features not be the way forward.

 

 

There are two implementation strategies.

 

 

 - "check the carry flag"

   A processor-specific thing, but possibly something easy for the gcc backend to do.

   And very likely easy for the integrated backend.

   Probably very efficient.

 

 

 - internally generate function calls for every arithmetic operation

   like how sets are implemented

 

 

 Implementing most such functions is easy enough in portable C.

 Or maybe using Modula-3 and interface Word.

 

 

 e.g.

   void add(int a, int b, int* c, int* overflow)

   {

    int d = (a + b);

    /* overflow if input signs are equal and output sign is different;

        if input signs are unequal, overflow is not possible

        positive + positive: expect positive, else overflow

        negative + negative: expect negative, else overflow

        positive + negative: overflow not possible */

    *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

 

   void sub(int a, int b, int* c, int* overflow)

   {

    int d = (a - b);

    /* overflow if input signs are unequal and output sign is different than first input;

        if input signs are equal, overflow is not possible;

        positive - negative: expect positive, overflow if negative

        negative - positive: expect negative, overflow if positive

        positive - positive, negative - negative: overflow not possible */

    *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));

    *c = d;

  }

 

#include <limits.h>

 

  void mult(int a, int b, int* c, int* overflow)

  {

    /* do operation in higher precision and check if it fits */

    int64 d = (a * (int64)b);

    *c = (int)d;

    *overflow = (d >= INT_MIN && d <= INT_MAX);

  }

 

/* for interface Word */

  typedef unsigned uint;

 

  void addu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a + b);

    /* overflow if output less than either input */

    *overflow = (d < a);

    *c = d;

 }

 

  void subu(uint a, uint b, uint* c, int* overflow)

  {

     uint d = (a - b);

    /* overflow if output greater than first input */

    *overflow = (d > a);

    *c = d;

 }

 

  void multu(uint a, uint b, uint* c, int* overflow)

  {

    /* operate at higher precision and see if it fits */

     uint64 d = (a * (uint64)b);

    *overflow = (d <= UINT_MAX);

    *c = (uint)d;

 }

 

 void multLU(uint64 a, uint64 b, uint64* c, int* overflow)

 {

  /* break it down into smaller operations, not shown, but not difficult */

 }

 

 

Yes I know this is inefficient, but such is a possible price of portable safety.

 

 

A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

 

  

 - Jay





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

From jay.krell at cornell.edu  Tue Jan 12 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 10:23:24 +0000
Subject: [M3devel] Change File.i3/Status.size from CARDINAL to
	[0L..LAST(LONGINT)].
In-Reply-To: <20100112102039.C3F672474001@birch.elegosoft.com>
References: <20100112102039.C3F672474001@birch.elegosoft.com>
Message-ID: <COL101-W288784810774F26CD509E0E66C0@phx.gbl>


diff attached (cvs is lame..)

 

 - Jay


 
> Date: Tue, 12 Jan 2010 11:20:39 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/12 11:20:39
> 
> Modified files:
> cm3/m3-db/stable/src/: LogManager.m3 
> cm3/m3-libs/libbuf/src/: Buf.m3 
> cm3/m3-libs/libm3/src/os/Common/: File.i3 
> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 
> SocketPosix.m3 
> cm3/m3-libs/libm3/src/os/WIN32/: FSWin32.m3 FileWin32.m3 
> LazyConsole.m3 
> cm3/m3-libs/libm3/src/rw/: FileRd.m3 FileWr.m3 
> cm3/m3-sys/cm3/src/: WebFile.m3 
> cm3/m3-sys/cm3ide/src/utils/: Buf.m3 
> cm3/m3-sys/fix_nl/src/: Main.m3 
> cm3/m3-sys/m3quake/src/: QScanner.m3 
> cm3/m3-sys/mklib/src/: Main.m3 
> cm3/m3-tools/cmpdir/src/: Main.m3 
> cm3/m3-tools/dirfp/src/: Main.m3 
> cm3/m3-tools/m3tohtml/src/: DBRd.m3 
> 
> Log message:
> Change File.i3/Status.size from CARDINAL to [0L..LAST(LONGINT)].
> (Notice that some code checks if it is < 0, though don't
> confuse that with <= 0.)
> Leave rd/wr essentially unchanged.
> This is probably enough to fix the exception when browsing to a directory with large files.
> Not that much/any code can read/write such files on 32bit system -- all the direct users of File.i3
> appear to read the entire file into memory.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/b12b560b/attachment-0002.txt>

From wagner at elegosoft.com  Tue Jan 12 13:13:05 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 12 Jan 2010 13:13:05 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
Message-ID: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> Actually, that diagnostic indicates that scc-mailrelay.att.net is   
> blocking messages from the Elegosoft mail server (it is blacklisted!).

Ups, I must have misread that. I should pay better attention.
Mike, can you investigate why we're blacklisted at att?

Thanks,

Olaf

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>
>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>
>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Chris <dimonax at att.net>
>>>> Date: 10 January 2010 16:43:32 EST
>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>> Subject: Re: CM3 development Inquiry.
>>>>
>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>
>>>>> Did you manage to subscribe?
>>>>
>>>> I put in another subscription request just after your previous    
>>>> reply, and I'm still waiting. I wonder if the confirmation e-mail  
>>>>   is getting through. Nonetheless, I'll keep trying.
>>
>> Unfortunately the address does not work:
>>
>> This is the mail system at host mx0.elegosoft.com.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>>                   The mail system
>>
>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>    command)
>>
>> If he really wants to join, he needs another mail address, but I cannot
>> tell him that.
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From michael.anderson at elego.de  Tue Jan 12 13:52:32 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 13:52:32 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<20100112131305.rzcfouhjrocs4gw4@mail.elegosoft.com>
Message-ID: <20100112135232.hd9dy91casc0g0kk@mail.elego.de>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> Actually, that diagnostic indicates that scc-mailrelay.att.net is    
>> blocking messages from the Elegosoft mail server (it is   
>> blacklisted!).
>
> Ups, I must have misread that. I should pay better attention.
> Mike, can you investigate why we're blacklisted at att?
>

I'm looking into it. I filled out att's unblock form and asked for  
clarification. I don't see anything in logs that looks like abuse from  
our side.  Messages to martinbishop at bellsouth.net have apparently been  
getting bounced by att for some time.

Mike

> Thanks,
>
> Olaf
>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous    
>>>>>  reply, and I'm still waiting. I wonder if the confirmation   
>>>>> e-mail   is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                  The mail system
>>>
>>> <dimonax at att.net>: host scc-mailrelay.att.net[204.127.208.75] said:
>>>   521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521 DNSRBL:
>>>   Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>   command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30   
>>> 23 45 86 95
>>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>>> DE163214194
>>>
>>
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 18:00:04 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 12:00:04 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
References: <20100112064243.6828D1A2078@async.async.caltech.edu>
	<COL101-W554FFEF412B3E4C65BFD78E66C0@phx.gbl>
Message-ID: <20100112170003.GA13141@topoi.pooq.com>

On Tue, Jan 12, 2010 at 06:55:27AM +0000, Jay K wrote:
> 
> TYPE Int1 = BITS 32, unsigned, integer, trap overflow;
> 
> TYPE Int2 = BITS 64, signed, integer, silent overflow;
> 
> TYPE Float1 = BITS 64, floating point, signed, mantissa 53, exponent 10;
> 
> TYPE Float2 = BITS 128, floating point, signed, mantissa 106, exponent 20;
> 
>  
> 
> and then provide just a few "canned" "popular" types so that
> 
> a lot of code can interoperate with a lot of code, but if a programmer
> 
> really needs something else, he has a chance of defining it.
> 
>  
> 
> Or maybe we can only define what is efficient in hardware, but still
> 
> do so with a syntax like this??

That resembles the approach of C--.  You have to explicitly define the 
precision, byte sex, etc. of your data, and the compiler refuses your 
program if it doesn't match what the machine provides.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 19:31:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:31:46 -0500
Subject: [M3devel] Integer literals
In-Reply-To: <20100112064243.6828D1A2078@async.async.caltech.edu>
References: <14BF9CAD-8DCD-4D65-8928-88329D12D2F6@cs.purdue.edu>,
	<4B4BC627.6030103@lcwb.coop>
	<COL101-W1292541F15B65FFE3C2EE3E66C0@phx.gbl>,
	<20100112054603.A07EA1A2078@async.async.caltech.edu>
	<COL101-W35F8A9E7D9A8EDBD07E5A6E66C0@phx.gbl>
	<20100112064243.6828D1A2078@async.async.caltech.edu>
Message-ID: <09217458-CE1E-4928-85EE-E8DCC4CC7755@cs.purdue.edu>


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 12 Jan 2010, at 01:42, Mika Nystrom wrote:

> Jay K writes:
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?
> 
> x86 (well, x87) is actually very much IEEE 754.  It's almost the reference
> implementation.  Normal on x87 is 80-bit extended (all math in the x87 is
> done in extended and then truncated by a store/load pair, if I remember
> correctly).  That's not a non-IEEE format.  And I find it puzzling that
> we don't expose the x87 native format in Modula-3 as EXTENDED.

That would also be a great project for someone to pick up.  ;-)  Just trying to encourage participation...

> One common completely non-IEEE format is Cray floating point.
> 
> In any case writing IEEE floating point into the specification of a
> systems language like Modula-3 seems completely wrong to me.
> Who knows what tomorrow will bring?

I agree that the spec should be neutral on the formats.  Just as it is about INTEGER and ADDRESS.

> 
>    Mika
> 
>> 
>> =20
>> 
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc. code in the world not being a fe=
>> ature of all CPUs=2C at least ones that have any floating point support? Or=
>> any software floating point library?
>> 
>> For that matter=2C probably Perl and Python=2C but I'd have to check.
>> 
>> Chances are high they only expose 64bit float and nothing else.
>> 
>> =20
>> 
>> =20
>> 
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?
>> 
>> =20
>> 
>> =20
>> 
>> I know=2C I know "never say never"=2C but sometimes....?
>> 
>> =20
>> 
>> =20
>> 
>> Certainly there are also 80bit formats on x86 and 68K.
>> 
>> Though x86 is moving away from this with SSE/SSE2.
>> 
>> And I think 128bit formats on PowerPC.
>> 
>> And something beyond 64bits on IA64 (Itanium).
>> 
>> =20
>> 
>> =20
>> 
>> - Jay
>> =20
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Integer literals=20
>>> Date: Mon=2C 11 Jan 2010 21:46:03 -0800
>>> From: mika at async.async.caltech.edu
>>> =20
>>> Jay K writes:
>>>> 
>>>>>> One thing I've really struggled with over the introduction of LONGINT=
>> is
>>>>>> the need for distinct literal forms. This strikes me as odd=3D2C sinc=
>> e
>>>>>> literals are really just ways of writing values=3D2C rather than stat=
>> ing
>>>>>> anything about how they should be represented.
>>>>>> (Yes=3D2C I know that the REAL/LONGREAL/EXTENDED literals are all dis=
>> tinct=3D
>>>> =3D2C
>>>>>> but they really do have incompatible value representations).
>>>>> 
>>>>> I agree=3D2C the need for distinctly typed literals is much greater fo=
>> r the
>>>>> floating types than the integer types=3D2C because they can't be viewe=
>> d
>>>>> as having overlapping value sets in any reasonable way.
>>>> 
>>>> =3D20
>>>> Huh? This seems to me to be directly opposite of the truth.
>>>> LONGREAL is a strict superset of REAL in what it can represent.
>>>> There is *complete* overlap.
>>>> Am I really mistaken here?
>>>> Floating point is indeed very wierd=3D2C but it isn't this wierd.
>>>> Right?
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>> =20
>>> Jay=2C I think if you have hardware that's strictly compliant with IEEE
>>> 754=2C you're right. Or at least there exists an interpretation of the
>>> values that have this property. I alluded earlier to the fact that
>>> Alpha represents single-precision by zeroing out the middle of the
>>> double-precision register (some of the mantissa and some of the exponent)=
>> .
>>> =20
>>> However I'm sure there are systems for which this is not true. Is=20
>>> Modula-3 forbidden from being ported to such machines?
>>> =20
>>> Mika
>> 		 	   		  =
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 10pt=3B
>> font-family:Verdana
>> }
>> --></style>
>> </head>
>> <body class=3D'hmmessage'>
>> When do you forsee any non-IEEE 754 floating point environments coming into=
>> existance?<BR>
>> &nbsp=3B<BR>
>> Or for that matter=2C simple efficient compatibility with all the C=2C C++=
>> =2C Java=2C Modula-3=2C JavaScript=2C etc.&nbsp=3Bcode in the world not bei=
>> ng a feature of all CPUs=2C at least ones that have any floating point supp=
>> ort? Or any software floating point library?<BR>
>> For that matter=2C probably Perl and Python=2C but I'd have to check.<BR>
>> Chances are high they only expose 64bit float and nothing else.<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> The precisions and magnitudes of 32bit float and 64bit double are *really o=
>> ld* and in no apparent danger of going away. I think over 25 years and coun=
>> ting (consider the "SANE" environment of the Macintosh in 1984 and the simi=
>> larly timed Apple 6502 package. I think Applesoft/Microsoft BASIC might hav=
>> e used a different format=2C but the processor had no floating point suppor=
>> t.) I think the only system with different formats is VAX. And Alpha suppor=
>> ts IEEE-754 and VAX. ?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> I know=2C I know "never say never"=2C but sometimes....?<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> Certainly there are also 80bit formats on x86 and 68K.<BR>
>> &nbsp=3BThough x86 is moving away from this&nbsp=3Bwith SSE/SSE2.<BR>
>> And I think 128bit formats on PowerPC.<BR>
>> And something beyond 64bits on IA64 (Itanium).<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B<BR>
>> &nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B CC:=
>> m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] Integer literals <B=
>> R>&gt=3B Date: Mon=2C 11 Jan 2010 21:46:03 -0800<BR>&gt=3B From: mika at async=
>> .async.caltech.edu<BR>&gt=3B <BR>&gt=3B Jay K writes:<BR>&gt=3B &gt=3B<BR>&=
>> gt=3B &gt=3B&gt=3B&gt=3B One thing I've really struggled with over the intr=
>> oduction of LONGINT is<BR>&gt=3B &gt=3B&gt=3B&gt=3B the need for distinct l=
>> iteral forms. This strikes me as odd=3D2C since<BR>&gt=3B &gt=3B&gt=3B&gt=
>> =3B literals are really just ways of writing values=3D2C rather than statin=
>> g<BR>&gt=3B &gt=3B&gt=3B&gt=3B anything about how they should be represente=
>> d.<BR>&gt=3B &gt=3B&gt=3B&gt=3B (Yes=3D2C I know that the REAL/LONGREAL/EXT=
>> ENDED literals are all distinct=3D<BR>&gt=3B &gt=3B=3D2C<BR>&gt=3B &gt=3B&g=
>> t=3B&gt=3B but they really do have incompatible value representations).<BR>=
>> &gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B I agree=3D2C the need for distin=
>> ctly typed literals is much greater for the<BR>&gt=3B &gt=3B&gt=3B floating=
>> types than the integer types=3D2C because they can't be viewed<BR>&gt=3B &=
>> gt=3B&gt=3B as having overlapping value sets in any reasonable way.<BR>&gt=
>> =3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3BHuh? This seems to me to b=
>> e directly opposite of the truth.<BR>&gt=3B &gt=3BLONGREAL is a strict supe=
>> rset of REAL in what it can represent.<BR>&gt=3B &gt=3BThere is *complete* =
>> overlap.<BR>&gt=3B &gt=3BAm I really mistaken here?<BR>&gt=3B &gt=3BFloatin=
>> g point is indeed very wierd=3D2C but it isn't this wierd.<BR>&gt=3B &gt=3B=
>> Right?<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B - Jay<B=
>> R>&gt=3B <BR>&gt=3B Jay=2C I think if you have hardware that's strictly com=
>> pliant with IEEE<BR>&gt=3B 754=2C you're right. Or at least there exists an=
>> interpretation of the<BR>&gt=3B values that have this property. I alluded =
>> earlier to the fact that<BR>&gt=3B Alpha represents single-precision by zer=
>> oing out the middle of the<BR>&gt=3B double-precision register (some of the=
>> mantissa and some of the exponent).<BR>&gt=3B <BR>&gt=3B However I'm sure =
>> there are systems for which this is not true. Is <BR>&gt=3B Modula-3 forbid=
>> den from being ported to such machines?<BR>&gt=3B <BR>&gt=3B Mika<BR> 		 	 =
>> 		  </body>
>> </html>=
>> 
>> --_d6e9c415-767b-4d0a-bb6d-678d1cf506d1_--

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

From hosking at cs.purdue.edu  Tue Jan 12 19:33:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 13:33:59 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
Message-ID: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>

On 11 Jan 2010, at 23:55, Jay K wrote:

> I thought FloatMode was only related to floating point.
> So I looked:
>  
>    "IntOverflow" = an integer operation produced a result whose
>    absolute value is too large to be represented.
>  
>    "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
> 
>  
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>  
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?

Yes, that's the issue.

>  For the floating point stuff:
>  
> Probably like other per-platform code, this should be done in #ifdefed C.

Agreed...  does that mean you will bite?  ;-)

>  
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>  
>  - Jay
> 

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

From hendrik at topoi.pooq.com  Tue Jan 12 19:55:21 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 13:55:21 -0500
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <20100112185520.GA21429@topoi.pooq.com>

On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
> On 11 Jan 2010, at 23:55, Jay K wrote:
> >  
> > Probably like other per-platform code, this should be done in #ifdefed C.
> 
> Agreed...  does that mean you will bite?  ;-)

I seem to remember an ad for Modula 3 once that went something like
 <big number> lines of code, and not a single ifdef!

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 19:59:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 18:59:24 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
Message-ID: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>


Maybe. But I don't want to prevent anyone else from stepping in.
And I want to bring up more platforms.
My integer implementation might be inefficient.
 
 
I see these as three or possibly more separate areas.
 Integer overflow. 
 Integer divide by zero. 
 Floating point. 
 
 
Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms is probably already "not silent", so not bad.
 
 
I'm not sure about unsigned/Word.T overflow, how that is supposed to be handled. In particular, signed overflow and unsigned overflow are slightly different, and unsigned/Word possibly suggests allowing silent overflow.
 
Again I really see quite a number of options here and programmer should indicate intent via choice of type or interface/function.
Fixed width, trap overflow, silent overflow, extent precision on overflow, etc.
 
 
I was talking to a friend about the integer/longint stuff.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 13:33:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
>
>
> On 11 Jan 2010, at 23:55, Jay K wrote:
>
> I thought FloatMode was only related to floating point.
> So I looked:
>
> "IntOverflow" = an integer operation produced a result whose
> absolute value is too large to be represented.
>
> "IntDivByZero" = integer "DIV" or "MOD" by zero.
> \end{quote}
>
>
> This part of it should be easy to implement for all architectures.
> The entire thing probably isn't too difficult either on many platforms either.
>
> However...I was surprised by this.
> I thought the real "intent" in Modula-3 to not have this be configurable
> and endeavor for overflow and divide by zero to always immediately
> raise an exception? The only "out" is that it might not get implemented on some platforms for some reason?
>
> Yes, that's the issue.
>
> For the floating point stuff:
>
> Probably like other per-platform code, this should be done in #ifdefed C.
>
> Agreed... does that mean you will bite? ;-)
>
>
> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
> etc.
>
> - Jay
>
> 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:02:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:02:49 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <20100112185520.GA21429@topoi.pooq.com>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>,
	<20100112185520.GA21429@topoi.pooq.com>
Message-ID: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>


That's *really* *not* a good thing.
 
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 13:55:21 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] FloatMode
>
> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>
>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>
>> Agreed... does that mean you will bite? ;-)
>
> I seem to remember an ad for Modula 3 once that went something like
> lines of code, and not a single ifdef!
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Tue Jan 12 20:13:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:13:25 +0000
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
References: <420956.32527.qm@web23605.mail.ird.yahoo.com>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>, ,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>, ,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>, ,
	<20100112185520.GA21429@topoi.pooq.com>,
	<COL101-W39425A69E673622AFCF7DAE66C0@phx.gbl>
Message-ID: <COL101-W200C77A1ABE9F1CAA90BCE66C0@phx.gbl>


Instead of the small evil of #ifdefs, we had two large evils:
 
 
 - cloning headers, fragile, tedious, error-prone 
   Though I think generally safe, *if* done *extremely* *carefully* and *correctly*. There is a need for the underlying system to not change. The commercial systems all do that well. 64bit FreeBSD seems to have a poor record at least. NetBSD changes the symbol names maybe often. etc.
 
 
 - cloning nearly identical Modula-3 code many times

 
The second could have been reduced, by making directories keyed by processor 
architecture or kernel, instead of architecture_kernel pairs.
 
 
The first could have been reduced a lot by limiting it to only what we use.
That was what I did at first with Cygwin.
But still.
 
 
By using #ifdefs we have gained a lot of portability and thrown away many lines of code.
 
 
A C generating backend will increase portability another very big step.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 19:02:49 +0000
> Subject: Re: [M3devel] FloatMode
>
>
> That's *really* *not* a good thing.
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 12 Jan 2010 13:55:21 -0500
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>> On Tue, Jan 12, 2010 at 01:33:59PM -0500, Tony Hosking wrote:
>>> On 11 Jan 2010, at 23:55, Jay K wrote:
>>>>
>>>> Probably like other per-platform code, this should be done in #ifdefed C.
>>>
>>> Agreed... does that mean you will bite? ;-)
>>
>> I seem to remember an ad for Modula 3 once that went something like
>> lines of code, and not a single ifdef!
>>
>> -- hendrik 		 	   		  

From hosking at cs.purdue.edu  Tue Jan 12 20:21:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:21:14 -0500
Subject: [M3devel] the LONGINT proposal
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>

On 11 Jan 2010, at 23:09, Randy Coleburn wrote:

> Tony:
>  
> I?m sorry, I missed the fact that you changed the type to ?Integer? vs. ?INTEGER? and defined ?Integer? to be ?INTEGER? or ?LONGINT?.
>  
> I agree that with your changes everything is in order now, even though I would prefer different names.  Nevertheless, I can be ?happy? with this state of affairs.
>  
> I am confused though by your last set of statements, namely:
>  
> >I don't think we need to do this, assuming you understand what I have said above.
> > 
> >ORD(x: INTEGER): LONGINT
> >ORD(x: LONGINT): INTEGER
> >ORD(x: Enumeration): INTEGER
> >ORD(x: Subrange): Base(Subrange)
> > 
> >ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> Didn?t you mean:
>                 ORD(x:INTEGER): INTEGER
>                 ORD(x:LONGINT): LONGINT

Sorry, yes.   Cut/paste error.

>  Also, in case anyone is interested, the current HEAD fails to compile the following packages on Windows Vista:
> "m3-libs\m3core"
> "m3-libs\libm3"
> "m3-tools\m3tk"
> So some recent changes have caused a problem.

Did you bootstrap a new compiler?  You will need to bootstrap a compiler before you can compile the revised ORD/VAL definitions.

>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 10:40 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> On 11 Jan 2010, at 22:11, Randy Coleburn wrote:
> 
> 
> Tony et al:
>  
> Yes, I think I am supporting the ?status quo?, which seems to be Rodney?s proposal, minus mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as you state.  (See discussion below to the end for more on this ?discomfort? and the problem I see with converting from LONGINT to INTEGER.)
>  
> When I said we don?t know the range of LONGINT, I meant that in the context of documenting the language we weren?t specifying this range; rather it is implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT) and LAST(LONGINT) at runtime to determine the actual range.
>  
> Tony you stated in your response that the 2nd parameter (the type) of VAL is optional.  I was not aware that this parameter can be defaulted.  Where is this stated in the language spec?
>  
> Sorry, my error.  I realised after writing that I had mis-spoken.
> 
> 
>  I?ve only scanned your HTML reference briefly, but it seems to me that even there it still says that ORD/VAL convert between enumerations and INTEGERs, not LONGINTs.
>  
> That wording is exactly the same as it has always been.  Here is the diff from the original specification (before LONGINT):
>  
> 55,56c55,56
> <               ORD  (element: Ordinal): INTEGER
> <               VAL  (i: INTEGER; T: OrdinalType): T
> ---
> >               ORD  (element: Ordinal): Integer
> >               VAL  (i: Integer; T: OrdinalType): T
> 74c74
> < If n is an integer, ORD(n) = VAL(n, INTEGER) = n.
> ---
> > If n is an integer of type T, ORD(n) = VAL(n, T) = n.
>  
> Notice that all that I have changed is to allow ORD to return INTEGER or LONGINT, depending on the type of the element.  And VAL simply takes an INTEGER or LONGINT and converts to an Ordinal type T.
> 
> 
>  Are we going to allow LONGINT to be an enumeration?  If so, then why not go full bore and just make INTEGER a subrange of LONGINT?  (I don?t favor this.)
>  
> No, enumerations map only onto INTEGER.
> 
> 
> Alternately, if you want to use ORD/VAL for the LONGINT conversions, could we at least change 2.2.1 to say that ORD/VAL convert between ordinal types, since enumerations are defined as an ordinal type and LONGINT falls into the category of an ordinal type, but not an enumeration type?  Indeed, the syntax definition of ORD/VAL seem to bear out this fact even though the text references ?enumerations? (see 4th major paragraph in 2.2.1, ?The operators ORD and VAL convert between ??).
>  
> I don't want to make wholesale changes to the reference that were not there in the first place.  ORD applied to and INTEGER has always been the identity operation.
> 
> 
>  The syntax of ORD/VAL is:
> ORD  (element: Ordinal): Integer
> VAL  (i: Integer; T: OrdinalType): T
> and, if n is a integer of type T, ORD(n) = VAL(n, T) = n.
>  
> BTW:  I think the above identity should say that n is a non-negative integer!
>  
> Huh?  No, that is not the case.  It is only non-negative for enumerations which count from 0.
> 
> 
>  So, using these, you propose one would write
>                 longInt := VAL(int, LONGINT);
>                 int := ORD(longInt)
>  
> No,
>  
> longint := VAL(integer, LONGINT)
> integer := VAL(longint, INTEGER)
> int := ORD(int)
> longint := ORD(longint)
> 
> 
> then, the identity doesn?t exactly match up unless you allow ORD(longInt) to return a LONGINT, but then if you do that the signature of ORD must be dependent on its argument type (either INTEGER or LONGINT; note that enumerations and INTEGER subranges also yield type INTEGER). 
>  
> This captures the identities precisely, which is why I reverted to the original formulation.
> 
> 
> Therefore, in the case of argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS type must be INTEGER when the argument is INTEGER, unless you allow checked assignability, in which case why do you need ORD in the first place?
>  
> IMO, ORD/VAL make more sense in the case of enumerations.  For example:
>                 Color = (Red, Blue, Green);
>                 ORD(Color.Blue) = 1
>                 VAL(1, Color) = Color.Blue
> (Note that the identity doesn?t apply here since n isn?t an integer when applied to ORD, or to the result of VAL.)
>  
> Yes, of course, ORD/VAL are there to allow mapping of enumerations to INTEGER.  But, for general consistency any integer can have ORD applied to it, and any integer can be mapped to its own type.
> 
> 
>  I think I saw later in one of the commit messages or replies to Jay that you propose to drop use of ORD with LONGINT and just use VAL, as in:
>                 longInt := VAL(int, LONGINT);
>                 int := VAL(longInt, INTEGER);
>  
> That is what is now implemented.
> 
> 
> but the second form would violate the signature of VAL, which requires an INTEGER as the first argument.
>  
> No, notice that VAL takes an Integer which can be INTEGER or LONGINT typed.
> 
> 
>  I guess my heartburn with using ORD/VAL for LONGINT conversions stems from fact that before LONGINT, enumerations, subranges, and INTEGER all had the same maximum range and NELSON states that ORD/VAL are for conversions between enumerations (aka ordinals) and integers.  Note that NELSON uses lowercase ?integers? (should really be ?non-negative integers?) so I guess this could mean all non-negative integers, whether representable as INTEGER or LONGINT, but then there was no LONGINT when NELSON?s book came out.  Also, before LONGINT, ORD could not cause a checked runtime error.
>  
> ORD now can never cause a checked runtime error, just as with Nelson.
> 
> 
>  So, at this point, to summarize, I think you are advocating:
> 1.      Distinct types INTEGER and LONGINT.
> 2.      LONGINT is an ordinal type, but cannot be used as the index type for an array.
> 3.      Enumerations are still constrained to no more than NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).
> 4.      No mixed arithmetic between INTEGER and LONGINT; require explicit conversions.
> 5.      No mixed comparisons between INTEGER and LONGINT; require explicit conversions.
> 6.      Allow VAL to convert INTEGER to LONGINT.
>  
> Am I correct so far?
>  
> Yes, correct.  This is what is now implemented in the CVS head.
> 
> 
>  Now, what to do about converting from LONGINT to INTEGER?
> a.      Originally, ORD was proposed along with use of a checked runtime error if the value of the LONGINT didn?t fit into an INTEGER.  But, then the result type signature of ORD (i.e., INTEGER) doesn?t preserve the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you would have to make the result type of ORD dependent on the parameter type passed to ORD.
>  
> See above.
> 
> 
> b.      Provide an overloaded form of VAL with a different signature that allows for int := VAL(longInt, INTEGER).  I think this is somewhat confusing in terms of the original definition of VAL as an inverse of ORD.
>  
> See above.
>  
> c.       Allow for checked assignability, e.g., int := longInt; but then this to me starts us on the slippery slope where one eventually argues for mixed arithmetic.
>  
> No assignability!
> 
> 
> d.      Come up with differently named operators (different from ORD/VAL).  These would have the benefit of requiring only one parameter, whereas VAL requires two, and would prevent any confusion with the defined use of ORD/VAL as conversion inverses for enumerations and integers.  This is my preferred option.
>  
> I don't think we need to do this, assuming you understand what I have said above.
>  
> ORD(x: INTEGER): LONGINT
> ORD(x: LONGINT): INTEGER
> ORD(x: Enumeration): INTEGER
> ORD(x: Subrange): Base(Subrange)
>  
> ORD(n) = VAL(n, T) = n if n is an integer of type T = INTEGER or T = LONGINT.
>  
> e.      Any other ideas?
>  
> I think we are done...
> 
> 
>  
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, January 11, 2010 12:32 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Quick summary:
>  
> I agree, and you seem to be supporting the status quo (other than your discomfort with ORD/VAL) as defined at: http://www.cs.purdue.edu/homes/hosking/m3/reference/
>  
> On 11 Jan 2010, at 01:11, Randy Coleburn wrote:
> 
> 
> 
> Tony:
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> Agreed.
> 
> 
> 
>  
> 2.  I think checked assignability gets us onto the slippery slope (see below).  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Read on for the long-winded version?
>  
> According to NELSON (SPwM3), ORD and VAL convert between enumerations and INTEGERs, and INTEGER is all integers represented by the implementation.  So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and 64-bit processors. 
>  
> Today we see 32-bit and 64-bit processors as predominant, but I remember the day when 8-bit and 16-bit were the norm.  Someday we may see 128-bit processors as the norm. 
>  
> (I?ve been cleaning up my basement office and ran across a box of 8-inch floppy disks.  When I showed them to my daughter she understood the meaning of ?floppy? as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)
>  
> On a 64-bit processor, this whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits also.  But on a 16-bit machine (assuming we had an implementation for one) the native word size would be less than the 32-bits we seem to take for granted now.
>  
> One problem is that one doesn?t really know the range of LONGINT unless we define it as some number of bits.  Rodney?s proposal simply stated that LONGINT was at least as big as INTEGER but could be larger.  So, on a 64-bit machine, are LONGINT and INTEGER really the same in terms of implementation?, whereas on a 32-bit the LONGINT would have an additional 32-bits more than INTEGER?  What about a 128-bit machine?
>  
> What's wrong with using FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is currently implemented.
> On a 64-bit machine the types LONGINT and INTEGER are still distinct in the current implementation, so cannot be assigned, though they do happen to have the same underlying representation.
> 
> 
> 
>  I say all this to point out the obvious, namely that LONGINT and INTEGER are different types. 
>  
> Correct.  The current implementation treats them as completely separate.
> 
> 
> 
>  Therefore, IMO the language must make it clear how these different types interact.
>  
> I would argue that
>    x: LONGINT := 23;
> is wrong!  The programmer should have to write
>    x: LONGINT := 23L;
> instead.
>  
> This is what we currently implement.
> 
> 
> 
>  A subrange of LONGINT would be written as [23L..4200L] and would be a different type than the integer subrange [23..4200] even though the ranges are identical.
>  
> Also what we currently implement.
> 
> 
> 
>  Likewise, IMO mixed arithmetic with the compiler deciding what to do is wrong.  The programmer should have to explicitly write conversions to a common type for arithmetic.
>  
> I agree, and this is the current implementation.
> 
> 
> 
>  I have no problem with extending the existing operators to deal with LONGINT; it?s just that the result should be LONGINT.
> Given x: LONGINT := 49L;
>    INC(x) yields 50L
>    INC(x, 3L) yields 52L
>       note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a LONGINT
>    (x + 20L) yields 69L
>       note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a LONGINT
>    LAST(LONGINT) yields a LONGINT
>  
> This is exactly the current implementation.
> 
> 
> 
>  Now that I think about it more, I have a problem using ORD/VAL for the conversion since NELSON defines these as converting between enumerations and INTEGERs, and since LONGINT is a different type than INTEGER and quite possibly has a greater range than INTEGER.  Is the proposal to also allow enumerations to use the range of LONGINT ?  Enumerations currently are defined as having a range no greater than INTEGER.  To extend them to LONGINT would lose the obvious performance benefits of keeping them same range as native INTEGER.
>  
> I'm not sure that the current implementation conflicts with the definition of ORD/VAL.  What we currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to an INTEGER.  The optional type parameter of VAL can be LONGINT, which permits conversion of INTEGER to LONGINT.  I don't see how these conflict with the intention of ORD/VAL.  You can see the language spec for what is currently implemented at: http://www.cs.purdue.edu/~hosking/m3/reference/.
> 
> 
> 
>  Maybe we should invent new names for the conversions between INTEGER and LONGINT.  Perhaps PROMOTE and DEMOTE or some such.  These are probably bad names, but I use them below simply to illustrate (feel free to come up with better names):
>    Given longInt: LONGINT;   and   int: INTEGER;
>    int := DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would give a runtime range check error if longInt is too big/small to fit in an INTEGER.
>    longInt := PROMOTE(int) would always succeed in performing the conversion from INTEGER to LONGINT but would make the conversion explicit
>    int + DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in the range of INTEGER
>    longInt + PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the range of LONGINT
>  
> I think ORD/VAL suffice...
> 
> 
> 
>  Now if we were to allow checked assignability (as Tony is leaning toward), I think we begin to get on the slippery slope.  How far do we extend this to the point that it is not clear in the expression of the code what is happening?  If I can write ?int := longInt;? why not ?int := 23L;? and why not ?int := longInt + 57;? and is this different than ?int := longInt + 57L;?? etc. etc.
>  
> I agree the ORD/VAL syntax is ugly, so that is another reason (besides them applying to enumerations only) we should use different names for the INTEGER/LONGINT conversions.
>  
> Sorry, I have been too long-winded here.  To answer your questions succinctly: 
>  
> 1.  I can relax on the requirement for overflow checking, but programmers should never count on it silently wrapping around.
>  
> 2.  I think checked assignability gets us onto the slippery slope.  Using differently named conversion operators would lesson some of the ugliness of ORD/VAL and also prevent confusion with their intended use as enumeration/INTEGER conversions.
>  
> Regards,
> Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Sunday, January 10, 2010 3:43 PM
> To: Randy Coleburn
> Cc: m3devel
> Subject: Re: [M3devel] the LONGINT proposal
>  
> Hi Randy,
>  
> As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.
>  
> I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:
>  
> x: INTEGER := ORD(longint, INTEGER);
>  
> seems unnecessary when they could just write
>  
> x: INTEGER := longint;
>  
> This is similar in spirit to:
>  
> x: [lo..hi] := integer;
>  
>  
> On 10 Jan 2010, at 15:00, Randy Coleburn wrote:
> 
> 
> 
> 
> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn
>  
>  
>  

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

From mika at async.async.caltech.edu  Tue Jan 12 20:28:07 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:28:07 -0800
Subject: [M3devel] FloatMode
In-Reply-To: <COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl> 
References: <COL101-W463D7E63B71B77BE9495F9E66C0@phx.gbl>, ,
	<420956.32527.qm@web23605.mail.ird.yahoo.com>,
	<COL101-W254342E6BFF96BDCA4BA85E66C0@phx.gbl>, ,
	<770FAFA3-9F41-48F4-A2E0-D4CD947EE6D2@cs.purdue.edu>,
	<COL101-W2811B60F7CC05B79BCCD26E66C0@phx.gbl>,
	<B9361FC8-0944-4FBF-A378-18A98C7A0F54@cs.purdue.edu>
	<COL101-W560A47192DDD1A715D1A5BE66C0@phx.gbl>
Message-ID: <20100112192807.055FC1A2079@async.async.caltech.edu>

Jay K writes:
>
>Maybe. But I don't want to prevent anyone else from stepping in.
>And I want to bring up more platforms.
>My integer implementation might be inefficient.
>=20
>=20
>I see these as three or possibly more separate areas.
> Integer overflow.=20
> Integer divide by zero.=20
> Floating point.=20
>=20
>=20
>Divide by zero in particular on NT/x86 and maybe other x86/AMD64 platforms =
>is probably already "not silent"=2C so not bad.
>=20
>=20
>I'm not sure about unsigned/Word.T overflow=2C how that is supposed to be h=
>andled. In particular=2C signed overflow and unsigned overflow are slightly=
> different=2C and unsigned/Word possibly suggests allowing silent overflow.

Word.T never overflows.  Tons of code depends on this!

Also a lot of machines don't have integer flags, don't forget that.  (Alpha
and MIPS come to mind, although MIPS has an "add-with-exception" instruction.)

     Mika

>=20
>Again I really see quite a number of options here and programmer should ind=
>icate intent via choice of type or interface/function.
>Fixed width=2C trap overflow=2C silent overflow=2C extent precision on over=
>flow=2C etc.
>=20
>=20
>I was talking to a friend about the integer/longint stuff.
>=20
>=20
> - Jay
>
>
>________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 13:33:59 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] FloatMode
>>
>>
>>
>> On 11 Jan 2010=2C at 23:55=2C Jay K wrote:
>>
>> I thought FloatMode was only related to floating point.
>> So I looked:
>>
>> "IntOverflow" =3D an integer operation produced a result whose
>> absolute value is too large to be represented.
>>
>> "IntDivByZero" =3D integer "DIV" or "MOD" by zero.
>> \end{quote}
>>
>>
>> This part of it should be easy to implement for all architectures.
>> The entire thing probably isn't too difficult either on many platforms ei=
>ther.
>>
>> However...I was surprised by this.
>> I thought the real "intent" in Modula-3 to not have this be configurable
>> and endeavor for overflow and divide by zero to always immediately
>> raise an exception? The only "out" is that it might not get implemented o=
>n some platforms for some reason?
>>
>> Yes=2C that's the issue.
>>
>> For the floating point stuff:
>>
>> Probably like other per-platform code=2C this should be done in #ifdefed =
>C.
>>
>> Agreed... does that mean you will bite? =3B-)
>>
>>
>> http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx
>> http://kernel.org/doc/man-pages/online/pages/man3/fetestexcept.3.html
>> etc.
>>
>> - Jay
>>
>> 		 	   		  =


From hosking at cs.purdue.edu  Tue Jan 12 20:30:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 14:30:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>
Message-ID: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>

On 12 Jan 2010, at 04:23, Jay K wrote:

> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.

That is going to pose a performance issue (that many C programmers may baulk at!).

> I propose that FloatMode's integer features not be the way forward.

Why not?

> There are two implementation strategies.
>  
>  
>  - "check the carry flag"
>    A processor-specific thing, but possibly something easy for the gcc backend to do.
>    And very likely easy for the integrated backend.
>    Probably very efficient.

Yes, doable.

>   - internally generate function calls for every arithmetic operation
>    like how sets are implemented

Very bad for performance.  We should rely on the processor support for arithmetic traps or condition variables.


>   Implementing most such functions is easy enough in portable C.
>  Or maybe using Modula-3 and interface Word.

Not the best way going forward...

>   e.g.
>    void add(int a, int b, int* c, int* overflow)
>    {
>     int d = (a + b);
>     /* overflow if input signs are equal and output sign is different;
>         if input signs are unequal, overflow is not possible
>         positive + positive: expect positive, else overflow
>         negative + negative: expect negative, else overflow
>         positive + negative: overflow not possible */
>     *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
>  
>    void sub(int a, int b, int* c, int* overflow)
>    {
>     int d = (a - b);
>     /* overflow if input signs are unequal and output sign is different than first input;
>         if input signs are equal, overflow is not possible;
>         positive - negative: expect positive, overflow if negative
>         negative - positive: expect negative, overflow if positive
>         positive - positive, negative - negative: overflow not possible */
>     *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>     *c = d;
>   }
>  
> #include <limits.h>
>  
>   void mult(int a, int b, int* c, int* overflow)
>   {
>     /* do operation in higher precision and check if it fits */
>     int64 d = (a * (int64)b);
>     *c = (int)d;
>     *overflow = (d >= INT_MIN && d <= INT_MAX);
>   }
>  
> /* for interface Word */
>   typedef unsigned uint;
>  
>   void addu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a + b);
>     /* overflow if output less than either input */
>     *overflow = (d < a);
>     *c = d;
>  }
>  
>   void subu(uint a, uint b, uint* c, int* overflow)
>   {
>      uint d = (a - b);
>     /* overflow if output greater than first input */
>     *overflow = (d > a);
>     *c = d;
>  }
>  
>   void multu(uint a, uint b, uint* c, int* overflow)
>   {
>     /* operate at higher precision and see if it fits */
>      uint64 d = (a * (uint64)b);
>     *overflow = (d <= UINT_MAX);
>     *c = (uint)d;
>  }
>  
>  void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>  {
>   /* break it down into smaller operations, not shown, but not difficult */
>  }
>  
>  
> Yes I know this is inefficient, but such is a possible price of portable safety.
>  
>  
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.

FloatMode seems a perfectly reasonable way forward doesn't it?  It allows both trap-based and (with compiler support) checked condition code implementations.

>  
>   
>  - Jay
> 
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Tue Jan 12 20:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 19:46:21 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
Message-ID: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>


I'm not against using "hardware traps", if they exist.
I'll have to do a bunch of research as to their existance.
 
 
 
I don't think one should be able to turn this on or off.
I think it should be static per type or interface/library.
 
 
Even so, if it is a runtime configuration, I realize
that the implementation, on a system
without hardware traps, with a processor-specific
flag would look *like*:
 
 
 check for overflow 
 if no overflow, continue on as usual
 if overflow, call out to a function
   that function:
      fetch the thread local
      depending on *that*, raise an exception or continue on 
 
 
I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
 
 
Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
 
 
That can also be highly portable, mimicing the algorithms I showed.
 
 
The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
 
 
- Jay



________________________________
> Subject: Re: [M3devel] integer overflow
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 14:30:00 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>
>
> On 12 Jan 2010, at 04:23, Jay K wrote:
>
> I propose that integer signed overflow always raise an immediate exception.
> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>
> That is going to pose a performance issue (that many C programmers may baulk at!).
>
> I propose that FloatMode's integer features not be the way forward.
>
> Why not?
>
> There are two implementation strategies.
>
>
> - "check the carry flag"
> A processor-specific thing, but possibly something easy for the gcc backend to do.
> And very likely easy for the integrated backend.
> Probably very efficient.
>
> Yes, doable.
>
> - internally generate function calls for every arithmetic operation
> like how sets are implemented
>
> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>
>
> Implementing most such functions is easy enough in portable C.
> Or maybe using Modula-3 and interface Word.
>
> Not the best way going forward...
>
> e.g.
> void add(int a, int b, int* c, int* overflow)
> {
> int d = (a + b);
> /* overflow if input signs are equal and output sign is different;
> if input signs are unequal, overflow is not possible
> positive + positive: expect positive, else overflow
> negative + negative: expect negative, else overflow
> positive + negative: overflow not possible */
> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
>
> void sub(int a, int b, int* c, int* overflow)
> {
> int d = (a - b);
> /* overflow if input signs are unequal and output sign is different than first input;
> if input signs are equal, overflow is not possible;
> positive - negative: expect positive, overflow if negative
> negative - positive: expect negative, overflow if positive
> positive - positive, negative - negative: overflow not possible */
> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
> *c = d;
> }
>
> #include
>
> void mult(int a, int b, int* c, int* overflow)
> {
> /* do operation in higher precision and check if it fits */
> int64 d = (a * (int64)b);
> *c = (int)d;
> *overflow = (d>= INT_MIN && d <= INT_MAX);
> }
>
> /* for interface Word */
> typedef unsigned uint;
>
> void addu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a + b);
> /* overflow if output less than either input */
> *overflow = (d < a);
> *c = d;
> }
>
> void subu(uint a, uint b, uint* c, int* overflow)
> {
> uint d = (a - b);
> /* overflow if output greater than first input */
> *overflow = (d> a);
> *c = d;
> }
>
> void multu(uint a, uint b, uint* c, int* overflow)
> {
> /* operate at higher precision and see if it fits */
> uint64 d = (a * (uint64)b);
> *overflow = (d <= UINT_MAX);
> *c = (uint)d;
> }
>
> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
> {
> /* break it down into smaller operations, not shown, but not difficult */
> }
>
>
> Yes I know this is inefficient, but such is a possible price of portable safety.
>
>
> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>
> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 20:57:52 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 11:57:52 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <20100112195752.22AC21A2079@async.async.caltech.edu>


Are you actually proposing making range checking mandatory for integer
arithmetic?

I think that's a bad idea... the performance hit could be very high
(especially on some architectures).

The language should already guarantee that problems in this area can't
cause unchecked runtime errors.

     Mika

Jay K writes:
>
>I'm not against using "hardware traps"=2C if they exist.
>I'll have to do a bunch of research as to their existance.
>=20
>=20
>=20
>I don't think one should be able to turn this on or off.
>I think it should be static per type or interface/library.
>=20
>=20
>Even so=2C if it is a runtime configuration=2C I realize
>that the implementation=2C on a system
>without hardware traps=2C with a processor-specific
>flag would look *like*:
>=20
>=20
> check for overflow=20
> if no overflow=2C continue on as usual
> if overflow=2C call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*=2C raise an exception or continue on=20
>=20
>=20
>I suspect I could easily quickly put in place a portable implementation=2C =
>and..like *almost* everything else that isn't I/O bound (other than code si=
>ze issue).
>=20
>=20
>Hm. Actually another very good approach is probably to have the front end i=
>nline most of this logic=2C like everything except 64bit multiplication on =
>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>ly probably competitive. There is already inlining of the computation of th=
>e result=2C and merely passing three parameters won't be cheap.
>=20
>=20
>That can also be highly portable=2C mimicing the algorithms I showed.
>=20
>=20
>The front end can also do the optimization where overflow isn't necessarily=
> checked for every single operation.
>=20
>=20
>- Jay
>
>
>
>________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>>
>>
>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>
>> I propose that integer signed overflow always raise an immediate exceptio=
>n.
>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
> no exceptions at all.
>> For folks that want silent wraparound=2C maybe a separate interface like =
>UnsafeInt.
>>
>> That is going to pose a performance issue (that many C programmers may ba=
>ulk at!).
>>
>> I propose that FloatMode's integer features not be the way forward.
>>
>> Why not?
>>
>> There are two implementation strategies.
>>
>>
>> - "check the carry flag"
>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>kend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>>
>> Yes=2C doable.
>>
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>>
>> Very bad for performance. We should rely on the processor support for ari=
>thmetic traps or condition variables.
>>
>>
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>>
>> Not the best way going forward...
>>
>> e.g.
>> void add(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a + b)=3B
>> /* overflow if input signs are equal and output sign is different=3B
>> if input signs are unequal=2C overflow is not possible
>> positive + positive: expect positive=2C else overflow
>> negative + negative: expect negative=2C else overflow
>> positive + negative: overflow not possible */
>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>>
>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> int d =3D (a - b)=3B
>> /* overflow if input signs are unequal and output sign is different than =
>first input=3B
>> if input signs are equal=2C overflow is not possible=3B
>> positive - negative: expect positive=2C overflow if negative
>> negative - positive: expect negative=2C overflow if positive
>> positive - positive=2C negative - negative: overflow not possible */
>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>> *c =3D d=3B
>> }
>>
>> #include
>>
>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d =3D (a * (int64)b)=3B
>> *c =3D (int)d=3B
>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>> }
>>
>> /* for interface Word */
>> typedef unsigned uint=3B
>>
>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a + b)=3B
>> /* overflow if output less than either input */
>> *overflow =3D (d < a)=3B
>> *c =3D d=3B
>> }
>>
>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> uint d =3D (a - b)=3B
>> /* overflow if output greater than first input */
>> *overflow =3D (d> a)=3B
>> *c =3D d=3B
>> }
>>
>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d =3D (a * (uint64)b)=3B
>> *overflow =3D (d <=3D UINT_MAX)=3B
>> *c =3D (uint)d=3B
>> }
>>
>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>> {
>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>t */
>> }
>>
>>
>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>e safety.
>>
>>
>> A hybrid is probably possible if the gcc backend support must be processo=
>r specific and we gradually provide the implementations.
>>
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>both trap-based and (with compiler support) checked condition code implemen=
>tations.
>>
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>> 		 	   		  =


From jay.krell at cornell.edu  Tue Jan 12 21:21:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:21:27 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>


Range checking and overflow checking I think are different.
 
 
TYPE T1 = [1..6];
a:T1 := 7; (* range check error *)
b:T1 := 6;
c:T1 := 1;
d:T1 := b + c; (* range check error *)
e:T1 := c - b; (* range check error *)
f:ARRAY [1..4] OF INTEGER;
f[b] := 0; (* range check error *)
g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
 
 
But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
 
 
Initially it'll probably be a command line option or such.
 
 
Or maybe it isn't a safety issue?
As long as one has checks on array indexing? Which I'm sure we do.
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 12 Jan 2010 11:57:52 -0800
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
>
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
>
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).
>
> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.
>
> Mika
>
> Jay K writes:
>>
>>I'm not against using "hardware traps"=2C if they exist.
>>I'll have to do a bunch of research as to their existance.
>>=20
>>=20
>>=20
>>I don't think one should be able to turn this on or off.
>>I think it should be static per type or interface/library.
>>=20
>>=20
>>Even so=2C if it is a runtime configuration=2C I realize
>>that the implementation=2C on a system
>>without hardware traps=2C with a processor-specific
>>flag would look *like*:
>>=20
>>=20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*=2C raise an exception or continue on=20
>>=20
>>=20
>>I suspect I could easily quickly put in place a portable implementation=2C =
>>and..like *almost* everything else that isn't I/O bound (other than code si=
>>ze issue).
>>=20
>>=20
>>Hm. Actually another very good approach is probably to have the front end i=
>>nline most of this logic=2C like everything except 64bit multiplication on =
>>32bit platform. At first I though that'd be too bloating=2C but it's actual=
>>ly probably competitive. There is already inlining of the computation of th=
>>e result=2C and merely passing three parameters won't be cheap.
>>=20
>>=20
>>That can also be highly portable=2C mimicing the algorithms I showed.
>>=20
>>=20
>>The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>>=20
>>=20
>>- Jay
>>
>>
>>
>>________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exceptio=
>>n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>>UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may ba=
>>ulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>>kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes=2C doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for ari=
>>thmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>>
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>>first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>>
>>> #include
>>>
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>>
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>>
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>>
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>>t */
>>> }
>>>
>>>
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>>e safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processo=
>>r specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>>both trap-based and (with compiler support) checked condition code implemen=
>>tations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Tue Jan 12 21:27:06 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 12 Jan 2010 12:27:06 -0800
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl> 
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112202706.C98571A2079@async.async.caltech.edu>

Jay K writes:
>
>Range checking and overflow checking I think are different.
>=20
>=20
>TYPE T1 =3D [1..6]=3B
>a:T1 :=3D 7=3B (* range check error *)
>b:T1 :=3D 6=3B
>c:T1 :=3D 1=3B
>d:T1 :=3D b + c=3B (* range check error *)
>e:T1 :=3D c - b=3B (* range check error *)
>f:ARRAY [1..4] OF INTEGER=3B
>f[b] :=3D 0=3B (* range check error *)
>g:INTEGER :=3D LAST(INTEGER) - 5 + a=3B (* overflow *)
>=20
>=20
>But anyway=2C yes it will be slower=2C but I believe it should be mandatory=
>=2C at least in safe modules=2C it is needed for safety=2C and I doubt it'l=
>l be *noticably* slower for the vast majority of code.
>=20
>=20
>Initially it'll probably be a command line option or such.
>=20
>=20
>Or maybe it isn't a safety issue?
>As long as one has checks on array indexing? Which I'm sure we do.

That was my point.  It shouldn't be a safety issue.  It's orthogonal to the
Modula-3 definition of UNSAFE.

    Mika



From michael.anderson at elego.de  Tue Jan 12 21:35:55 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Tue, 12 Jan 2010 21:35:55 +0100
Subject: [M3devel] Fwd: CM3 development Inquiry.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100110164332.0c09a257.dimonax@att.net>
	<5A44E4F2-AF0C-4241-BD11-4A8B0912A022@cs.purdue.edu>
	<20100111115257.d437knapzgocgc0g@mail.elegosoft.com>
	<9997AE9B-BB65-4B2E-9528-D002583C8B97@cs.purdue.edu>
	<4B4BFE06.5010400@polstra.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD11@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100112213555.v7disk2h44kkcos8@mail.elego.de>

Hi All,

att.net has responded and promised to have us off of their blacklist  
within 48 hours.
I'll inform Chris from another mail server.

Mike

Quoting Randy Coleburn <rcolebur at SCIRES.COM>:

> I also took the liberty of contacting him.  Shown below is my   
> message and his response:
> Regards,
> Randy
>
> On Mon, 11 Jan 2010 12:19:26 -0500
> Randy Coleburn <rcolebur at SCIRES.COM> wrote:
>
>> Just want to let you know that the folks hosting the mail list   
>> service are trying to fulfill your request to be added to the   
>> m3devel mail list.
>>
>> The problem seems to be blacklisting of one of the hosts.  At first  
>>  it seemed your email address was blacklisted, but upon further   
>> investigation it seems your email server   
>> (scc-mailrelay.att.net<http://scc-mailrelay.att.net>) has   
>> blacklisted the mail list server at elegosoft.  Note that the   
>> elegosoft server is based in Germany.
>>
>> The server admins are working on the problem, but not sure if/when   
>> it will be resolved.
>>
>> I'm one of the developers and also subscribe to the list and   
>> noticed the traffic about your request, so thought I would try and   
>> send you an email to see if it gets thru and to let you know of the  
>>  problem.
>>
>> Regards,
>> Randy
>>
>
> Thanks for the heads up. I'll give them a call to see what the problem is.
>
> AT&T actually does it's mail hosting through Yahoo mail, so they   
> might actually be the ones doing the blacklisting. I'm going to do   
> some poking around on this end; and I'll send you an email if I find  
>  anything noteworthy.
>
> Thank you.
>
> --
> Chris <dimonax at att.net>
>
>
> -----Original Message-----
> From: John Polstra [mailto:jdp at polstra.com]
> Sent: Monday, January 11, 2010 11:44 PM
> To: Tony Hosking
> Cc: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: CM3 development Inquiry.
>
> I forwarded this to him, and my mail log says it was delivered.
>
> John
>
> Tony Hosking wrote:
>> Actually, that diagnostic indicates that scc-mailrelay.att.net
>> <http://scc-mailrelay.att.net> is blocking messages from the Elegosoft
>> mail server (it is blacklisted!).
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 11 Jan 2010, at 05:52, Olaf Wagner wrote:
>>
>>> Quoting Tony Hosking <hosking at cs.purdue.edu
>>> <mailto:hosking at cs.purdue.edu>>:
>>>
>>>> This guy is trying to subscribe to m3devel.  Can someone help him?
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Chris <dimonax at att.net <mailto:dimonax at att.net>>
>>>>> Date: 10 January 2010 16:43:32 EST
>>>>> To: Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> Subject: Re: CM3 development Inquiry.
>>>>>
>>>>> On Fri, 8 Jan 2010 13:01:21 -0500
>>>>> Tony Hosking <hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>>
>>>>> wrote:
>>>>>
>>>>>> Did you manage to subscribe?
>>>>>
>>>>> I put in another subscription request just after your previous
>>>>>  reply, and I'm still waiting. I wonder if the confirmation e-mail
>>>>>  is getting through. Nonetheless, I'll keep trying.
>>>
>>> Unfortunately the address does not work:
>>>
>>> This is the mail system at host mx0.elegosoft.com
>>> <http://mx0.elegosoft.com>.
>>>
>>> I'm sorry to have to inform you that your message could not
>>> be delivered to one or more recipients. It's attached below.
>>>
>>> For further assistance, please send mail to postmaster.
>>>
>>> If you do so, please include this problem report. You can
>>> delete your own text from the attached returned message.
>>>
>>>                   The mail system
>>>
>>> <dimonax at att.net <mailto:dimonax at att.net>>: host
>>> scc-mailrelay.att.net[204.127.208.75] said:
>>>    521-88.198.54.133 blocked by sbc:blacklist.mailrelay.att.net. 521
>>> DNSRBL:
>>>    Blocked for abuse. See http://att.net/blocks (in reply to MAIL FROM
>>>    command)
>>>
>>> If he really wants to join, he needs another mail address, but I cannot
>>> tell him that.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
>>> 86 95
>>>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>
>>
>



-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From hendrik at topoi.pooq.com  Tue Jan 12 21:37:49 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 15:37:49 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>
Message-ID: <20100112203749.GA27597@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
> 
> Range checking and overflow checking I think are different.
>  
>  
> TYPE T1 = [1..6];
> a:T1 := 7; (* range check error *)
> b:T1 := 6;
> c:T1 := 1;
> d:T1 := b + c; (* range check error *)
> e:T1 := c - b; (* range check error *)
> f:ARRAY [1..4] OF INTEGER;
> f[b] := 0; (* range check error *)
> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>  
>  
> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>  
>  
> Initially it'll probably be a command line option or such.
>  
>  
> Or maybe it isn't a safety issue?
> As long as one has checks on array indexing? Which I'm sure we do.

I always thought one of the points about declared ranges (instead of 
making everything just int, as C does) was to enable one to suppress 
most of the array indexing checks safely.

-- hendrik


From jay.krell at cornell.edu  Tue Jan 12 21:51:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 20:51:46 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <20100112203749.GA27597@topoi.pooq.com>
References: <20100112195752.22AC21A2079@async.async.caltech.edu>,
	<COL101-W569368C8E68A3CF1870984E66C0@phx.gbl>,
	<20100112203749.GA27597@topoi.pooq.com>
Message-ID: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>


> subranges allow suppressing array index checks
 
I didn't know that.
Sounds reasonable.
I haven't contradicted it, have I?
 
 
That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.
 
Gotta go,
 - Jay


----------------------------------------
> Date: Tue, 12 Jan 2010 15:37:49 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On Tue, Jan 12, 2010 at 08:21:27PM +0000, Jay K wrote:
>>
>> Range checking and overflow checking I think are different.
>>
>>
>> TYPE T1 = [1..6];
>> a:T1 := 7; (* range check error *)
>> b:T1 := 6;
>> c:T1 := 1;
>> d:T1 := b + c; (* range check error *)
>> e:T1 := c - b; (* range check error *)
>> f:ARRAY [1..4] OF INTEGER;
>> f[b] := 0; (* range check error *)
>> g:INTEGER := LAST(INTEGER) - 5 + a; (* overflow *)
>>
>>
>> But anyway, yes it will be slower, but I believe it should be mandatory, at least in safe modules, it is needed for safety, and I doubt it'll be *noticably* slower for the vast majority of code.
>>
>>
>> Initially it'll probably be a command line option or such.
>>
>>
>> Or maybe it isn't a safety issue?
>> As long as one has checks on array indexing? Which I'm sure we do.
>
> I always thought one of the points about declared ranges (instead of
> making everything just int, as C does) was to enable one to suppress
> most of the array indexing checks safely.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Tue Jan 12 22:17:00 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 12 Jan 2010 16:17:00 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
References: <20100112203749.GA27597@topoi.pooq.com>
	<COL101-W21D7D1AC3DFEFD852ED34CE66C0@phx.gbl>
Message-ID: <20100112211700.GA29801@topoi.pooq.com>

On Tue, Jan 12, 2010 at 08:51:46PM +0000, Jay K wrote:
> 
> > subranges allow suppressing array index checks
>  
> I didn't know that.
> Sounds reasonable.
> I haven't contradicted it, have I?

No.  Assignments to subrange variables can be a lot less frequent than 
the use of those variables as subscripts, especially in, say, 
matrix-handling code.

>  
>  
> That does point out that indexing an array with an INTEGER need bounds checks on both ends though.
> Probably a FOR loop can optimize though -- no need to check the lower bound more than once or somesuch.

Might not have to check the lower bound at all.
Might only have to check the upper bound when you have to anyway in the 
loop control.

-- hendrik


From hosking at cs.purdue.edu  Tue Jan 12 23:02:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:02:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <20100112195752.22AC21A2079@async.async.caltech.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
	<20100112195752.22AC21A2079@async.async.caltech.edu>
Message-ID: <E48D174B-D53C-4D58-8F13-10B450ED3437@cs.purdue.edu>

On 12 Jan 2010, at 14:57, Mika Nystrom wrote:

> 
> Are you actually proposing making range checking mandatory for integer
> arithmetic?
> 
> I think that's a bad idea... the performance hit could be very high
> (especially on some architectures).

I agree.

> The language should already guarantee that problems in this area can't
> cause unchecked runtime errors.

It does.

> 
>     Mika
> 
> Jay K writes:
>> 
>> I'm not against using "hardware traps"=2C if they exist.
>> I'll have to do a bunch of research as to their existance.
>> =20
>> =20
>> =20
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>> =20
>> =20
>> Even so=2C if it is a runtime configuration=2C I realize
>> that the implementation=2C on a system
>> without hardware traps=2C with a processor-specific
>> flag would look *like*:
>> =20
>> =20
>> check for overflow=20
>> if no overflow=2C continue on as usual
>> if overflow=2C call out to a function
>>  that function:
>>     fetch the thread local
>>     depending on *that*=2C raise an exception or continue on=20
>> =20
>> =20
>> I suspect I could easily quickly put in place a portable implementation=2C =
>> and..like *almost* everything else that isn't I/O bound (other than code si=
>> ze issue).
>> =20
>> =20
>> Hm. Actually another very good approach is probably to have the front end i=
>> nline most of this logic=2C like everything except 64bit multiplication on =
>> 32bit platform. At first I though that'd be too bloating=2C but it's actual=
>> ly probably competitive. There is already inlining of the computation of th=
>> e result=2C and merely passing three parameters won't be cheap.
>> =20
>> =20
>> That can also be highly portable=2C mimicing the algorithms I showed.
>> =20
>> =20
>> The front end can also do the optimization where overflow isn't necessarily=
>> checked for every single operation.
>> =20
>> =20
>> - Jay
>> 
>> 
>> 
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> 
>>> 
>>> On 12 Jan 2010=2C at 04:23=2C Jay K wrote:
>>> 
>>> I propose that integer signed overflow always raise an immediate exceptio=
>> n.
>>> Word.T should either raise an exception for unsigned overflow=2C or maybe=
>> no exceptions at all.
>>> For folks that want silent wraparound=2C maybe a separate interface like =
>> UnsafeInt.
>>> 
>>> That is going to pose a performance issue (that many C programmers may ba=
>> ulk at!).
>>> 
>>> I propose that FloatMode's integer features not be the way forward.
>>> 
>>> Why not?
>>> 
>>> There are two implementation strategies.
>>> 
>>> 
>>> - "check the carry flag"
>>> A processor-specific thing=2C but possibly something easy for the gcc bac=
>> kend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>> 
>>> Yes=2C doable.
>>> 
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>> 
>>> Very bad for performance. We should rely on the processor support for ari=
>> thmetic traps or condition variables.
>>> 
>>> 
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>> 
>>> Not the best way going forward...
>>> 
>>> e.g.
>>> void add(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a + b)=3B
>>> /* overflow if input signs are equal and output sign is different=3B
>>> if input signs are unequal=2C overflow is not possible
>>> positive + positive: expect positive=2C else overflow
>>> negative + negative: expect negative=2C else overflow
>>> positive + negative: overflow not possible */
>>> *overflow =3D ((a < 0) =3D=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> 
>>> void sub(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> int d =3D (a - b)=3B
>>> /* overflow if input signs are unequal and output sign is different than =
>> first input=3B
>>> if input signs are equal=2C overflow is not possible=3B
>>> positive - negative: expect positive=2C overflow if negative
>>> negative - positive: expect negative=2C overflow if positive
>>> positive - positive=2C negative - negative: overflow not possible */
>>> *overflow =3D ((a < 0) !=3D (b < 0) && (d < 0) !=3D (a < 0))=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> #include
>>> 
>>> void mult(int a=2C int b=2C int* c=2C int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d =3D (a * (int64)b)=3B
>>> *c =3D (int)d=3B
>>> *overflow =3D (d>=3D INT_MIN && d <=3D INT_MAX)=3B
>>> }
>>> 
>>> /* for interface Word */
>>> typedef unsigned uint=3B
>>> 
>>> void addu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a + b)=3B
>>> /* overflow if output less than either input */
>>> *overflow =3D (d < a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void subu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> uint d =3D (a - b)=3B
>>> /* overflow if output greater than first input */
>>> *overflow =3D (d> a)=3B
>>> *c =3D d=3B
>>> }
>>> 
>>> void multu(uint a=2C uint b=2C uint* c=2C int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d =3D (a * (uint64)b)=3B
>>> *overflow =3D (d <=3D UINT_MAX)=3B
>>> *c =3D (uint)d=3B
>>> }
>>> 
>>> void multLU(uint64 a=2C uint64 b=2C uint64* c=2C int* overflow)
>>> {
>>> /* break it down into smaller operations=2C not shown=2C but not difficul=
>> t */
>>> }
>>> 
>>> 
>>> Yes I know this is inefficient=2C but such is a possible price of portabl=
>> e safety.
>>> 
>>> 
>>> A hybrid is probably possible if the gcc backend support must be processo=
>> r specific and we gradually provide the implementations.
>>> 
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows =
>> both trap-based and (with compiler support) checked condition code implemen=
>> tations.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 		 	   		  =



From hosking at cs.purdue.edu  Tue Jan 12 23:09:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 17:09:36 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>
Message-ID: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>

On 12 Jan 2010, at 14:46, Jay K wrote:

> I'm not against using "hardware traps", if they exist.
> I'll have to do a bunch of research as to their existence.

Their existence is why FloatMode was designed in the first place.

> I don't think one should be able to turn this on or off.
> I think it should be static per type or interface/library.

I disagree.  You are conflating language safety with what the semantics of arithmetic should be.  The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C).  Overflow doesn't create a "bad" value for an INTEGER.  It is still an INTEGER value.  It is just that the value is obtained by overflowed arithmetic in the hardware.


> Even so, if it is a runtime configuration, I realize
> that the implementation, on a system
> without hardware traps, with a processor-specific
> flag would look *like*:
> 
> 
> check for overflow 
> if no overflow, continue on as usual
> if overflow, call out to a function
>   that function:
>      fetch the thread local
>      depending on *that*, raise an exception or continue on 

Why do you assume we would even support thread-local handling of overflow?    If we did, I would argue that the code would be more like:

check if this thread cares about overflow
if it does then check the overflow flag and raise an exception if it is set

> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
> 
> 
> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.

The inline sequence would be quite cheap if we really needed to go that route.

> That can also be highly portable, mimicing the algorithms I showed.
> 
> 
> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.

Correct.  It is never needed for subranges that don't include the extremes of the integer representation.

> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> Subject: Re: [M3devel] integer overflow
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> 
>> 
>> On 12 Jan 2010, at 04:23, Jay K wrote:
>> 
>> I propose that integer signed overflow always raise an immediate exception.
>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>> 
>> That is going to pose a performance issue (that many C programmers may baulk at!).
>> 
>> I propose that FloatMode's integer features not be the way forward.
>> 
>> Why not?
>> 
>> There are two implementation strategies.
>> 
>> 
>> - "check the carry flag"
>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>> And very likely easy for the integrated backend.
>> Probably very efficient.
>> 
>> Yes, doable.
>> 
>> - internally generate function calls for every arithmetic operation
>> like how sets are implemented
>> 
>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>> 
>> 
>> Implementing most such functions is easy enough in portable C.
>> Or maybe using Modula-3 and interface Word.
>> 
>> Not the best way going forward...
>> 
>> e.g.
>> void add(int a, int b, int* c, int* overflow)
>> {
>> int d = (a + b);
>> /* overflow if input signs are equal and output sign is different;
>> if input signs are unequal, overflow is not possible
>> positive + positive: expect positive, else overflow
>> negative + negative: expect negative, else overflow
>> positive + negative: overflow not possible */
>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> 
>> void sub(int a, int b, int* c, int* overflow)
>> {
>> int d = (a - b);
>> /* overflow if input signs are unequal and output sign is different than first input;
>> if input signs are equal, overflow is not possible;
>> positive - negative: expect positive, overflow if negative
>> negative - positive: expect negative, overflow if positive
>> positive - positive, negative - negative: overflow not possible */
>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>> *c = d;
>> }
>> 
>> #include
>> 
>> void mult(int a, int b, int* c, int* overflow)
>> {
>> /* do operation in higher precision and check if it fits */
>> int64 d = (a * (int64)b);
>> *c = (int)d;
>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>> }
>> 
>> /* for interface Word */
>> typedef unsigned uint;
>> 
>> void addu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a + b);
>> /* overflow if output less than either input */
>> *overflow = (d < a);
>> *c = d;
>> }
>> 
>> void subu(uint a, uint b, uint* c, int* overflow)
>> {
>> uint d = (a - b);
>> /* overflow if output greater than first input */
>> *overflow = (d> a);
>> *c = d;
>> }
>> 
>> void multu(uint a, uint b, uint* c, int* overflow)
>> {
>> /* operate at higher precision and see if it fits */
>> uint64 d = (a * (uint64)b);
>> *overflow = (d <= UINT_MAX);
>> *c = (uint)d;
>> }
>> 
>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>> {
>> /* break it down into smaller operations, not shown, but not difficult */
>> }
>> 
>> 
>> Yes I know this is inefficient, but such is a possible price of portable safety.
>> 
>> 
>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>> 
>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Tue Jan 12 23:51:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 22:51:29 +0000
Subject: [M3devel] integer overflow
In-Reply-To: <42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
References: <COL101-W60F1929F9C697D56BC1F06E66C0@phx.gbl>, ,
	<C514C8C2-569C-47C9-B909-214FB6216AC8@cs.purdue.edu>,
	<COL101-W571935AC6F339BFF72872EE66C0@phx.gbl>,
	<42757F2C-390C-477C-A9CF-6129EA0DD5E9@cs.purdue.edu>
Message-ID: <COL101-W272903528EBD5811FFF56CE66C0@phx.gbl>


I didn't think many processors offered integer overflow "traps".
I'm so used to condition flags being the way, on x86, PowerPC, 6502, etc.
  (6502 it turns out is awful, but you don't realize you are in the insane asylum until you leave it; signed comparisons required doing an actual "destructive" subtract, the "compare" instruction only "works" for unsigned comparisons) 
 
 
Divide by zero and floating point I'm more familiar with.
  Though I think x86 and PowerPC vary on that point -- integer divide by zero.
  I think that was mentioned on the "let's change architectures yet again" guide.
 
 
The reason you'd check for overflow before you'd check if the thread cares about overflow, is that the first is probably *much* cheaper and yields "true" much less often. Checking if the thread cares about trapping overflow requires getting a thread local. Checking for overflow on x86 is typically one conditional branch I believe. Or maybe a "cmove", probably cheaper.
 
 
Granted, if you get the address of the thread locals only upon entry (such as in a function with TRY!) and you only check the bit when there hasn't been a function call (such as to possibly change the setting), then the check isn't too too bad. Still, one conditional branch, encoded to be predicted correctly (whichever way that is..), seems cheap. Plus there might be a reasonable way to "accumulate" overflow that is even cheaper. Like, having a local overflow variable and if you have e := a + b + c + d, do like:
 
 
  overflow = 0;  
  e = a + b;  
  overflow += carry;  
  e += c;  
  overflow += carry;  
  e += d;  
  overflow += carry;  
  if overflow raise 
 
 
might be cheaper than:
  overflow = 0;  
  e = a + b;  
  if overflow raise 
  e += c;  
  if overflow raise 
  e += d;  
  if overflow raise 
 
 
 
I really thought that detecting/trapping integer overflow was part of being safe. It seems I was very mistaken.
So I guess any work here is really not so important as I thought?
Someone convince me that it is actually important?
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 17:09:36 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow
>
> On 12 Jan 2010, at 14:46, Jay K wrote:
>
>> I'm not against using "hardware traps", if they exist.
>> I'll have to do a bunch of research as to their existence.
>
> Their existence is why FloatMode was designed in the first place.
>
>> I don't think one should be able to turn this on or off.
>> I think it should be static per type or interface/library.
>
> I disagree. You are conflating language safety with what the semantics of arithmetic should be. The language spec is deliberately vague about whether overflow checking should take place or not for signed integers (as is C). Overflow doesn't create a "bad" value for an INTEGER. It is still an INTEGER value. It is just that the value is obtained by overflowed arithmetic in the hardware.
>
>
>> Even so, if it is a runtime configuration, I realize
>> that the implementation, on a system
>> without hardware traps, with a processor-specific
>> flag would look *like*:
>>
>>
>> check for overflow
>> if no overflow, continue on as usual
>> if overflow, call out to a function
>> that function:
>> fetch the thread local
>> depending on *that*, raise an exception or continue on
>
> Why do you assume we would even support thread-local handling of overflow? If we did, I would argue that the code would be more like:
>
> check if this thread cares about overflow
> if it does then check the overflow flag and raise an exception if it is set
>
>> I suspect I could easily quickly put in place a portable implementation, and..like *almost* everything else that isn't I/O bound (other than code size issue).
>>
>>
>> Hm. Actually another very good approach is probably to have the front end inline most of this logic, like everything except 64bit multiplication on 32bit platform. At first I though that'd be too bloating, but it's actually probably competitive. There is already inlining of the computation of the result, and merely passing three parameters won't be cheap.
>
> The inline sequence would be quite cheap if we really needed to go that route.
>
>> That can also be highly portable, mimicing the algorithms I showed.
>>
>>
>> The front end can also do the optimization where overflow isn't necessarily checked for every single operation.
>
> Correct. It is never needed for subranges that don't include the extremes of the integer representation.
>
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> Subject: Re: [M3devel] integer overflow
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 12 Jan 2010 14:30:00 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>>
>>>
>>> On 12 Jan 2010, at 04:23, Jay K wrote:
>>>
>>> I propose that integer signed overflow always raise an immediate exception.
>>> Word.T should either raise an exception for unsigned overflow, or maybe no exceptions at all.
>>> For folks that want silent wraparound, maybe a separate interface like UnsafeInt.
>>>
>>> That is going to pose a performance issue (that many C programmers may baulk at!).
>>>
>>> I propose that FloatMode's integer features not be the way forward.
>>>
>>> Why not?
>>>
>>> There are two implementation strategies.
>>>
>>>
>>> - "check the carry flag"
>>> A processor-specific thing, but possibly something easy for the gcc backend to do.
>>> And very likely easy for the integrated backend.
>>> Probably very efficient.
>>>
>>> Yes, doable.
>>>
>>> - internally generate function calls for every arithmetic operation
>>> like how sets are implemented
>>>
>>> Very bad for performance. We should rely on the processor support for arithmetic traps or condition variables.
>>>
>>>
>>> Implementing most such functions is easy enough in portable C.
>>> Or maybe using Modula-3 and interface Word.
>>>
>>> Not the best way going forward...
>>>
>>> e.g.
>>> void add(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a + b);
>>> /* overflow if input signs are equal and output sign is different;
>>> if input signs are unequal, overflow is not possible
>>> positive + positive: expect positive, else overflow
>>> negative + negative: expect negative, else overflow
>>> positive + negative: overflow not possible */
>>> *overflow = ((a < 0) == (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>>
>>> void sub(int a, int b, int* c, int* overflow)
>>> {
>>> int d = (a - b);
>>> /* overflow if input signs are unequal and output sign is different than first input;
>>> if input signs are equal, overflow is not possible;
>>> positive - negative: expect positive, overflow if negative
>>> negative - positive: expect negative, overflow if positive
>>> positive - positive, negative - negative: overflow not possible */
>>> *overflow = ((a < 0) != (b < 0) && (d < 0) != (a < 0));
>>> *c = d;
>>> }
>>>
>>> #include
>>>
>>> void mult(int a, int b, int* c, int* overflow)
>>> {
>>> /* do operation in higher precision and check if it fits */
>>> int64 d = (a * (int64)b);
>>> *c = (int)d;
>>> *overflow = (d>= INT_MIN && d <= INT_MAX);
>>> }
>>>
>>> /* for interface Word */
>>> typedef unsigned uint;
>>>
>>> void addu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a + b);
>>> /* overflow if output less than either input */
>>> *overflow = (d < a);
>>> *c = d;
>>> }
>>>
>>> void subu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> uint d = (a - b);
>>> /* overflow if output greater than first input */
>>> *overflow = (d> a);
>>> *c = d;
>>> }
>>>
>>> void multu(uint a, uint b, uint* c, int* overflow)
>>> {
>>> /* operate at higher precision and see if it fits */
>>> uint64 d = (a * (uint64)b);
>>> *overflow = (d <= UINT_MAX);
>>> *c = (uint)d;
>>> }
>>>
>>> void multLU(uint64 a, uint64 b, uint64* c, int* overflow)
>>> {
>>> /* break it down into smaller operations, not shown, but not difficult */
>>> }
>>>
>>>
>>> Yes I know this is inefficient, but such is a possible price of portable safety.
>>>
>>>
>>> A hybrid is probably possible if the gcc backend support must be processor specific and we gradually provide the implementations.
>>>
>>> FloatMode seems a perfectly reasonable way forward doesn't it? It allows both trap-based and (with compiler support) checked condition code implementations.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 00:02:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 12 Jan 2010 23:02:58 +0000
Subject: [M3devel] integer overflow and for loops
Message-ID: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>


http://www.roland-illig.de/articles/modula-3-for-loop.pdf





  		 	   		  

From hosking at cs.purdue.edu  Wed Jan 13 03:18:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:18:59 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>

> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

This assumes that overflow checks should be defined on integers in the language.  Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language.  I think this is an unacceptable overhead for a systems programming language.  C does not have it.  The characteristics of restricted range integer arithmetic are well understood.  If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).



From rcolebur at SCIRES.COM  Wed Jan 13 03:23:04 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:23:04 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>

Ok, I thought I understood this, but now I'm not sure.

I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.

I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle

Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.

Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
                package C:\cm3\Sandbox\m3-win\import-libs
                package C:\cm3\Sandbox\m3-libs\m3core
                package C:\cm3\Sandbox\m3-libs\libm3
                package C:\cm3\Sandbox\m3-libs\sysutils
                package C:\cm3\Sandbox\m3-sys\m3middle
                package C:\cm3\Sandbox\m3-sys\m3objfile
                package C:\cm3\Sandbox\m3-sys\m3linker
                package C:\cm3\Sandbox\m3-sys\m3back
                package C:\cm3\Sandbox\m3-sys\m3staloneback
                package C:\cm3\Sandbox\m3-sys\m3front
                package C:\cm3\Sandbox\m3-sys\m3quake
                package C:\cm3\Sandbox\m3-sys\cm3
                package C:\cm3\Sandbox\m3-tools\m3bundle
                package C:\cm3\Sandbox\m3-sys\mklib

The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Q1:  So, am I to infer that in the process of "bootstrapping" a new compiler using an old one, that you have to leave out "m3core" and "libm3" on the first pass, or is there some other logic going on here?

Q2:  Next, if "m3staloneback" and "m3bundle" are needed, shouldn't they be listed as part of the "front" group in pkginfo.txt?

Regards,
Randy Coleburn

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

From hosking at cs.purdue.edu  Wed Jan 13 03:30:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 12 Jan 2010 21:30:49 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>

On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:

> Ok, I thought I understood this, but now I?m not sure.
>  
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay?s upgrade.py to see what it does.
>  
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>  
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>  
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
>  
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>  
> Q1:  So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?

It has to do with bootstrapping the compiler to implement feature FOO.  Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries.  First you build a compiler that can compiler FOO (using the old libraries).  Then you make the FOO change to the libraries, and recompile the compiler against the new libraries.  Now both libraries and compiler are FOO-capable.  Carry on...

> Q2:  Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?

They aren't actually needed here.  Not sure why they are included.  Nor is import-libs unless on Windows perhaps.

>  
> Regards,
> Randy Coleburn
>  

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

From jay.krell at cornell.edu  Wed Jan 13 03:57:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 02:57:07 +0000
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>,
	<2D4C1A79-CE80-4836-AD2A-8C5A32188768@cs.purdue.edu>
Message-ID: <COL101-W132DFD4126C48933CFAA6DE66B0@phx.gbl>


m3stalonebak I think is never used, agreed.
m3bundle I don't remember why I put it there.
 
 
  Probably because in upgrade.sh or such, there was logic like if m3bundle not found in path, build it fairly early. Something like that. A lot of this is based on what the *.sh files did/do, though there is also divergence/improvement/regression.
  - The *.sh files accept additional cm3 parameters, *.py not yet.
  - The *.sh files read pkginfo.txt, which I was a vocal proponent of and implemented mostly. The *.py not yet (yeah yeah, I'm a hypocrite.)
(*.py is still arguably better than the older *.sh here, in that the data drivenness of it has less redundancy, e.g. the ordering is only present once).
 
 
import-libs is "self filtering", building it does nothing, successfully, for other targets.
 
 
Agreed.
There is are unavoidable circularities.
 
 
Historically there was also a problem with adding new targets.
If libm3 "knew" about a different list of targets than cm3, then cm3 couldn't build it. Maybe similar with m3core but I think not.
So you had to avoid using your pre-existing cm3 to build a current libm3.
First build cm3, then libm3.
That problem is gone now.
What libm3 actually I think "knew" about was more like the hash ("fingerprint") of an enum that listed all targets, which is about the same as having an exact list (few collisions that aren't also exact matches). Anyway, the list is gone.
 
 
But the circularities are and still can be present.
m3core/libm3 use LONGINT for example, so a sufficiently old cm3 can't compile them.
 
 
This is the nature of writing a system in itself.
Definitely a worthwhile tradeoff.
:)
 
 
 - Jay




________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:30:49 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] two questions on bootstrapping the compiler
>
>
>
> On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:
>
> Ok, I thought I understood this, but now I?m not sure.
>
> I had trouble rebuilding everything due to the recent changes. So, I ran Jay?s upgrade.py to see what it does.
>
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
>
> Note that ?m3staloneback? and ?m3bundle? are not listed as being part of the ?front? group in pkginfo.txt.
>
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\m3core
> package C:\cm3\Sandbox\m3-libs\libm3
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
> package C:\cm3\Sandbox\m3-sys\mklib
>
> The difference here is that ?m3core? and ?libm3? (which are in the ?front? group) are added back to the list.
>
> Q1: So, am I to infer that in the process of ?bootstrapping? a new compiler using an old one, that you have to leave out ?m3core? and ?libm3? on the first pass, or is there some other logic going on here?
>
> It has to do with bootstrapping the compiler to implement feature FOO. Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries. First you build a compiler that can compiler FOO (using the old libraries). Then you make the FOO change to the libraries, and recompile the compiler against the new libraries. Now both libraries and compiler are FOO-capable. Carry on...
>
> Q2: Next, if ?m3staloneback? and ?m3bundle? are needed, shouldn?t they be listed as part of the ?front? group in pkginfo.txt?
>
> They aren't actually needed here. Not sure why they are included. Nor is import-libs unless on Windows perhaps.
>
>
> Regards,
> Randy Coleburn
>
> 		 	   		  

From rcolebur at SCIRES.COM  Wed Jan 13 03:57:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 12 Jan 2010 21:57:02 -0500
Subject: [M3devel] LONGINT on NT386
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>

Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?

I ask, because currently on Windows, LONGINT has same range as INTEGER.

Is there anything I can do to help?

BYTESIZE(INTEGER) =4
BYTESIZE(CARDINAL)=4
BYTESIZE(LONGINT) =4

FIRST(INTEGER) =-2147483648
LAST (INTEGER) = 2147483647

FIRST(CARDINAL)=0
LAST (CARDINAL)=2147483647

FIRST(LONGINT) =-2147483648
LAST (LONGINT) = 2147483647

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/9c6de4be/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan 13 04:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:08:47 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
Message-ID: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>


If isn't needed for safety, then I agree.
I really thought it was needed for safety.
But I do not "argue" that that is true.
I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
 
 
That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
This is a common problem. There are several solutions all with tradeoffs.
It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
I tend to think type/interface are the best options.
 
 
INTERFACE IntegerOverflowOut;
 
 
(* maybe UNTRACED REF := NIL for "compatibility" *)
 
PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;

PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
 
 
INTERFACE IntegerOverflowRaises;
 
EXCEPTION Error;
 
PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
 
 
INTERFACE IntegerOverflowSilent;
 
 
PROCEDURE Add(a,b: INTEGER): INTEGER;
PROCEDURE Sub(a,b: INTEGER): INTEGER;
PROCEDURE Mult(a,b: INTEGER): INTEGER;
PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
 
PROCEDURE AddLong(a,b: LONGINT): LONGINT;
PROCEDURE SubLong(a,b: LONGINT): LONGINT;
PROCEDURE MultLong(a,b: LONGINT): LONGINT;
PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
 
 
Notice how two of the interfaces are "source compatible" and allow
easy switching between them for testing/investigation.
That might be deemed a feature, and provided somehow across all three.
 
 
Is anyone strongly opposed to providing something *like* these in m3core?
Maybe inlined by the compiler?
 
 
You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
 
And sometimes not.
 
 
 - Jay



----------------------------------------
> Subject: Re: [M3devel] integer overflow and for loops
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:18:59 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 13 04:27:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 03:27:05 +0000
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>


It's not easy to fix.
I386_MINGWIN is the easiest way actually..
I'll look at it again soon..
Maybe we should have an option where the front end decomposes things?
Or makes function calls?
That is probably a pleasantly nice option.
 
 
 - Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Tue, 12 Jan 2010 21:57:02 -0500
> Subject: [M3devel] LONGINT on NT386
>
>
> Ok, so now that we have this LONGINT type, what else needs
> to take place for it to be useful?
>
> I ask, because currently on Windows, LONGINT has same range
> as INTEGER.
>
>
> Is there anything I can do to help?
>
>
>
>
>
>
>
> BYTESIZE(INTEGER) =4
>
> BYTESIZE(CARDINAL)=4
>
> BYTESIZE(LONGINT) =4
>
>
>
> FIRST(INTEGER) =-2147483648
>
> LAST (INTEGER) = 2147483647
>
>
>
> FIRST(CARDINAL)=0
>
> LAST (CARDINAL)=2147483647
>
>
>
> FIRST(LONGINT) =-2147483648
>
> LAST (LONGINT) = 2147483647
>
>
>
>
>
>
>
> Regards,
>
>
>
> Randy Coleburn
>
> 		 	   		  

From roland.illig at gmx.de  Wed Jan 13 08:33:46 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Wed, 13 Jan 2010 08:33:46 +0100
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
Message-ID: <4B4D775A.9040603@gmx.de>

Jay K schrieb:
> http://www.roland-illig.de/articles/modula-3-for-loop.pdf

My main point in that article was not the integer overflow but the fact 
of having an ugly sentence like "don't use the FOR loop for large 
numbers" in the language definition. Additionally, one would not expect 
the FOR loop to loop endlessly. These are the things I wanted to fix 
back then.

Roland


From wagner at elegosoft.com  Wed Jan 13 10:43:03 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 13 Jan 2010 10:43:03 +0100
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
Message-ID: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>
>>  Also, in case anyone is interested, the current HEAD fails to   
>> compile the following packages on Windows Vista:
>> "m3-libs\m3core"
>> "m3-libs\libm3"
>> "m3-tools\m3tk"
>> So some recent changes have caused a problem.
>
> Did you bootstrap a new compiler?  You will need to bootstrap a   
> compiler before you can compile the revised ORD/VAL definitions.

So if I understand this correctly, should we finally get to release
5.8, then this compiler won't be able to compile the current trunk
head? That is, not unless we merge this change to the release branch?

Anything else that we should do for 5.8?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed Jan 13 15:25:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:25:14 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <20100113142513.GA25925@topoi.pooq.com>

On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
>  
>  
> INTERFACE IntegerOverflowOut;

While we're at it, should there be a carry out as well?

-- hendrik



From hendrik at topoi.pooq.com  Wed Jan 13 15:32:32 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 13 Jan 2010 09:32:32 -0500
Subject: [M3devel] two questions on bootstrapping the compiler
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF00@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <20100113143232.GB25925@topoi.pooq.com>

On Tue, Jan 12, 2010 at 09:23:04PM -0500, Coleburn, Randy wrote:
> Ok, I thought I understood this, but now I'm not sure.
> 
> I had trouble rebuilding everything due to the recent changes.  So, I ran Jay's upgrade.py to see what it does.
> 
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
> 
> Note that "m3staloneback" and "m3bundle" are not listed as being part of the "front" group in pkginfo.txt.
> 
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
>                 package C:\cm3\Sandbox\m3-win\import-libs
>                 package C:\cm3\Sandbox\m3-libs\m3core
>                 package C:\cm3\Sandbox\m3-libs\libm3
>                 package C:\cm3\Sandbox\m3-libs\sysutils
>                 package C:\cm3\Sandbox\m3-sys\m3middle
>                 package C:\cm3\Sandbox\m3-sys\m3objfile
>                 package C:\cm3\Sandbox\m3-sys\m3linker
>                 package C:\cm3\Sandbox\m3-sys\m3back
>                 package C:\cm3\Sandbox\m3-sys\m3staloneback
>                 package C:\cm3\Sandbox\m3-sys\m3front
>                 package C:\cm3\Sandbox\m3-sys\m3quake
>                 package C:\cm3\Sandbox\m3-sys\cm3
>                 package C:\cm3\Sandbox\m3-tools\m3bundle
>                 package C:\cm3\Sandbox\m3-sys\mklib
> 
> The difference here is that "m3core" and "libm3" (which are in the "front" group) are added back to the list.

Also "mklib".

-- hendrik


From hosking at cs.purdue.edu  Wed Jan 13 16:09:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:01 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <8E064BBE-460E-45AE-B08A-82B8AA6A5B16@cs.purdue.edu>

That's because the integrated backed on Windows doesn't currently support LONGINT.  Someone needs to smarten up the code generator to cope with LONGINT.

On 12 Jan 2010, at 21:57, Coleburn, Randy wrote:

> Ok, so now that we have this LONGINT type, what else needs to take place for it to be useful?
>  
> I ask, because currently on Windows, LONGINT has same range as INTEGER.
>  
> Is there anything I can do to help?
>  
> BYTESIZE(INTEGER) =4
> BYTESIZE(CARDINAL)=4
> BYTESIZE(LONGINT) =4
> 
> FIRST(INTEGER) =-2147483648
> LAST (INTEGER) = 2147483647
> 
> FIRST(CARDINAL)=0
> LAST (CARDINAL)=2147483647
> 
> FIRST(LONGINT) =-2147483648
> LAST (LONGINT) = 2147483647
>  
> Regards,
> Randy Coleburn

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

From hosking at cs.purdue.edu  Wed Jan 13 16:09:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:09:59 -0500
Subject: [M3devel] LONGINT on NT386
In-Reply-To: <COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8710CD76FF02@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W1BDA54732A53B41F826BEE66B0@phx.gbl>
Message-ID: <831906E2-A122-4C17-BA03-C0101F4DFE85@cs.purdue.edu>

On 12 Jan 2010, at 22:27, Jay K wrote:

> It's not easy to fix.
> I386_MINGWIN is the easiest way actually..
> I'll look at it again soon..
> Maybe we should have an option where the front end decomposes things?

It is the job of the backend to map to machine types.  Don't go complicating the front-end unnecessarily: compiler design 101.

> Or makes function calls?
> That is probably a pleasantly nice option.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Tue, 12 Jan 2010 21:57:02 -0500
>> Subject: [M3devel] LONGINT on NT386
>> 
>> 
>> Ok, so now that we have this LONGINT type, what else needs
>> to take place for it to be useful?
>> 
>> I ask, because currently on Windows, LONGINT has same range
>> as INTEGER.
>> 
>> 
>> Is there anything I can do to help?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> BYTESIZE(INTEGER) =4
>> 
>> BYTESIZE(CARDINAL)=4
>> 
>> BYTESIZE(LONGINT) =4
>> 
>> 
>> 
>> FIRST(INTEGER) =-2147483648
>> 
>> LAST (INTEGER) = 2147483647
>> 
>> 
>> 
>> FIRST(CARDINAL)=0
>> 
>> LAST (CARDINAL)=2147483647
>> 
>> 
>> 
>> FIRST(LONGINT) =-2147483648
>> 
>> LAST (LONGINT) = 2147483647
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Randy Coleburn
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:14:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:14:52 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <2227245F-1770-4D86-B74A-CEBDA15FCB2D@cs.purdue.edu>

On 13 Jan 2010, at 04:43, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
>> 
>>> Also, in case anyone is interested, the current HEAD fails to  compile the following packages on Windows Vista:
>>> "m3-libs\m3core"
>>> "m3-libs\libm3"
>>> "m3-tools\m3tk"
>>> So some recent changes have caused a problem.
>> 
>> Did you bootstrap a new compiler?  You will need to bootstrap a  compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?

Correct.  I suggest we merge the changes to avoid inconsistency.  This will be the first official release with LONGINT in it so let's make sure we make it right before anyone starts actually using it...

> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Wed Jan 13 16:40:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:40:20 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>
Message-ID: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>

I really don't think an interface should support overflow checks for unsigned types.  We have Word.T and Long.T with their current semantics.  To be honest I don't think this is really a high priority right now.

I do have another suggestion for where to direct your energies.  :-)  What about going back to smartening up the integrated backend to generate LONGINT properly on Windows?  As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end.  Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html

We only need the following:

Load Relaxed:  MOV (from memory)
Load Acquire:  MOV (from memory)
Load Seq_Cst:  LOCK XADD(0) // alternative: MFENCE,MOV (from memory)

Store Relaxed: MOV (into memory)
Store Release: MOV (into memory)
Store Seq Cst: LOCK XCHG    // alternative: MOV (into memory),MFENCE

Acquire Fence: <ignore>
Release Fence: <ignore>
Acq_Rel Fence: <ignore>
Seq_Cst Fence: MFENCE

Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).

One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable.  The ops as currently defined do not take an offset.  This would permit more efficient addressing modes for the instructions just like regular loads/stores.

On 12 Jan 2010, at 22:08, Jay K wrote:

> 
> If isn't needed for safety, then I agree.
> I really thought it was needed for safety.
> But I do not "argue" that that is true.
> I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> 
> 
> That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> This is a common problem. There are several solutions all with tradeoffs.
> It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> I tend to think type/interface are the best options.
> 
> 
> INTERFACE IntegerOverflowOut;
> 
> 
> (* maybe UNTRACED REF := NIL for "compatibility" *)
> 
> PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> 
> 
> INTERFACE IntegerOverflowRaises;
> 
> EXCEPTION Error;
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> 
> 
> INTERFACE IntegerOverflowSilent;
> 
> 
> PROCEDURE Add(a,b: INTEGER): INTEGER;
> PROCEDURE Sub(a,b: INTEGER): INTEGER;
> PROCEDURE Mult(a,b: INTEGER): INTEGER;
> PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> 
> PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> 
> 
> Notice how two of the interfaces are "source compatible" and allow
> easy switching between them for testing/investigation.
> That might be deemed a feature, and provided somehow across all three.
> 
> 
> Is anyone strongly opposed to providing something *like* these in m3core?
> Maybe inlined by the compiler?
> 
> 
> You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> 
> And sometimes not.
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] integer overflow and for loops
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 21:18:59 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>> 
>> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 13 16:47:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 10:47:19 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <4B4D775A.9040603@gmx.de>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>
Message-ID: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> 
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
> 
> Roland



From rcolebur at SCIRES.COM  Wed Jan 13 17:41:44 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 11:41:44 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>
	<4B4D775A.9040603@gmx.de>,
	<F4E28F24-9538-4185-97F5-45D5F09E295D@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CD7F1902@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland

From rcolebur at SCIRES.COM  Wed Jan 13 19:00:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 13 Jan 2010 13:00:02 -0500
Subject: [M3devel] integer overflow and for loops
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E412@ATLEX02-SRV.SCIRES.LOCAL>

I agree completely.  

(I know I said something about overflow checking before, but I mispoke; my intent was to ensure the implementation had a way we could turn this on because I was under the impression the current implementation hadn't evolved that far even though FloatMode gave the interface.)

--Randy Coleburn

________________________________________
From: Tony Hosking [hosking at cs.purdue.edu]
Sent: Wednesday, January 13, 2010 10:47 AM
To: Roland Illig
Cc: m3devel
Subject: Re: [M3devel] integer overflow and for loops

Their is a fine line to tread here between prohibiting perceived "bad" things happening and leaving the language design permissive enough to have an efficient implementation.  In the case of overflow I am not convinced it is so evil that it should be prohibited in the implementation.  In fact, one can argue that because current hardware does not uniformly treat integer overflow in ways that yield to efficient implementations the retaining the ambiguity is the right compromise.  This does not make the language any less safe.  A programmer cannot safely conjure values out of thin air.  And so long as he/she understands about integer overflow then the effects are at least entirely predictable.  Gguard against overflow is straightforward enough to do:

VAR upper: [0..LAST(INTEGER)-1] := bound;
FOR j = lower TO upper DO ... END;

On 13 Jan 2010, at 02:33, Roland Illig wrote:

> Jay K schrieb:
>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
>
> My main point in that article was not the integer overflow but the fact of having an ugly sentence like "don't use the FOR loop for large numbers" in the language definition. Additionally, one would not expect the FOR loop to loop endlessly. These are the things I wanted to fix back then.
>
> Roland


From jay.krell at cornell.edu  Wed Jan 13 22:39:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:39:34 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
Message-ID: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>


Agreed. I might have more a clue this time around for LONGINT/NT386.

I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:

    last_imm   : INTEGER := 0;
    lowbound   : INTEGER := FIRST (INTEGER);
    upbound    : INTEGER := LAST (INTEGER);


Something is bugging me a bit though.

Is TInt also used to hold LONGINT values for 32bit targets?

 

I'll look into the atomics too.

It's easy, because in particular, we can just be overly strict on the memory model.

Boehm's prototype already is -- using full barriers where only release/acquire is called for.

 

mfence is a "relatively new" instruction. We are ok with that?

 

I'll try to report back later about the offset question.

I'll compile some C examples and see what addressing modes get used. :)

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 10:40:20 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> 
> I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> 
> We only need the following:
> 
> Load Relaxed: MOV (from memory)
> Load Acquire: MOV (from memory)
> Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> 
> Store Relaxed: MOV (into memory)
> Store Release: MOV (into memory)
> Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> 
> Acquire Fence: <ignore>
> Release Fence: <ignore>
> Acq_Rel Fence: <ignore>
> Seq_Cst Fence: MFENCE
> 
> Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> 
> One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> 
> On 12 Jan 2010, at 22:08, Jay K wrote:
> 
> > 
> > If isn't needed for safety, then I agree.
> > I really thought it was needed for safety.
> > But I do not "argue" that that is true.
> > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > 
> > 
> > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > This is a common problem. There are several solutions all with tradeoffs.
> > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > I tend to think type/interface are the best options.
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> > 
> > 
> > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > 
> > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > 
> > 
> > INTERFACE IntegerOverflowRaises;
> > 
> > EXCEPTION Error;
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > 
> > 
> > INTERFACE IntegerOverflowSilent;
> > 
> > 
> > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > 
> > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > 
> > 
> > Notice how two of the interfaces are "source compatible" and allow
> > easy switching between them for testing/investigation.
> > That might be deemed a feature, and provided somehow across all three.
> > 
> > 
> > Is anyone strongly opposed to providing something *like* these in m3core?
> > Maybe inlined by the compiler?
> > 
> > 
> > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > 
> > And sometimes not.
> > 
> > 
> > - Jay
> > 
> > 
> > 
> > ----------------------------------------
> >> Subject: Re: [M3devel] integer overflow and for loops
> >> From: hosking at cs.purdue.edu
> >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> >> CC: m3devel at elegosoft.com
> >> To: jay.krell at cornell.edu
> >> 
> >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> >> 
> >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/456d6837/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan 13 22:45:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:45:17 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
Message-ID: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>


Yes and no. I was thinking about this too.

In general this "race" never ends.

However:

  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"

   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

 

  - the "race" should actually "slow down" now that I fixed the platform list problem :)

     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use

     (to be clear, the "front" group needs to be more careful about using more features;

     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

 

 

If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.

They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/b0ca354d/attachment-0002.html>

From hosking at cs.purdue.edu  Wed Jan 13 22:53:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 16:53:19 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
Message-ID: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>

On 13 Jan 2010, at 16:45, Jay K wrote:

> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)

We should merge head back to release for LONGINT as it is now (more consistently) implemented.

>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).

Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.

I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.

>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).

That would be good too.

>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

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

From jay.krell at cornell.edu  Wed Jan 13 22:58:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 21:58:55 +0000
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <20100113142513.GA25925@topoi.pooq.com>
References: <3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<20100113142513.GA25925@topoi.pooq.com>
Message-ID: <COL101-W5136334F62E4E28C53D39BE66B0@phx.gbl>


I believe it is the same thing. As long as you still compute the lower bits correctly.

There should also be carry in.

And check if the arithmetic library doesn't already provide this stuff.

 

 

You might also provide a library, where, at least for add/sub, signed and unsigned

operations are merged but two extra bits are output: "signed overflow" and "unsigned overflow".

Probably all processors do that in one add/sub instruction that produces at least

2 status flags.

"signed overflow" is the "second to last carry bit" as I recall.

"unsigned overflow" is merely the "last carry bit".

 

 

Another way to look at it is that there is signed overflow if there was

carry into the sign bit.

 

 

Another implementation choice is what lower bits to return if there is overflow.

I had a "new idea" that you might as well just always use the direct

implementation to compute the lower bits. It's a little extra work

in the highest precision multiplication case but probably ok.

That is -- look at hand.c, how m3_mult_u64 throws away the

result of the last m3_add_u64.

 

Someone should also write a bunch of code with these things and then

argue for operator overloading in the language. :)

 

 

 - Jay

 
> Date: Wed, 13 Jan 2010 09:25:14 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer overflow and for loops
> 
> On Wed, Jan 13, 2010 at 03:08:47AM +0000, Jay K wrote:
> > 
> > 
> > INTERFACE IntegerOverflowOut;
> 
> While we're at it, should there be a carry out as well?
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/1cc7e05e/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan 13 23:39:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Jan 2010 22:39:53 +0000
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>


Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

I kind of think Target.Int should remain being implemented as an array of 8 bit integers.

That preserves flexibility of targeting basically "anything from anything".

 

 

Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.

  Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.

 

 

As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

I think it's a pretty simple fix.

 

 

There is still a bug targeting 64bit from 32bit because of this.

The attempts to declare "maximally sized arrays" fails.

m3core has a hack where it uses 2GB or 4GB instead of the real max.

The "jvideo" package still fails to cross compile.

 

 

 - Jay
 


Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
From: hosking at cs.purdue.edu
Date: Wed, 13 Jan 2010 16:53:19 -0500
CC: wagner at elegosoft.com; m3devel at elegosoft.com
To: jay.krell at cornell.edu




On 13 Jan 2010, at 16:45, Jay K wrote:


Yes and no. I was thinking about this too.
In general this "race" never ends.
However:
  - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
   (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)



We should merge head back to release for LONGINT as it is now (more consistently) implemented.


  - the "race" should actually "slow down" now that I fixed the platform list problem :)
     but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
     (to be clear, the "front" group needs to be more careful about using more features;
     for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).



Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.


I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.


 If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).



That would be good too.


 
 
 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Thu Jan 14 02:05:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:05:10 -0500
Subject: [M3devel] integer overflow and for loops
In-Reply-To: <COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
References: <COL101-W20302DD38BC43CE10995F1E66C0@phx.gbl>, ,
	<3B6142BF-837A-4781-81C2-B9E08984CE55@cs.purdue.edu>,
	<COL101-W11ED7121BC18924E90F183E66B0@phx.gbl>,
	<FCA3A0C7-A355-4EAB-8E67-713A9296C893@cs.purdue.edu>
	<COL101-W5189B1837316CA9CE890DBE66B0@phx.gbl>
Message-ID: <D3FCB564-EA7A-441C-B5E7-1DAEB00CDA77@cs.purdue.edu>

On 13 Jan 2010, at 16:39, Jay K wrote:

> Agreed. I might have more a clue this time around for LONGINT/NT386.
> I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:
>     last_imm   : INTEGER := 0;
>     lowbound   : INTEGER := FIRST (INTEGER);
>     upbound    : INTEGER := LAST (INTEGER);
> 
> Something is bugging me a bit though.
> Is TInt also used to hold LONGINT values for 32bit targets?

Yes, but the range is dictated by the n field of TInt.  So, you'd need to have 8-byte TInt for 64-bit LONGINT.

>  I'll look into the atomics too.
> It's easy, because in particular, we can just be overly strict on the memory model.

Correct: x86 is closest to SC.

> Boehm's prototype already is -- using full barriers where only release/acquire is called for.

Right.

>  mfence is a "relatively new" instruction. We are ok with that?

Our targets that support this should probably be equivalent of "-arch i686" (gcc flag) and above.  Notice that targets can always revert to locks to implement things.

>  I'll try to report back later about the offset question.
> I'll compile some C examples and see what addressing modes get used. :)

:-)

>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Wed, 13 Jan 2010 10:40:20 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] integer overflow and for loops
> > 
> > I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.
> > 
> > I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64:http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html
> > 
> > We only need the following:
> > 
> > Load Relaxed: MOV (from memory)
> > Load Acquire: MOV (from memory)
> > Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)
> > 
> > Store Relaxed: MOV (into memory)
> > Store Release: MOV (into memory)
> > Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE
> > 
> > Acquire Fence: <ignore>
> > Release Fence: <ignore>
> > Acq_Rel Fence: <ignore>
> > Seq_Cst Fence: MFENCE
> > 
> > Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).
> > 
> > One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.
> > 
> > On 12 Jan 2010, at 22:08, Jay K wrote:
> > 
> > > 
> > > If isn't needed for safety, then I agree.
> > > I really thought it was needed for safety.
> > > But I do not "argue" that that is true.
> > > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.
> > > 
> > > 
> > > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.
> > > This is a common problem. There are several solutions all with tradeoffs.
> > > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.
> > > I tend to think type/interface are the best options.
> > > 
> > > 
> > > INTERFACE IntegerOverflowOut;
> > > 
> > > 
> > > (* maybe UNTRACED REF := NIL for "compatibility" *)
> > > 
> > > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;
> > > 
> > > 
> > > INTERFACE IntegerOverflowRaises;
> > > 
> > > EXCEPTION Error;
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;
> > > 
> > > 
> > > INTERFACE IntegerOverflowSilent;
> > > 
> > > 
> > > PROCEDURE Add(a,b: INTEGER): INTEGER;
> > > PROCEDURE Sub(a,b: INTEGER): INTEGER;
> > > PROCEDURE Mult(a,b: INTEGER): INTEGER;
> > > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;
> > > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;
> > > 
> > > PROCEDURE AddLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE SubLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE MultLong(a,b: LONGINT): LONGINT;
> > > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;
> > > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;
> > > 
> > > 
> > > Notice how two of the interfaces are "source compatible" and allow
> > > easy switching between them for testing/investigation.
> > > That might be deemed a feature, and provided somehow across all three.
> > > 
> > > 
> > > Is anyone strongly opposed to providing something *like* these in m3core?
> > > Maybe inlined by the compiler?
> > > 
> > > 
> > > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.
> > > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.
> > > 
> > > And sometimes not.
> > > 
> > > 
> > > - Jay
> > > 
> > > 
> > > 
> > > ----------------------------------------
> > >> Subject: Re: [M3devel] integer overflow and for loops
> > >> From: hosking at cs.purdue.edu
> > >> Date: Tue, 12 Jan 2010 21:18:59 -0500
> > >> CC: m3devel at elegosoft.com
> > >> To: jay.krell at cornell.edu
> > >> 
> > >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf
> > >> 
> > >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).
> > >> 
> > 

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

From hosking at cs.purdue.edu  Thu Jan 14 02:35:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Jan 2010 20:35:45 -0500
Subject: [M3devel] RELENG again, was: Re:  the LONGINT proposal
In-Reply-To: <COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>,
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<COL101-W4B0FF7B6A92A6459D6596E66B0@phx.gbl>
Message-ID: <2ED96294-8D8F-4F73-8B5E-C7EA588D5A85@cs.purdue.edu>

On 13 Jan 2010, at 17:39, Jay K wrote:

> Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

It's a possibility except for overflow checks, etc. on compile-time constant folding, so perhaps not.

> I kind of think Target.Int should remain being implemented as an array of 8 bit integers.
> That preserves flexibility of targeting basically "anything from anything".

True, I guess not.

>  Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.
>   Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.
>  
>  
> As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

They should always be representable as INTEGER, no?

> I think it's a pretty simple fix.
>  
>  
> There is still a bug targeting 64bit from 32bit because of this.
> The attempts to declare "maximally sized arrays" fails.

Oh, yes, now I get you.

> m3core has a hack where it uses 2GB or 4GB instead of the real max.
> The "jvideo" package still fails to cross compile.


RIght.

>  
>  
>  - Jay
>  
> Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
> From: hosking at cs.purdue.edu
> Date: Wed, 13 Jan 2010 16:53:19 -0500
> CC: wagner at elegosoft.com; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> On 13 Jan 2010, at 16:45, Jay K wrote:
> 
> Yes and no. I was thinking about this too.
> In general this "race" never ends.
> However:
>   - right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"
>    (Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)
> 
> We should merge head back to release for LONGINT as it is now (more consistently) implemented.
> 
>   - the "race" should actually "slow down" now that I fixed the platform list problem :)
>      but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use
>      (to be clear, the "front" group needs to be more careful about using more features;
>      for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).
> 
> Yes, I could have made use of LONGINT but didn't so as to retain cross-compilation from short to long LONGINT platforms.
> 
> I don't understand what you are saying about needing to simulate 64-bit arithmetic.  We can do that already.  I don't think the compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be surprised if that actually works.
> 
>  If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.
> They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).
> 
> That would be good too.
> 
>  
>  
>  - Jay
> 
>  
> > Date: Wed, 13 Jan 2010 10:43:03 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> > 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> > 
> > > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> > >
> > >> Also, in case anyone is interested, the current HEAD fails to 
> > >> compile the following packages on Windows Vista:
> > >> "m3-libs\m3core"
> > >> "m3-libs\libm3"
> > >> "m3-tools\m3tk"
> > >> So some recent changes have caused a problem.
> > >
> > > Did you bootstrap a new compiler? You will need to bootstrap a 
> > > compiler before you can compile the revised ORD/VAL definitions.
> > 
> > So if I understand this correctly, should we finally get to release
> > 5.8, then this compiler won't be able to compile the current trunk
> > head? That is, not unless we merge this change to the release branch?
> > 
> > Anything else that we should do for 5.8?
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 
> 
> 

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

From jay.krell at cornell.edu  Thu Jan 14 11:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 10:23:24 +0000
Subject: [M3devel] merging head m3front to release
Message-ID: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>


 > merging head m3front to release

 

The changes are big and I don't understand them right away.

Just do a wholesale copy?

(and remember related changes to m3tk and m3core)

 

A parameter got renamed lhs => traced or vice versa 

through a lot of the code, but not always. And the value

of it sometimes changed but not always.

 

 - Jay





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

From wagner at elegosoft.com  Thu Jan 14 11:56:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Jan 2010 11:56:49 +0100
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>, 
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>, 
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>, 
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
Message-ID: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 13 Jan 2010, at 16:45, Jay K wrote:
>
>> Yes and no. I was thinking about this too.
>> In general this "race" never ends.
>> However:
>>   - right this is first release with LONGINT, and I think there are  
>>  incompatibilities between head and release esp. wrt "ORD"
>>    (Had we added e.g. "assignability" and release was just a   
>> compatible subset, different; I think it is actually "incompatible".)
>
> We should merge head back to release for LONGINT as it is now (more   
> consistently) implemented.
>
>>   - the "race" should actually "slow down" now that I fixed the   
>> platform list problem :)
>>      but still, the "race" isn't guaranteeably gone; there might   
>> still be new language features that m3core/libm3 use
>>      (to be clear, the "front" group needs to be more careful about  
>>  using more features;
>>      for example, it would be "useful" for me to use LONGINT in   
>> m3back, and then build a non-NT386 hosted compiler, in order to get  
>>  LONGINT support into NT386, however my preference at the moment is  
>>  to use Target.Int to "simulate" 64bit arithmetic in the compiler   
>> ("constant folding" and such, as it already does for 32bit   
>> integers); the compiler basically supports targeting 32bit INTEGER   
>> even on a host with only 8 or 16bit INTEGER, as I understand).
>
> Yes, I could have made use of LONGINT but didn't so as to retain   
> cross-compilation from short to long LONGINT platforms.
>
> I don't understand what you are saying about needing to simulate   
> 64-bit arithmetic.  We can do that already.  I don't think the   
> compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be   
> surprised if that actually works.
>
>>  If I or anyone checks that the exception is gone now in GUI file   
>> open dialog, maybe merge those changes too.
>> They are pretty small. I haven't touched rd/wr yet (well, they were  
>>  touched *slightly*).
>
> That would be good too.

Can one of you please do the necessary merges? I had a quick look,
but there were too many commits to find the relevant things quickly.

We should try to be selective and not merge just everything though;
CVS needs two labels or dates to do those three point merges
(cvs update -j -r rev1 -r rev2; build; cvs commit).

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Jan 14 13:36:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100114123342.98F412474001@birch.elegosoft.com>
References: <20100114123342.98F412474001@birch.elegosoft.com>
Message-ID: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>


In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..

 

 

 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0008.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0009.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0010.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f7359360/attachment-0011.txt>

From jay.krell at cornell.edu  Thu Jan 14 13:37:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 12:37:45 +0000
Subject: [M3devel] longint changes to release branch
In-Reply-To: <COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
References: <20100114123342.98F412474001@birch.elegosoft.com>,
	<COL101-W5277F455BB04AD26E99BA8E66A0@phx.gbl>
Message-ID: <COL101-W251E60863732D724E2A93EE66A0@phx.gbl>


Also, I'm slightly guessing here as to what should go to release.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3commit at elegosoft.com; m3devel at elegosoft.com
Date: Thu, 14 Jan 2010 12:36:25 +0000
Subject: Re: [M3devel] [M3commit] CVS Update: cm3



In the continuing series of: cvs/cvsweb is so lame, it is way too difficult to see what any change is, diffs attached, hopefully they match the checkin..
 
 
 - Jay

 
> Date: Thu, 14 Jan 2010 13:33:42 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/14 13:33:42
> 
> Modified files:
> cm3/m3-libs/m3core/src/convert/: Tag: release_branch_cm3_5_8 
> Convert.m3 
> cm3/m3-libs/libm3/src/fmtlex/: Tag: release_branch_cm3_5_8 
> Fmt.m3 
> cm3/m3-sys/m3front/src/builtinOps/: Tag: release_branch_cm3_5_8 
> Val.m3 Ord.m3 
> cm3/m3-tools/m3tk/src/target/: Tag: release_branch_cm3_5_8 
> M3CBackEnd_Int.mg M3CBackEnd_C.m3 
> 
> Log message:
> copy LONGINT changes from head
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/8b1d6459/attachment-0002.html>

From hosking at cs.purdue.edu  Thu Jan 14 14:44:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:44:54 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>
Message-ID: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>

On 14 Jan 2010, at 05:23, Jay K wrote:

>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.

That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).

I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

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

From hosking at cs.purdue.edu  Thu Jan 14 14:45:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 08:45:27 -0500
Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
In-Reply-To: <20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
References: <20100110051218.2F3C42474001@birch.elegosoft.com>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB48@ATLEX02-SRV.SCIRES.LOCAL>,
	<73D2F123-F308-4210-9655-1F80F9A5C370@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FB5B@ATLEX02-SRV.SCIRES.LOCAL>,
	<2158B017-4405-40B6-A750-FAD2BAA88BCB@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0B@ATLEX02-SRV.SCIRES.LOCAL>,
	<26567A2B-DF4C-460C-A06C-3C534731FA53@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CD76FD0E@ATLEX02-SRV.SCIRES.LOCAL>,
	<946A720B-8819-4D55-8F26-24054CE26166@cs.purdue.edu>,
	<20100113104303.zi7q33u4gw0owkwc@mail.elegosoft.com>
	<COL101-W511B5D725816E425BCF588E66B0@phx.gbl>
	<5A7CF095-978A-48E2-ACB1-E29EB18DFF1F@cs.purdue.edu>
	<20100114115649.yvcvl3qjk0s08owo@mail.elegosoft.com>
Message-ID: <9EF41FDC-DF20-4024-99FC-ADCA6CE44BAC@cs.purdue.edu>

I won't have time for it for at least 2 weeks.

On 14 Jan 2010, at 05:56, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
>> On 13 Jan 2010, at 16:45, Jay K wrote:
>> 
>>> Yes and no. I was thinking about this too.
>>> In general this "race" never ends.
>>> However:
>>>  - right this is first release with LONGINT, and I think there are  incompatibilities between head and release esp. wrt "ORD"
>>>   (Had we added e.g. "assignability" and release was just a  compatible subset, different; I think it is actually "incompatible".)
>> 
>> We should merge head back to release for LONGINT as it is now (more  consistently) implemented.
>> 
>>>  - the "race" should actually "slow down" now that I fixed the  platform list problem :)
>>>     but still, the "race" isn't guaranteeably gone; there might  still be new language features that m3core/libm3 use
>>>     (to be clear, the "front" group needs to be more careful about  using more features;
>>>     for example, it would be "useful" for me to use LONGINT in  m3back, and then build a non-NT386 hosted compiler, in order to get  LONGINT support into NT386, however my preference at the moment is  to use Target.Int to "simulate" 64bit arithmetic in the compiler  ("constant folding" and such, as it already does for 32bit  integers); the compiler basically supports targeting 32bit INTEGER  even on a host with only 8 or 16bit INTEGER, as I understand).
>> 
>> Yes, I could have made use of LONGINT but didn't so as to retain  cross-compilation from short to long LONGINT platforms.
>> 
>> I don't understand what you are saying about needing to simulate  64-bit arithmetic.  We can do that already.  I don't think the  compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be  surprised if that actually works.
>> 
>>> If I or anyone checks that the exception is gone now in GUI file  open dialog, maybe merge those changes too.
>>> They are pretty small. I haven't touched rd/wr yet (well, they were  touched *slightly*).
>> 
>> That would be good too.
> 
> Can one of you please do the necessary merges? I had a quick look,
> but there were too many commits to find the relevant things quickly.
> 
> We should try to be selective and not merge just everything though;
> CVS needs two labels or dates to do those three point merges
> (cvs update -j -r rev1 -r rev2; build; cvs commit).
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Thu Jan 14 18:40:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 12:40:32 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
Message-ID: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 12:14, Tony Hosking wrote:

> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all

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

From rcolebur at SCIRES.COM  Thu Jan 14 20:34:24 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 14:34:24 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>

No, the only scripts I've changed are mine in scripts/dev/windows.  These don't have anything to do with Tinderbox.
Regards,
Randy

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command

Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

Randy/Jay, did you change something related to this?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484





On 14 Jan 2010, at 12:14, Tony Hosking wrote:


Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all

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

From hosking at cs.purdue.edu  Thu Jan 14 20:57:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 14:57:15 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>

Hmm.  The only other commits I've seen are Jay's.  Jay?

On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:

> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>  
> 
> 
>  
>  
> On 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  

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

From jay.krell at cornell.edu  Thu Jan 14 23:09:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:09:17 +0000
Subject: [M3devel] initializing Target.Int
In-Reply-To: <20100114135750.080852474001@birch.elegosoft.com>
References: <20100114135750.080852474001@birch.elegosoft.com>
Message-ID: <COL101-W65F274A88DB4C659B147C3E66A0@phx.gbl>


Uninitialized seems pretty much always bad.

n := 0 appears to be illegal.

 

 - Jay

 
> Date: Thu, 14 Jan 2010 14:57:50 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/14 14:57:49
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.i3 
> 
> Log message:
> This is deliberately uninitialised!
> It defaults to 0 anyway.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/afde87e9/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan 14 23:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:21:43 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
Message-ID: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>


"lastok" of the release branch, which this appears to be, was expected to fail.
(and for head was expected a few days ago)

Previous compiler can't build m3core.

Must first build compiler, then m3core.

The usual occasional problem.

 

  - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 14:57:15 -0500
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Output from "cron" command

Hmm.  The only other commits I've seen are Jay's.  Jay?




On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:



No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
Regards,
Randy
 


From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, January 14, 2010 12:41 PM
To: Tony Hosking
Cc: m3devel m3devel
Subject: Re: [M3devel] Output from "cron" command
 
Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...

 

http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419

 

Randy/Jay, did you change something related to this?

 



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 14 Jan 2010, at 12:14, Tony Hosking wrote:




Your "cron" job on niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produced the following output:

GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara release-build"

creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 06:30:09 -- checkout in progress.
[start checkout 2010.01.14 06:30:17]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
cvs return value: 0
[end checkout 2010.01.14 06:45:08]
CHECKOUT_RETURN = 0
--
2010.01.14 06:45:13 -- compile in progress.
[start compile 2010.01.14 06:45:13]
compile return value: 0
[end compile 2010.01.14 08:49:36]
COMPILE_RETURN = 0
2010.01.14 08:49:56 -- tests in progress.
[start run-tests 2010.01.14 08:49:56]
cd /tmp/build-cm3-20100114-063009-n6aGOt/build
[end run-tests 2010.01.14 11:02:11]
TESTS_RETURN = 510
*** TESTS FAILED
removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
GMAKE=gmake
export GMAKE
TAR=gtar
export TAR
TESTHOSTNAME=niagara
WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
LASTREL=5.4.0
INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=POSIX
CM3_TARGET=SOLgnu
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=birch.elegosoft.com
CM3CVSROOT=birch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"

creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt

---

checkout, compile and test of cm3 ...
2010.01.14 11:05:04 -- checkout in progress.
[start checkout 2010.01.14 11:05:06]
cd /tmp/build-cm3-20100114-110504-6ga4NN/build
cvs return value: 0
[end checkout 2010.01.14 11:20:02]
CHECKOUT_RETURN = 0
--
2010.01.14 11:20:08 -- compile in progress.
[start compile 2010.01.14 11:20:08]
compile return value: 1
[end compile 2010.01.14 12:11:12]
COMPILE_RETURN = 1
*** COMPILE FAILED
removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
cleaning CM3 workspaces...
/homes/hosking/work/cm3-ws/niagara-*
cleanup_all_but_last_n
cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05

cleaning regression test log files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning m3test log files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
cleanup_all_but_last_n
cleanup_all_but_last_n

/homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning snapshot files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
cleanup_all_but_last_n
cleanup_all_but_last_n

cleaning package reports...
/tmp/cm3-pkg-report-SOLgnu-*.html
cleanup_all_but_last_n
cleanup_all_but_last_n

done with cleanup_all
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100114/f6fcf293/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan 14 23:28:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 22:28:33 +0000
Subject: [M3devel] merging head m3front to release
In-Reply-To: <E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
Message-ID: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>


If it's just a wholesale copy, I can do that fairly easily/quickly/soon.

  Anyone can.

You are certain a wholesale copy, of all of m3front? Final answer?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 14 Jan 2010 08:44:54 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] merging head m3front to release




On 14 Jan 2010, at 05:23, Jay K wrote:


 > merging head m3front to release
 
The changes are big and I don't understand them right away.
Just do a wholesale copy?
(and remember related changes to m3tk and m3core)
 
A parameter got renamed lhs => traced or vice versa 
through a lot of the code, but not always. And the value
of it sometimes changed but not always.



That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).


I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.

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

From hosking at cs.purdue.edu  Fri Jan 15 00:22:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:22:03 -0500
Subject: [M3devel] merging head m3front to release
In-Reply-To: <COL101-W39241284420296C5E5118FE66A0@phx.gbl>
References: <COL101-W2019B50E0DF35F8C535CDE66A0@phx.gbl>,
	<E1030FA9-F099-4AE0-B947-EC128584C8FC@cs.purdue.edu>
	<COL101-W39241284420296C5E5118FE66A0@phx.gbl>
Message-ID: <E9ED6716-3CCB-4DF3-B25E-D34DF4097E16@cs.purdue.edu>

Yes.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:28, Jay K wrote:

> If it's just a wholesale copy, I can do that fairly easily/quickly/soon.
>   Anyone can.
> You are certain a wholesale copy, of all of m3front? Final answer?
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 08:44:54 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] merging head m3front to release
> 
> On 14 Jan 2010, at 05:23, Jay K wrote:
> 
>  > merging head m3front to release
>  
> The changes are big and I don't understand them right away.
> Just do a wholesale copy?
> (and remember related changes to m3tk and m3core)
>  
> A parameter got renamed lhs => traced or vice versa 
> through a lot of the code, but not always. And the value
> of it sometimes changed but not always.
> 
> That's not related to LONGINT, but is in fact a performance bug fix (eliminates a number of unnecessary GC barriers).
> 
> I won't have time to do the merge for at least a couple of weeks.  But, yes, I would plan on a wholesale copy.
> Yes, not to forget the other changes too.  I think there were a few other places where the change to using VAL for all conversions required turning ORD into VAL.
> 
> 

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

From hosking at cs.purdue.edu  Fri Jan 15 00:24:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 18:24:06 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>

I'm not sure what that implies...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 14 Jan 2010, at 17:21, Jay K wrote:

> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>  
>   - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Hmm.  The only other commits I've seen are Jay's.  Jay?
> 
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> 
> No, the only scripts I?ve changed are mine in scripts/dev/windows.  These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>  
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>  
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>  
> Randy/Jay, did you change something related to this?
>  
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> 
> 
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
> 
> produced the following output:
> 
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
> 
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
> 
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> 
> ---
> 
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> 
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
> 
> done with cleanup_all
>  
> 
> 

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

From jay.krell at cornell.edu  Fri Jan 15 00:58:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Jan 2010 23:58:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
Message-ID: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Fri Jan 15 02:10:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 01:10:33 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <COL101-W25419C91933D529A477126E6690@phx.gbl>


> What should always work actually..
 
Except that I've seen "blessed" in our Hudson process
a cm3 that just always crashes.
It happened multiple times on my SOLgnu/SOLsun machine.
I had to delete a bunch of cm3 and go back to an older one.
 
 
 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:58:33 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
> Tony you know all this.
> This email is redundant for you.
>
>
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>
>
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
>
>
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>
>
> If this works, its cm3 output can be "blessed" as "something".
>
>
>
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>
>
> Again the output can be "blessed" as "something".
>
>
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>
>
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>
>
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>
>
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>
>
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>
>
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>
>
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>
>
> - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>>
>> I'm not sure what that implies...
>>
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>>
>>
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>>
>> - Jay
>>
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Hmm. The only other commits I've seen are Jay's. Jay?
>>
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>
>> No, the only scripts I?ve changed are mine in scripts/dev/windows. These don?t have anything to do with Tinderbox.
>> Regards,
>> Randy
>>
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>
>> Randy/Jay, did you change something related to this?
>>
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>
>>
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>>
>> produced the following output:
>>
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>
>> ---
>>
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>>
>> done with cleanup_all
>>
>>
>>
>> 		 	   		  

From rcolebur at SCIRES.COM  Fri Jan 15 05:45:50 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 14 Jan 2010 23:45:50 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, ,
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>

Jay / Tony:

I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".

RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".

Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".

RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
1.  Copies some of the other scripts and documentation I use to the "bin" folder.
2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
4.  Stage-2:  Builds and ships all packages in the "front" group.
5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.

Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?

Regards,
Randy Coleburn

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, January 14, 2010 6:59 PM
To: Tony
Cc: m3devel
Subject: Re: [M3devel] Output from "cron" command


Tony you know all this.
This email is redundant for you.
 
 
A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
 
 
We have as I understand "pairs" of automated builds.
Though actually more than two could make sense.
 
 
There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
 
 
If this works, its cm3 output can be "blessed" as "something".
 
 
 
There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
 
 
Again the output can be "blessed" as "something".
 
 
Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
 
 
There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
 
 
Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
 
 
All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
 
 
This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
 
 
To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
 
 
You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
 
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 18:24:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
>
>
> I'm not sure what that implies...
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 14 Jan 2010, at 17:21, Jay K wrote:
>
> "lastok" of the release branch, which this appears to be, was expected to fail.
> (and for head was expected a few days ago)
> Previous compiler can't build m3core.
> Must first build compiler, then m3core.
> The usual occasional problem.
>
> - Jay
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm. The only other commits I've seen are Jay's. Jay?
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
> Regards,
> Randy
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
> Randy/Jay, did you change something related to this?
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree: "cm3"
> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>
>
> 		 	   		  


From hosking at cs.purdue.edu  Fri Jan 15 05:49:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 14 Jan 2010 23:49:18 -0500
Subject: [M3devel] Output from "cron" command
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>

I think so.  Jay can comment more accurately re Windows.

On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:

> Jay / Tony:
> 
> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
> 
> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
> 
> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file.  It depends on "pkgInfo.txt".
> 
> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
> 1.  Copies some of the other scripts and documentation I use to the "bin" folder.
> 2.  Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
> 3.  Stage-1:  Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
> 4.  Stage-2:  Builds and ships all packages in the "front" group.
> 5.  Stage-3:  Builds and ships a distribution.  Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
> 
> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Thursday, January 14, 2010 6:59 PM
> To: Tony
> Cc: m3devel
> Subject: Re: [M3devel] Output from "cron" command
> 
> 
> Tony you know all this.
> This email is redundant for you.
> 
> 
> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
> 
> 
> We have as I understand "pairs" of automated builds.
> Though actually more than two could make sense.
> 
> 
> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
> 
> 
> If this works, its cm3 output can be "blessed" as "something".
> 
> 
> 
> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
> 
> 
> Again the output can be "blessed" as "something".
> 
> 
> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
> 
> 
> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
> 
> 
> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
> 
> 
> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
> 
> 
> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
> 
> 
> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
> 
> 
> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> 
>> 
>> I'm not sure what that implies...
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 14 Jan 2010, at 17:21, Jay K wrote:
>> 
>> "lastok" of the release branch, which this appears to be, was expected to fail.
>> (and for head was expected a few days ago)
>> Previous compiler can't build m3core.
>> Must first build compiler, then m3core.
>> The usual occasional problem.
>> 
>> - Jay
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>> To: rcolebur at SCIRES.COM
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Hmm. The only other commits I've seen are Jay's. Jay?
>> 
>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>> 
>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>> Regards,
>> Randy
>> 
>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>> Sent: Thursday, January 14, 2010 12:41 PM
>> To: Tony Hosking
>> Cc: m3devel m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>> 
>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>> 
>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>> 
>> Randy/Jay, did you change something related to this?
>> 
>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>> 
>> 
>> Your "cron" job on niagara.cs.purdue.edu
>> $HOME/cm3/scripts/regression/cron.sh
>> 
>> produced the following output:
>> 
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>> 
>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 06:30:09 -- checkout in progress.
>> [start checkout 2010.01.14 06:30:17]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> cvs return value: 0
>> [end checkout 2010.01.14 06:45:08]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 06:45:13 -- compile in progress.
>> [start compile 2010.01.14 06:45:13]
>> compile return value: 0
>> [end compile 2010.01.14 08:49:36]
>> COMPILE_RETURN = 0
>> 2010.01.14 08:49:56 -- tests in progress.
>> [start run-tests 2010.01.14 08:49:56]
>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>> [end run-tests 2010.01.14 11:02:11]
>> TESTS_RETURN = 510
>> *** TESTS FAILED
>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> GMAKE=gmake
>> export GMAKE
>> TAR=gtar
>> export TAR
>> TESTHOSTNAME=niagara
>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>> LASTREL=5.4.0
>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>> CM3_OSTYPE=POSIX
>> CM3_TARGET=SOLgnu
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSSERVER=birch.elegosoft.com
>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>> CM3CVSUSER=
>> testing ssh birch.elegosoft.com..
>> ssh birch.elegosoft.com ok
>> Building cm3.
>> Tinderbox Tree: "cm3"
>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>> 
>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>> 
>> ---
>> 
>> checkout, compile and test of cm3 ...
>> 2010.01.14 11:05:04 -- checkout in progress.
>> [start checkout 2010.01.14 11:05:06]
>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>> cvs return value: 0
>> [end checkout 2010.01.14 11:20:02]
>> CHECKOUT_RETURN = 0
>> --
>> 2010.01.14 11:20:08 -- compile in progress.
>> [start compile 2010.01.14 11:20:08]
>> compile return value: 1
>> [end compile 2010.01.14 12:11:12]
>> COMPILE_RETURN = 1
>> *** COMPILE FAILED
>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>> cleaning CM3 workspaces...
>> /homes/hosking/work/cm3-ws/niagara-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>> 
>> cleaning regression test log files...
>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning m3test log files...
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning snapshot files...
>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> cleaning package reports...
>> /tmp/cm3-pkg-report-SOLgnu-*.html
>> cleanup_all_but_last_n
>> cleanup_all_but_last_n
>> 
>> done with cleanup_all
>> 
>> 
>> 
>> 		 	   		  



From jay.krell at cornell.edu  Fri Jan 15 07:07:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 06:07:56 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<B4F87A63-1EA7-49EF-BD54-730D3830BEB1@cs.purdue.edu>,
	<COL101-W86306C048B1B5C6FF2FC0E66A0@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E638@ATLEX02-SRV.SCIRES.LOCAL>,
	<D61E1A1D-164D-4786-914C-77B961937870@cs.purdue.edu>
Message-ID: <COL101-W18358BFDB1FF6BCB94C49DE6690@phx.gbl>


Not quite. shipping cm3 doesn't put it in the right place, so you have to "manually" copy it.
 
 
At some point I'd like to see about making that work better
but it isn't high priority.
 
 
In particular, on Windows you can rename away an in-use .exe/.dll and then copy over.
 
 
But I think I've seen the behavior on other systems that replacing in-use executables/.so files causes a "random" mix of in-memory code/data and crashes. (And I know Windows is usually criticized for not letting you replace "running code", but the reality is more lenient than people realize, the reality of allowing such things is far more complicated than people realize (how do I ensure the old version eventually is not used?) and I believe other systems have similar or more stringent restrictions, e.g. AIX).
 
 
We should probably make shipping in cminstall put the configuration files in place or somesuch, instead of leaving it to all the scripts.
There is a tension in that programming in Python being much easier and more pleasant than any of the alternatives such as Modula-3 or Quake..
 
 
Anyway, I just use the *.py files, on Linux, Darwin, NT, OpenBSD, FreeBSD, NetBSD, Solaris, etc. (MIPS64_OPENBSD so far I don't have Python for, it's like the only one).
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 23:49:18 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] Output from "cron" command
>
> I think so. Jay can comment more accurately re Windows.
>
> On 14 Jan 2010, at 23:45, Coleburn, Randy wrote:
>
>> Jay / Tony:
>>
>> I have tried to capture this scenario in my latest scripts in "scripts/dev/windows".
>>
>> RCC_upgrade.cmd is my version of Jay's upgrade.py, but it uses Windows CMD files only; no python dependencies, AND it parses "pkgInfo.txt".
>>
>> Do-cm3.cmd is my version of the various "do.sh" scripts rolled up into one CMD file. It depends on "pkgInfo.txt".
>>
>> RCC_upgrade.cmd assumes you have a working cm3 installation, then does the following:
>> 1. Copies some of the other scripts and documentation I use to the "bin" folder.
>> 2. Copies all the cm3.cfg config stuff set up by Jay to the appropriate places.
>> 3. Stage-1: Builds and Ships all packages in the "front" group, except for "m3core", "libm3", and "mklib".
>> 4. Stage-2: Builds and ships all packages in the "front" group.
>> 5. Stage-3: Builds and ships a distribution. Default is the "min" group, but you can use the "-all" parameter to build everything, i.e., a complete distribution.
>>
>> Jay, do these 5 points reliably and succinctly express what you are saying; or am I missing something else?
>>
>> Regards,
>> Randy Coleburn
>>
>> -----Original Message-----
>> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
>> Sent: Thursday, January 14, 2010 6:59 PM
>> To: Tony
>> Cc: m3devel
>> Subject: Re: [M3devel] Output from "cron" command
>>
>>
>> Tony you know all this.
>> This email is redundant for you.
>>
>>
>> A near current release_branch cm3 cannot build a current release_branch m3core, due to the VAL changes regarding LONGINT. A current release_branch cm3 can.
>>
>>
>> We have as I understand "pairs" of automated builds.
>> Though actually more than two could make sense.
>>
>>
>> There is the variety that starts with the "last release", builds "up to cm3" but skipping m3core/libm3, and then I guess rebuilds "up to cm3" with the new cm3 not skipping m3core/libm3, and then builds reverything. (possibly the second step is skipped).
>>
>>
>> If this works, its cm3 output can be "blessed" as "something".
>>
>>
>>
>> There is the variety or varieties that starts with the most recent "blessed "something" and either does the same process, or never skips libm3/m3core.
>>
>>
>> Again the output can be "blessed" as "something".
>>
>>
>> Whatever succeeds should be identical, so there isn't a need to "bless" all the outputs. However there can be failures.
>>
>>
>> There are so many of these "somethings"; I don't know what they are called. I also hadn't thought through one of the points until just now: that keeping all the outputs is redundant, but you aren't guaranteed which ones you'll get.
>>
>>
>> Hm. What should always work actually, is starting with the "latest blessed something", and *skip* m3core/libm3.
>>
>>
>> All this is to say, that, neither the "latest (or older) release" nor the "latest build" can guaranteeably build latest m3core/libm3.
>>
>>
>> This varies in time, but the typical problem with "releases" is lack of LONGINT. The current problem with recent builds is VAL.
>>
>>
>> To further try to summarize, there should probably be *three* recurring builds of each architecture. However, you don't really have to always do all three, you can "fallback" in case of failure. In particular, if you are starting with "latest build", you would first try building m3core and libm3. If that succeeds proceeds -- ship them. If that fails, well, you still proceed, but you remember to do another go around, which maybe you want to do anyway (builds are so fast on NT386 anyway, throw in a few extra :) )
>>
>>
>> You know all this already, I know, but maybe my attempt to summarize yet again will help spread the word. It is not the easiest thing to understand.
>>
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 18:24:06 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>>
>>>
>>> I'm not sure what that implies...
>>>
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 14 Jan 2010, at 17:21, Jay K wrote:
>>>
>>> "lastok" of the release branch, which this appears to be, was expected to fail.
>>> (and for head was expected a few days ago)
>>> Previous compiler can't build m3core.
>>> Must first build compiler, then m3core.
>>> The usual occasional problem.
>>>
>>> - Jay
>>>
>>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 14 Jan 2010 14:57:15 -0500
>>> To: rcolebur at SCIRES.COM
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Hmm. The only other commits I've seen are Jay's. Jay?
>>>
>>> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>>>
>>> No, the only scripts I've changed are mine in scripts/dev/windows. These don't have anything to do with Tinderbox.
>>> Regards,
>>> Randy
>>>
>>> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
>>> Sent: Thursday, January 14, 2010 12:41 PM
>>> To: Tony Hosking
>>> Cc: m3devel m3devel
>>> Subject: Re: [M3devel] Output from "cron" command
>>>
>>> Looks like the change in the last 24 hours to the build scripts results in improper bootstrapping of the compiler...
>>>
>>> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>>>
>>> Randy/Jay, did you change something related to this?
>>>
>>> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>>>
>>>
>>> Your "cron" job on niagara.cs.purdue.edu
>>> $HOME/cm3/scripts/regression/cron.sh
>>>
>>> produced the following output:
>>>
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 06:30:09 -- checkout in progress.
>>> [start checkout 2010.01.14 06:30:17]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 06:45:08]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 06:45:13 -- compile in progress.
>>> [start compile 2010.01.14 06:45:13]
>>> compile return value: 0
>>> [end compile 2010.01.14 08:49:36]
>>> COMPILE_RETURN = 0
>>> 2010.01.14 08:49:56 -- tests in progress.
>>> [start run-tests 2010.01.14 08:49:56]
>>> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
>>> [end run-tests 2010.01.14 11:02:11]
>>> TESTS_RETURN = 510
>>> *** TESTS FAILED
>>> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>> GMAKE=gmake
>>> export GMAKE
>>> TAR=gtar
>>> export TAR
>>> TESTHOSTNAME=niagara
>>> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
>>> LASTREL=5.4.0
>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
>>> CM3_OSTYPE=POSIX
>>> CM3_TARGET=SOLgnu
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSSERVER=birch.elegosoft.com
>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
>>> CM3CVSUSER=
>>> testing ssh birch.elegosoft.com..
>>> ssh birch.elegosoft.com ok
>>> Building cm3.
>>> Tinderbox Tree: "cm3"
>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
>>>
>>> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>>>
>>> ---
>>>
>>> checkout, compile and test of cm3 ...
>>> 2010.01.14 11:05:04 -- checkout in progress.
>>> [start checkout 2010.01.14 11:05:06]
>>> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
>>> cvs return value: 0
>>> [end checkout 2010.01.14 11:20:02]
>>> CHECKOUT_RETURN = 0
>>> --
>>> 2010.01.14 11:20:08 -- compile in progress.
>>> [start compile 2010.01.14 11:20:08]
>>> compile return value: 1
>>> [end compile 2010.01.14 12:11:12]
>>> COMPILE_RETURN = 1
>>> *** COMPILE FAILED
>>> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
>>> cleaning CM3 workspaces...
>>> /homes/hosking/work/cm3-ws/niagara-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>>>
>>> cleaning regression test log files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning m3test log files...
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning snapshot files...
>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> cleaning package reports...
>>> /tmp/cm3-pkg-report-SOLgnu-*.html
>>> cleanup_all_but_last_n
>>> cleanup_all_but_last_n
>>>
>>> done with cleanup_all
>>>
>>>
>>>
>>>
> 		 	   		  

From wagner at elegosoft.com  Fri Jan 15 10:05:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 15 Jan 2010 10:05:09 +0100
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>, 
	<3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>
Message-ID: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> "lastok" of the release branch, which this appears to be, was   
> expected to fail.
> (and for head was expected a few days ago)
>
> Previous compiler can't build m3core.
>
> Must first build compiler, then m3core.
>
> The usual occasional problem.

The release-builds fail, too.

Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
AMD64_LINUX has no previous release, it needs to be fixed manually.
I expect SOLgnu on Niagara to fail soon, too.

The upgrade.sh script should take care for all problems encountered
during bootstrapping a (slightly) incompatible compiler.

In  
http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846

it fails with a quake error though:

5369           
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh  
upgrade
5370          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
5371          cp  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
5372  NEXT    quake runtime error:  
"/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line  
13: quake runtime error: undefined variable: M3_PROFILING
5373
5374          --procedure--  -line-  -file---
5375                             13   
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
5376          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
5377          cp  
/pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg  
/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5

Later libm3 cannot be compiled due to errors in FilePosix.

Error reporting should definitely be better here, but it's unlikely that
I find the time to do that soon.

Olaf


>   - Jay
>
> From: hosking at cs.purdue.edu
> Date: Thu, 14 Jan 2010 14:57:15 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
>
> Hmm.  The only other commits I've seen are Jay's.  Jay?
>
>
>
>
> On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
>
>
>
> No, the only scripts I?ve changed are mine in scripts/dev/windows.    
> These don?t have anything to do with Tinderbox.
> Regards,
> Randy
>
>
>
> From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> Sent: Thursday, January 14, 2010 12:41 PM
> To: Tony Hosking
> Cc: m3devel m3devel
> Subject: Re: [M3devel] Output from "cron" command
>
> Looks like the change in the last 24 hours to the build scripts   
> results in improper bootstrapping of the compiler...
>
>
>
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
>
>
>
> Randy/Jay, did you change something related to this?
>
>
>
>
>
> 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
>
>
>
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 06:30:09 -- checkout in progress.
> [start checkout 2010.01.14 06:30:17]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> cvs return value: 0
> [end checkout 2010.01.14 06:45:08]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 06:45:13 -- compile in progress.
> [start compile 2010.01.14 06:45:13]
> compile return value: 0
> [end compile 2010.01.14 08:49:36]
> COMPILE_RETURN = 0
> 2010.01.14 08:49:56 -- tests in progress.
> [start run-tests 2010.01.14 08:49:56]
> cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> [end run-tests 2010.01.14 11:02:11]
> TESTS_RETURN = 510
> *** TESTS FAILED
> removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n   
> /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
> GMAKE=gmake
> export GMAKE
> TAR=gtar
> export TAR
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSUSER=
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2010.01.14 11:05:04 -- checkout in progress.
> [start checkout 2010.01.14 11:05:06]
> cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> cvs return value: 0
> [end checkout 2010.01.14 11:20:02]
> CHECKOUT_RETURN = 0
> --
> 2010.01.14 11:20:08 -- compile in progress.
> [start compile 2010.01.14 11:20:08]
> compile return value: 1
> [end compile 2010.01.14 12:11:12]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
> cleanup_all_but_last_n
> cleanup_all_but_last_n
>
> done with cleanup_all
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Jan 15 12:17:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:17:59 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W48219CDFF89BDE026F09A1E6690@phx.gbl>


ps: the thing do is also what I alluded to:

 

use a "latest" build, but skip m3core/libm3.

 

 

 - Jay


 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] Output from "cron" command
Date: Fri, 15 Jan 2010 11:16:45 +0000



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/875a534f/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 15 12:16:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>, ,
	<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>
Message-ID: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>


Interestingly, my upgrade.py goes ahead and foists current configuration files any

old compiler. I've definitely spent some time working around problems

with older compilers in the current configurations.

And older compilers definitely don't always have a good configuration,

so replacing it is not a bad idea.

 

 

That said, this isn't that big a deal. The scripts

prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/cb7ffe36/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 15 13:16:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 12:16:04 +0000
Subject: [M3devel] Output from "cron" command
In-Reply-To: <COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
References: <201001141714.o0EHEWBA020043@niagara.cs.purdue.edu>,
	,,<16B45315-1134-4EC9-9623-C716F5D6D055@cs.purdue.edu>, , ,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E5C7@ATLEX02-SRV.SCIRES.LOCAL>,
	, , <3A9D448E-FD12-453E-B5D7-523DDBFBB8A5@cs.purdue.edu>, ,
	<COL101-W5E59ABD6575C70A027D6AE66A0@phx.gbl>, ,
	<20100115100509.kmhcwu8hn4cw8gs8@mail.elegosoft.com>,
	<COL101-W407234DFB02ADC5113172CE6690@phx.gbl>
Message-ID: <COL101-W69543449C8565130D44A9E6690@phx.gbl>


well, I did something else instead; let's see how it goes

 

 - Jay

 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 11:16:45 +0000
Subject: Re: [M3devel] Output from "cron" command



Interestingly, my upgrade.py goes ahead and foists current configuration files any
old compiler. I've definitely spent some time working around problems
with older compilers in the current configurations.
And older compilers definitely don't always have a good configuration,
so replacing it is not a bad idea.
 
 
That said, this isn't that big a deal. The scripts
prepend if not defined("M3_PROFILING") M3_PROFILING = FALSE end
to the config, or maybe -DM3_PROFILING=FALSE.
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 10:05:09 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Output from "cron" command
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > "lastok" of the release branch, which this appears to be, was 
> > expected to fail.
> > (and for head was expected a few days ago)
> >
> > Previous compiler can't build m3core.
> >
> > Must first build compiler, then m3core.
> >
> > The usual occasional problem.
> 
> The release-builds fail, too.
> 
> Tinderbox shows the same problem for FreeBSD and I386_DARWIN.
> AMD64_LINUX has no previous release, it needs to be fixed manually.
> I expect SOLgnu on Niagara to fail soon, too.
> 
> The upgrade.sh script should take care for all problems encountered
> during bootstrapping a (slightly) incompatible compiler.
> 
> In 
> http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1263530987.11846
> 
> it fails with a quake error though:
> 
> 5369 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/scripts/install-cm3-compiler.sh 
> upgrade
> 5370 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-5.4.0
> 5371 cp 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-5.4.0
> 5372 NEXT quake runtime error: 
> "/pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg", line 
> 13: quake runtime error: undefined variable: M3_PROFILING
> 5373
> 5374 --procedure-- -line- -file---
> 5375 13 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3.cfg
> 5376 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/cm3/FreeBSD4/cm3 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3-pre-5.8.5
> 5377 cp 
> /pub/users/m3/work/cm3-ws/new.elego.de-2010-01-15-03-21-10/cm3/m3-sys/m3cc/FreeBSD4/cm3cg 
> /pub/users/m3/work/cm3-inst/new.elego.de/current/bin/cm3cg-pre-5.8.5
> 
> Later libm3 cannot be compiled due to errors in FilePosix.
> 
> Error reporting should definitely be better here, but it's unlikely that
> I find the time to do that soon.
> 
> Olaf
> 
> 
> > - Jay
> >
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Jan 2010 14:57:15 -0500
> > To: rcolebur at SCIRES.COM
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Hmm. The only other commits I've seen are Jay's. Jay?
> >
> >
> >
> >
> > On 14 Jan 2010, at 14:34, Coleburn, Randy wrote:
> >
> >
> >
> > No, the only scripts I?ve changed are mine in scripts/dev/windows. 
> > These don?t have anything to do with Tinderbox.
> > Regards,
> > Randy
> >
> >
> >
> > From: Tony Hosking [mailto:hosking at cs.purdue.edu]
> > Sent: Thursday, January 14, 2010 12:41 PM
> > To: Tony Hosking
> > Cc: m3devel m3devel
> > Subject: Re: [M3devel] Output from "cron" command
> >
> > Looks like the change in the last 24 hours to the build scripts 
> > results in improper bootstrapping of the compiler...
> >
> >
> >
> > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&full-log=1263489074.21419
> >
> >
> >
> > Randy/Jay, did you change something related to this?
> >
> >
> >
> >
> >
> > 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 14 Jan 2010, at 12:14, Tony Hosking wrote:
> >
> >
> >
> >
> > Your "cron" job on niagara.cs.purdue.edu
> > $HOME/cm3/scripts/regression/cron.sh
> >
> > produced the following output:
> >
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-11-30-07
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara release-build"
> >
> > creating log file /tmp/build-cm3-20100114-063009-n6aGOt/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 06:30:09 -- checkout in progress.
> > [start checkout 2010.01.14 06:30:17]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > cvs return value: 0
> > [end checkout 2010.01.14 06:45:08]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 06:45:13 -- compile in progress.
> > [start compile 2010.01.14 06:45:13]
> > compile return value: 0
> > [end compile 2010.01.14 08:49:36]
> > COMPILE_RETURN = 0
> > 2010.01.14 08:49:56 -- tests in progress.
> > [start run-tests 2010.01.14 08:49:56]
> > cd /tmp/build-cm3-20100114-063009-n6aGOt/build
> > [end run-tests 2010.01.14 11:02:11]
> > TESTS_RETURN = 510
> > *** TESTS FAILED
> > removing build tree /tmp/build-cm3-20100114-063009-n6aGOt ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-11-16-05-08
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n 
> > /homes/hosking/tmp/cm3/niagara/m3tests-2010-01-09-11-30-05.stderr.extract
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> > GMAKE=gmake
> > export GMAKE
> > TAR=gtar
> > export TAR
> > TESTHOSTNAME=niagara
> > WS=/homes/hosking/work/cm3-ws/niagara-2010-01-14-16-05-02
> > LASTREL=5.4.0
> > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> > CM3_OSTYPE=POSIX
> > CM3_TARGET=SOLgnu
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSSERVER=birch.elegosoft.com
> > CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> > CM3CVSUSER=
> > testing ssh birch.elegosoft.com..
> > ssh birch.elegosoft.com ok
> > Building cm3.
> > Tinderbox Tree: "cm3"
> > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build"
> >
> > creating log file /tmp/build-cm3-20100114-110504-6ga4NN/log.txt
> >
> > ---
> >
> > checkout, compile and test of cm3 ...
> > 2010.01.14 11:05:04 -- checkout in progress.
> > [start checkout 2010.01.14 11:05:06]
> > cd /tmp/build-cm3-20100114-110504-6ga4NN/build
> > cvs return value: 0
> > [end checkout 2010.01.14 11:20:02]
> > CHECKOUT_RETURN = 0
> > --
> > 2010.01.14 11:20:08 -- compile in progress.
> > [start compile 2010.01.14 11:20:08]
> > compile return value: 1
> > [end compile 2010.01.14 12:11:12]
> > COMPILE_RETURN = 1
> > *** COMPILE FAILED
> > removing build tree /tmp/build-cm3-20100114-110504-6ga4NN ...
> > cleaning CM3 workspaces...
> > /homes/hosking/work/cm3-ws/niagara-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2010-01-12-11-30-05
> >
> > cleaning regression test log files...
> > /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning m3test log files...
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning snapshot files...
> > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > cleaning package reports...
> > /tmp/cm3-pkg-report-SOLgnu-*.html
> > cleanup_all_but_last_n
> > cleanup_all_but_last_n
> >
> > done with cleanup_all
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/efb1e269/attachment-0002.html>

From hosking at cs.purdue.edu  Fri Jan 15 17:51:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 11:51:18 -0500
Subject: [M3devel] Oops, forgot to ask
In-Reply-To: <4B2965B7.6040304@lcwb.coop>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>
	<4B2965B7.6040304@lcwb.coop>
Message-ID: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>

I just dug this correspondence out of my pile and realised that we still don't have LONGCARD.  This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines.  I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3.  Might as well do it now instead of later, so the pain is not dragged out over time.

On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
>> 
>>  
>>> Hi Gang,
>>> 
>>> 0 - CARDINALs are an integral type defined by the language
>>> spec to be from 0 (zero) to MAXINT (not MAXCARD).  Recently,
>>> a change was made to CM3 to extend the language it recognizes
>>> beyond the original language spec (SPWM3), now CM3 understands
>>> a LONGINT.  
>>> Was there a corresponding LONGCARD defined?
>>>    
>> 
>> No.  But you can write:
>> 
>> [0L..LAST(LONGINT)]
>> 
>> just as
>> 
>> CARDINAL=[0..LAST(INTEGER)]
>>  
> Actually, the line above was once true, long long ago, when dinosaurs
> roamed unfettered.  CARDINAL was changed to be "just like"
> (but not equal to) [0..LAST(INTEGER)].  This would have been
> maybe early 1990s. 
> It took me years to figure out what this actually meant, and more
> years to figure out why, but I believe I now know.  CARDINAL is not an
> equal type to [0..LAST(INTEGER)], but otherwise has all the same
> properties.  This makes the two mutually assignable, which is close
> enough to equal to not matter in most contexts.  The exact consequences
> follow from other language rules. 
> The motivation is this:  [0..LAST(INTEGER)] on a 32-bit machine is not
> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> machines with different values of LAST(INTEGER)), because the numeric
> value of LAST(INTEGER) is part of the expanded type.  The one place this
> matters is if you use pickles to transfer data between machines of different
> word sizes.  If the type is [0..LAST(INTEGER)], the type signature (a hash
> of the complete, expanded type definition) is different on the two machines,
> and values of or containing this type cannot be transferred.  Exact type
> signature matches are used in pickles to find corresponding types when
> reading. 
> But pickles handle different sized INTEGER values fine, expanding/shortening
> as needed.  Being a leaf in a type definition, INTEGER is always the same
> type on any machine.  So CARDINAL was changed to be its own unique
> type too, so it would be possible also to transfer CARDINAL values in pickles
> between different word sizes. 
> So, we really should have a LONGCARD, parallel to CARDINAL.
> 
> Note that this also affects network objects, which use pickles to transfer
> values of the objects.
> 
> 
>> 
>>  
>>> Can is use all 64-bits, or is it restricted to 63, like
>>> the CARDINAL is only 31-bits.
>>>    
>> 
>> 63 bits, since its underlying base type is LONGINT.
>> 
>> 
>>  
>>> 
>>> 
>>> 
>>> +--------------------------------------------------------+
>>> | Peter P. Eiserloh                                      |
>>> +--------------------------------------------------------+
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>  



From jay.krell at cornell.edu  Fri Jan 15 21:53:51 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:53:51 +0000
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
Message-ID: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>


I know. But see here from 2001:

 

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2



Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.

 

It seems some of the 4.1/5.1 changes never made it from a branch to head??


 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:04:48 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> 
> *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> ***************
> *** 236,241 ****
> --- 236,242 ----
> 
> PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> RAISES {OSError.E} =
> + VAR log: TEXT;
> BEGIN
> IF NOT lm.recoverable(nm) THEN
> RAISE OSError.E(
> ***************
> *** 243,253 ****
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! IF TestFile(lm.logfn(nm)) THEN
> ! RETURN FS.Status(nm).size > 0
> ! ELSE
> ! RETURN TRUE
> ! END;
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> --- 244,251 ----
> Atom.FromText(
> "no checkpointfile for log in " & nm)));
> END;
> ! log := lm.logfn(nm);
> ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> END EmptyLog;
> 
> PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> 
> 
> On 15 Jan 2010, at 13:03, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 13:03:10
> > 
> > Modified files:
> > cm3/m3-db/stable/src/: LogManager.m3 
> > 
> > Log message:
> > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/62e18b50/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 15 21:57:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 20:57:58 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
 file size on 32bit platform)
In-Reply-To: <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
Message-ID: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>


I at least did move the hacks to one place.

I agree it isn't nice.

This is due to my changes, not yours -- changing File.T.status().size to LONGINT.

There's no way to use that in the "compiler" and still support old compiler/libm3, right?

Ok now that I centralized it to sysutils?

 

 

Leave status() alone as using INTEGER and introduce statusL()?

 

 

Or leave size alone and introduce sizeL?

 That's not a complete solution because you have to set size to something.

  -1 if it doesn't fit?

 

 

Or just get past the bootstrapping and put it back using VAL?

It seems a tough situation..the compiler is otherwise I believe

very compatible with old compiler/libm3.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/870c16bb/attachment-0002.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:08:59 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:08:59 -0500
Subject: [M3devel] question on cm3 versioning & dating
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7B8@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

When running upgrade.py, the compiler gets invoked as follows on my system:

C:\cm3\bin\cm3.exe  -build -DROOT=C:/cm3/Sandbox -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15

I also note that the "cm3 -version" option currently produces the following:

Critical Mass Modula-3 version d5.8.2
  last updated: 2009-07-15
  compiled: 2010-01-13 02:33:39
  configuration: C:\cm3\bin\cm3.cfg
  host: NT386
defaulting to native build: NT386
  target: NT386

Questions:


1.       What is purpose of the various "-DCM3..." arguments and should these be changing based on some formula or rule?


2.       I note that when compiling "cm3" package, I get complaints about missing version file information.  What should I be doing to correct this, if anything?  See below:

missing CM3_VERSION_NUMBER will read version file
missing CM3_VERSION_TEXT will read version file
missing CM3_LAST_CHANGED will read version file

It would seem that these three items have some parallel to the "-DCM3..." arguments.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/88197ea8/attachment-0002.html>

From hosking at cs.purdue.edu  Fri Jan 15 22:17:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:17:15 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>
Message-ID: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>

On 15 Jan 2010, at 15:57, Jay K wrote:

> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?

Yes.

> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.

It very soon will not be.

>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 

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

From hosking at cs.purdue.edu  Fri Jan 15 22:20:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 16:20:03 -0500
Subject: [M3devel] LogManager.EmptyLog FS.Status(nm) vs.
	FS.Status(logfn(nm))
In-Reply-To: <COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
References: <20100115120311.0B4B32474001@birch.elegosoft.com>,
	<9CD84849-55B8-4F3D-A5CD-A415337C3807@cs.purdue.edu>
	<COL101-W174DBEF3D9C5B9DF5AAA3E6690@phx.gbl>
Message-ID: <9CA89F2F-4065-480D-A20C-87B983CE511B@cs.purdue.edu>

Aha!  Weird!  I'll leave it alone.

On 15 Jan 2010, at 15:53, Jay K wrote:

> I know. But see here from 2001:
>  
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-db/stable/src/LogManager.m3.diff?r1=1.1.1.1;r2=1.1.1.2
> 
> 
> Something is wierd here, I agree. I think I somehow had the 1.1.1.2 version (odd), and if you look through all the other uses of TestFile, I think it is more correct.
>  
> It seems some of the 4.1/5.1 changes never made it from a branch to head??
> 
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:04:48 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Here's the diff between 1.1 and 1.2, which you committed. You seem to have changed the meaning. I don't understand the change.
> > 
> > *** LogManager.m3.~1.1~ Thu Jan 14 13:56:42 2010
> > --- LogManager.m3.~1.2~ Fri Jan 15 09:59:41 2010
> > ***************
> > *** 236,241 ****
> > --- 236,242 ----
> > 
> > PROCEDURE EmptyLog (lm: Default; nm: Pathname.T): BOOLEAN
> > RAISES {OSError.E} =
> > + VAR log: TEXT;
> > BEGIN
> > IF NOT lm.recoverable(nm) THEN
> > RAISE OSError.E(
> > ***************
> > *** 243,253 ****
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! IF TestFile(lm.logfn(nm)) THEN
> > ! RETURN FS.Status(nm).size > 0
> > ! ELSE
> > ! RETURN TRUE
> > ! END;
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > --- 244,251 ----
> > Atom.FromText(
> > "no checkpointfile for log in " & nm)));
> > END;
> > ! log := lm.logfn(nm);
> > ! RETURN (NOT TestFile(log)) OR (FS.Status(log).size = 0L);
> > END EmptyLog;
> > 
> > PROCEDURE Dispose (lm: Default; nm: Pathname.T) RAISES {OSError.E} =
> > 
> > 
> > On 15 Jan 2010, at 13:03, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 13:03:10
> > > 
> > > Modified files:
> > > cm3/m3-db/stable/src/: LogManager.m3 
> > > 
> > > Log message:
> > > something is broken in the history here: put my version back, there is a semantic difference as to which file path is passed to FS.Status and I didn't invent the 'obfuscated' form, though the history is indeed confusing (did somebody mention that cvs and cvsweb don't work well?)
> > 



From jay.krell at cornell.edu  Fri Jan 15 22:34:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:34:11 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
Message-ID: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>


We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.

That is more ok for m3core, less ok for cm3/m3quake.

As well, m3core also couldn't be built with recent but slightly old compiler.

    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).

    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.

 

 

The sysutils/m3quake/cm3 changes should stand?

Ok removing "32" from the name and letting it return >4GB on 64bit platforms.

But I think either it can't use libm3.File.T.status().size, OR we have to

make status().size more compatible such as by introducing statusL or sizeL.

32bit code wouldn't see >4GB file sizes unless actively changed.

Maybe not a bad idea.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 

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

From rcolebur at SCIRES.COM  Fri Jan 15 22:45:42 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Not sure about your statement that recent cm3.exe can't be used to bootstrap new compiler.

I haven't done an update in last 2 days, but up until then, I've been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.

Are you saying that if I get current update (I'm only a couple of days out of sync with HEAD) that I won't be able to bootstrap anymore?

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.


The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.


 - Jay


________________________________
From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
On 15 Jan 2010, at 15:57, Jay K wrote:

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

Ok now that I centralized it to sysutils?


Leave status() alone as using INTEGER and introduce statusL()?


Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?


Or just get past the bootstrapping and put it back using VAL?

Yes.

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

It very soon will not be.



 - Jay


> From: hosking at cs.purdue.edu<mailto:hosking at cs.purdue.edu>
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de<mailto:jkrell at elego.de>
> CC: m3commit at elegosoft.com<mailto:m3commit at elegosoft.com>
> Subject: Re: [M3commit] CVS Update: cm3
>
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
>
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
>
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> >
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
> > m3makefile
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c
> >
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
>

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

From jay.krell at cornell.edu  Fri Jan 15 22:46:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:46:48 +0000
Subject: [M3devel] Oops, forgot to ask (LONGCARD)
In-Reply-To: <A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
References: <351872.44455.qm@web56806.mail.re3.yahoo.com>,
	<1F930CD2-8B8C-4AF2-A93E-172309FFA306@cs.purdue.edu>,
	<4B2965B7.6040304@lcwb.coop>,
	<A62A1655-E8A8-438D-B1EB-637D7E92A23D@cs.purdue.edu>
Message-ID: <COL101-W161A9EA86E5E2209FDC950E6690@phx.gbl>


sysutils.GetFileSize use by the compiler should help.

And still I'm open to introducing statusL() or sizeL and leaving status()/size as INTEGER.

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 11:51:18 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Oops, forgot to ask
> 
> I just dug this correspondence out of my pile and realised that we still don't have LONGCARD. This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines. I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3. Might as well do it now instead of later, so the pain is not dragged out over time.
> 
> On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:
> 
> > Tony Hosking wrote:
> >> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
> >> 
> >> 
> >>> Hi Gang,
> >>> 
> >>> 0 - CARDINALs are an integral type defined by the language
> >>> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,
> >>> a change was made to CM3 to extend the language it recognizes
> >>> beyond the original language spec (SPWM3), now CM3 understands
> >>> a LONGINT. 
> >>> Was there a corresponding LONGCARD defined?
> >>> 
> >> 
> >> No. But you can write:
> >> 
> >> [0L..LAST(LONGINT)]
> >> 
> >> just as
> >> 
> >> CARDINAL=[0..LAST(INTEGER)]
> >> 
> > Actually, the line above was once true, long long ago, when dinosaurs
> > roamed unfettered. CARDINAL was changed to be "just like"
> > (but not equal to) [0..LAST(INTEGER)]. This would have been
> > maybe early 1990s. 
> > It took me years to figure out what this actually meant, and more
> > years to figure out why, but I believe I now know. CARDINAL is not an
> > equal type to [0..LAST(INTEGER)], but otherwise has all the same
> > properties. This makes the two mutually assignable, which is close
> > enough to equal to not matter in most contexts. The exact consequences
> > follow from other language rules. 
> > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not
> > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> > machines with different values of LAST(INTEGER)), because the numeric
> > value of LAST(INTEGER) is part of the expanded type. The one place this
> > matters is if you use pickles to transfer data between machines of different
> > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash
> > of the complete, expanded type definition) is different on the two machines,
> > and values of or containing this type cannot be transferred. Exact type
> > signature matches are used in pickles to find corresponding types when
> > reading. 
> > But pickles handle different sized INTEGER values fine, expanding/shortening
> > as needed. Being a leaf in a type definition, INTEGER is always the same
> > type on any machine. So CARDINAL was changed to be its own unique
> > type too, so it would be possible also to transfer CARDINAL values in pickles
> > between different word sizes. 
> > So, we really should have a LONGCARD, parallel to CARDINAL.
> > 
> > Note that this also affects network objects, which use pickles to transfer
> > values of the objects.
> > 
> > 
> >> 
> >> 
> >>> Can is use all 64-bits, or is it restricted to 63, like
> >>> the CARDINAL is only 31-bits.
> >>> 
> >> 
> >> 63 bits, since its underlying base type is LONGINT.
> >> 
> >> 
> >> 
> >>> 
> >>> 
> >>> 
> >>> +--------------------------------------------------------+
> >>> | Peter P. Eiserloh |
> >>> +--------------------------------------------------------+
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/4286c96a/attachment-0002.html>

From rcolebur at SCIRES.COM  Fri Jan 15 22:49:06 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
References: <20100115212846.B78742474001@birch.elegosoft.com>
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Can you explain why?

I haven't noticed this problem on Windows.

Perhaps are you suggesting that since cm3.exe is currently executing the -ship directive that Windows won't replace the .exe file while in use?  In general, for these type of problems I've always gotten a pop-up warning that file was in use.  I don't get such an error in this case though.

Regards,
Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3

In fact -ship never puts cm3.exe in the right place.

 - Jay



> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
>
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd
>
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b3ca8a42/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 15 22:53:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:53:00 +0000
Subject: [M3devel] installing cm3.exe.
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115212846.B78742474001@birch.elegosoft.com>,
	<COL101-W35A6D6F4557EB8E3E61CF7E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W656107CB255BC695B02F6EE6690@phx.gbl>


Because it is likely to fail, we don't even try.

 

 

See m3-sys/cm3/src/m3makefile:

 

 

% Some platforms do not allow overwriting binaries that are currently
% executed, hence the default is not to install the cm3 binary in place.
% This also saves the user from accidentally overwriting the currently
% used compiler. To install the binary, you can either use the
% install-cm3-compiler script from the scripts/ directory or set the
% INSTALL_CM3_IN_BIN environment variable to "yes".
if equal($INSTALL_CM3_IN_BIN, "yes")
Program ("cm3")
else
program ("cm3")
end


 

You wouldn't get a popup for this, you'd just get an error.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:49:06 -0500
Subject: Re: [M3devel] [M3commit] CVS Update: cm3





Jay:
 
Can you explain why?
 
I haven?t noticed this problem on Windows.
 
Perhaps are you suggesting that since cm3.exe is currently executing the ?ship directive that Windows won?t replace the .exe file while in use?  In general, for these type of problems I?ve always gotten a pop-up warning that file was in use.  I don?t get such an error in this case though.
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:38 PM
To: Coleburn, Randy
Subject: RE: [M3commit] CVS Update: cm3
 
In fact -ship never puts cm3.exe in the right place.
 
 - Jay


 
> Date: Fri, 15 Jan 2010 22:28:46 +0000
> To: m3commit at elegosoft.com
> From: rcoleburn at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: rcoleburn at birch. 10/01/15 22:28:46
> 
> Modified files:
> cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd 
> 
> Log message:
> 01/15/2010, R.Coleburn, add extra checks at end of each stage to ensure new cm3.exe was produced and copied to target bin folder. All this per Jay's assertion that -ship doesn't always result in cm3.exe getting copied to the "bin" folder.
>  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/d5965c5c/attachment-0002.html>

From Highjinks at gmx.com  Fri Jan 15 22:46:53 2010
From: Highjinks at gmx.com (Highjinks at gmx.com)
Date: Fri, 15 Jan 2010 16:46:53 -0500
Subject: [M3devel] Hello m3devel.
Message-ID: <20100115214653.129010@gmx.com>


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

From jay.krell at cornell.edu  Fri Jan 15 22:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:56:19 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <20100115215118.A9F482474001@birch.elegosoft.com>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
Message-ID: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>


VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,

but I think what I had is the way to go.

The bootstrapping pain is otherwise novel.

The compiler doesn't otherwise use LONGINT.

 (My doing that it started using it.)

It ought not until after the current release?

 

 

 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/f54804b0/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 15 22:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 21:50:50 +0000
Subject: [M3devel] [M3commit] WebFile/QScanner
	use	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W633584E529E074A2C2AEE6E6690@phx.gbl>


cm3.exe from a few days ago doesn't understand the VAL(LONGINT, INTEGER) used in Convert.m3.

 I had "fixed" Convert.m3 that but Tony put it back.

 

cm3/m3quake packages from a period this week only work with current libm3.

  That is fixed.

 

Normally you can either use an old cm3 and skip libm3/m3core or you can use a fairly recent cm3 and not stop skip them.

Neither was the case for a short time, but I restored the first option.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: Re: [M3devel] [M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)







Jay:
 
Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
 
I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
 
Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
 
We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 



From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)



On 15 Jan 2010, at 15:57, Jay K wrote:


 

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

 

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

 

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

 

Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?

 

Yes.

 

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

 

It very soon will not be.

 

 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/ddee77a0/attachment-0002.html>

From hosking at cs.purdue.edu  Fri Jan 15 23:08:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:08:08 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
Message-ID: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.

On 15 Jan 2010, at 16:34, Jay K wrote:

> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 

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

From hosking at cs.purdue.edu  Fri Jan 15 23:09:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:09:10 -0500
Subject: [M3devel] [M3commit] WebFile/QScanner use
	of	File.T.status().size (64bit	file size on 32bit platform)
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>
	<DBC0A6E744573F4FA5BF013793743B8710CDD6E7CE@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <E8BA8874-781B-48CC-8603-78B2B34E38C7@cs.purdue.edu>

You'll  need to bootstrap from old libs to new compiler+old libs to new libs to new compiler+new libs.

On 15 Jan 2010, at 16:45, Coleburn, Randy wrote:

> Jay:
>  
> Not sure about your statement that recent cm3.exe can?t be used to bootstrap new compiler.
>  
> I haven?t done an update in last 2 days, but up until then, I?ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
>  
> Are you saying that if I get current update (I?m only a couple of days out of sync with HEAD) that I won?t be able to bootstrap anymore?
>  
> Regards,
> Randy Coleburn
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, January 15, 2010 4:34 PM
> To: Tony
> Cc: m3devel; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
>  
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
>  
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
>  
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
>  
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
>  
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
>  
> Yes.
>  
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
>  
> It very soon will not be.
>  
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
>  

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

From hosking at cs.purdue.edu  Fri Jan 15 23:13:38 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:13:38 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

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

From jay.krell at cornell.edu  Fri Jan 15 23:13:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:13:46 +0000
Subject: [M3devel] WebFile/QScanner use of File.T.status().size
	(64bit	file size on 32bit platform)
In-Reply-To: <1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
References: <20100115134101.B053F2474001@birch.elegosoft.com>,
	, , <A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
Message-ID: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>


That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?

They previously never used LONGINT, including converting LONGINT to INTEGER.

*I* changed that, not you.

But then I decided it was a mistake.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:08:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.






On 15 Jan 2010, at 16:34, Jay K wrote:

We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)




On 15 Jan 2010, at 15:57, Jay K wrote:


I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?



RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.


My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)


Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?



Yes.


It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.



It very soon will not be.


 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 


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

From jay.krell at cornell.edu  Fri Jan 15 23:42:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 22:42:58 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
Message-ID: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>


The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.

 

I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.

(It's still in progress, but far long.)

 

m3core/libm3 can depend on current compiler, agreed.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:13:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages

Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.



On 15 Jan 2010, at 16:56, Jay K wrote:

VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
but I think what I had is the way to go.
The bootstrapping pain is otherwise novel.
The compiler doesn't otherwise use LONGINT.
 (My doing that it started using it.)
It ought not until after the current release?
 
 
 - Jay

 
> Date: Fri, 15 Jan 2010 22:51:15 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 10/01/15 22:51:15
> 
> Modified files:
> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> 
> Log message:
> Revert to VAL.
> 

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

From hosking at cs.purdue.edu  Fri Jan 15 23:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:48:09 -0500
Subject: [M3devel] WebFile/QScanner use of File.T.status().size (64bit
	file size on 32bit platform)
In-Reply-To: <COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
References: <20100115134101.B053F2474001@birch.elegosoft.com>, , ,
	<A7013429-09C0-4047-BA13-283182BE85B8@cs.purdue.edu>, ,
	<COL101-W538D049DFE9518ACA28951E6690@phx.gbl>, ,
	<09B41766-F3E3-4321-A568-AFE76959B787@cs.purdue.edu>,
	<COL101-W19AF18FC49D488FC38B5A0E6690@phx.gbl>,
	<1E52AB69-2D52-496D-AB5B-AF5FDA21744B@cs.purdue.edu>
	<COL101-W19C48AB50FF55E5290B276E6690@phx.gbl>
Message-ID: <D4AC4183-1465-47E9-BD5B-DF879237640A@cs.purdue.edu>

My point is that you need to bootstrap a new compiler as follows:

Build new compiler against old libraries.
Compile new libraries using new compiler.
Recompile new compiler against new libraries.
Throw away old libraries.

On 15 Jan 2010, at 17:13, Jay K wrote:

> That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?
> They previously never used LONGINT, including converting LONGINT to INTEGER.
> *I* changed that, not you.
> But then I decided it was a mistake.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:08:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.
> 
> On 15 Jan 2010, at 16:34, Jay K wrote:
> 
> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> I at least did move the hacks to one place.
> I agree it isn't nice.
> This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
> There's no way to use that in the "compiler" and still support old compiler/libm3, right?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> Ok now that I centralized it to sysutils?
>  
>  
> Leave status() alone as using INTEGER and introduce statusL()?
>  
>  
> Or leave size alone and introduce sizeL?
>  That's not a complete solution because you have to set size to something.
>   -1 if it doesn't fit?
>  
>  
> Or just get past the bootstrapping and put it back using VAL?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 15 Jan 2010 10:13:06 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> > 
> > On 15 Jan 2010, at 14:41, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/01/15 14:41:00
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > > m3makefile 
> > > Added files:
> > > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > > 
> > > Log message:
> > > m3quake also can't use libm3 File.T.status().size and be compatible
> > > with both old and new libm3 (INTEGER vs. LONGINT)
> > 
> 
> 
> 
> 



From hosking at cs.purdue.edu  Fri Jan 15 23:50:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:50:17 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>
Message-ID: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>

On 15 Jan 2010, at 16:56, Jay K wrote:

> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.

The bootstrapping pain is now no more novel than when LONGINT was first introduced...

> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?

... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.

>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 

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

From hosking at cs.purdue.edu  Fri Jan 15 23:51:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 17:51:47 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>
Message-ID: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>

It's not the presence of LONGINT in the libraries or not.  It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.

On 15 Jan 2010, at 17:42, Jay K wrote:

> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>  
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>  
> m3core/libm3 can depend on current compiler, agreed.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
> 
> Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.
> 
> On 15 Jan 2010, at 16:56, Jay K wrote:
> 
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - Jay
> 
>  
> > Date: Fri, 15 Jan 2010 22:51:15 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/01/15 22:51:15
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > 
> > Log message:
> > Revert to VAL.
> > 
> 
> 

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

From jay.krell at cornell.edu  Sat Jan 16 00:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:45:36 +0000
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
Message-ID: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>


I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
I'm not sure, but our regular builds might do that.
Not so now though.
I think you might be saying however that such a compiler might have bugs in it?
 
 - Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:50:17 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>
>
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
>
> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 00:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 15 Jan 2010 23:50:17 +0000
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
Message-ID: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>


Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.
 
 
Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?
 
 
One of us seems confused. I'm not sure who.
 
 
Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
5.2.6 works.
5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
 
 
I realize that it is grey and not clear how far to run this race.
You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
 
 
One metric has been that you can build with the previous "release".
I'm not sure which that is.
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:51:47 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
>
>
> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>
>
>
> On 15 Jan 2010, at 17:42, Jay K wrote:
>
> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>
> m3core/libm3 can depend on current compiler, agreed.
>
> - Jay
>
>
> ________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>
> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>
> On 15 Jan 2010, at 16:56, Jay K wrote:
>
> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
> but I think what I had is the way to go.
> The bootstrapping pain is otherwise novel.
> The compiler doesn't otherwise use LONGINT.
> (My doing that it started using it.)
> It ought not until after the current release?
>
>
> - Jay
>
>
>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>> To: m3commit at elegosoft.com
>> From: hosking at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: hosking at birch. 10/01/15 22:51:15
>>
>> Modified files:
>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>
>> Log message:
>> Revert to VAL.
>>
>
>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 00:57:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:57:30 -0500
Subject: [M3devel] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W36E9F26B4074904F190869E6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>
Message-ID: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>

You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:

Using old (release) cm3

m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.

m3core (new, with LONGINT/LONGCARD)
libm3 (new, with LONGINT/LONGCARD)
sysutils
m3middle
m3linker
m3front
m3quake
cm3

This cm3 uses new run-time libraries.

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

> 
> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
> I'm not sure, but our regular builds might do that.
> Not so now though.
> I think you might be saying however that such a compiler might have bugs in it?
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> 
>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>> 
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>> 
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Sat Jan 16 00:58:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 18:58:27 -0500
Subject: [M3devel] [M3commit] LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<6CF0A42A-940C-4FB5-9CFD-CBA18EC9CAFA@cs.purdue.edu>,
	<COL101-W40CFF2286C3D5165EDE83E6690@phx.gbl>,
	<35CA5D39-E2B2-4576-82D3-108CC21F34AC@cs.purdue.edu>
	<COL101-W599F11E9801B4CA0B956EDE6690@phx.gbl>
Message-ID: <13D6BE0C-2B40-474D-8743-B4F95F7A1D1A@cs.purdue.edu>

On 15 Jan 2010, at 18:50, Jay K wrote:

> 
> Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.

Not easily.

> Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?

By old, you mean pre-LONGINT, right?

> One of us seems confused. I'm not sure who.

Not me!  ;-)

> Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
> 5.2.6 works.
> 5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
> 
> 
> I realize that it is grey and not clear how far to run this race.
> You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
> 
> 
> One metric has been that you can build with the previous "release".
> I'm not sure which that is.
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:51:47 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>> 
>> 
>> 
>> On 15 Jan 2010, at 17:42, Jay K wrote:
>> 
>> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>> 
>> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
>> (It's still in progress, but far long.)
>> 
>> m3core/libm3 can depend on current compiler, agreed.
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:13:38 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 
>> 
>> 		 	   		  



From Highjinks at gmx.com  Sat Jan 16 01:33:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 16 Jan 2010 01:33:22 +0100 (CET)
Subject: [M3devel] Hello m3devel. Fixed mailer.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <20100115203621.5ca71b4a.Highjinks@gmx.com>

On Fri, 15 Jan 2010 16:46:53 -0500
Highjinks at gmx.com wrote:

Sorry about the html attachment. Webmailers tend to do that. Sticking to my regular client program. 


--
Chris <Highjinks at gmx.com>


From rcolebur at SCIRES.COM  Sat Jan 16 02:09:02 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 15 Jan 2010 20:09:02 -0500
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6E7F4@ATLEX02-SRV.SCIRES.LOCAL>

Chris:

Glad to have you on board.  Welcome!

We always seem to have a long list of to-do items and a shorter list of folks to help, so thanks for your offer.

As you become more familiar with Modula-3, don?t hesitate to reach out to me, or to the development group.

Glad to hear your learning experience so far has been good.  That is one of the primary goals of Modula-3.

I?ve been using Modula-3 for over 16 years now; and Modula-2 before that (among other languages).  Right now I?m primarily using Modula-3 on various Windows? platforms, so I won?t be much help with AMD64_LINUX issues, though I have and do use other Linux flavors.

The next major hurdle for the development team is to finish up the next release.  Maybe you can help test on your platform.

Regards,
Randy Coleburn

From: Highjinks at gmx.com [mailto:Highjinks at gmx.com]
Sent: Friday, January 15, 2010 4:47 PM
To: m3devel at elegosoft.com
Subject: [M3devel] Hello m3devel.

Just dropping in to say "Hi" and let you guys know what I'm up to.

Since I'm new to the list, and Modula 3, I wont clog up the list with novice questions. However, I do have fifteen years experience developing in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an order of magnitude faster than I picked up Ada.

My current platform is the AMD64_LINUX setup. And from the looks of it the development team here has been struggling a bit with 32bit/64bit issues. Is my observation correct? If so, what could I, an M3 newbie, do to assist?

I'm checking out the CM3 sources, anonymously, from the repository right now.

If there is anything I can do, just let me know.
--
Chris <Highjinks at gmx.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/b95c54c4/attachment-0002.html>

From hosking at cs.purdue.edu  Sat Jan 16 03:45:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 21:45:26 -0500
Subject: [M3devel] LONGINT and LONGCARD
Message-ID: <C101F91A-05C4-4FDA-84A8-A2A8BC13D043@cs.purdue.edu>

Support for these is now more complete.
More probably needs to be done w.r.to pickles, stable, sharedobj, netobj, etc. to handle variations in target implementations (NT386 using the integrated backend currently treats LONGINT/LONGCARD as 32 bits, whereas all other targets using the gcc-based backend treat LONGINT/LONGCARD as 64 bits).

For example:  there are no Longint/Longcard variants of In/OutInteger and In/OutCardinal in PickleStubs.m3.  Rodney?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

From jay.krell at cornell.edu  Sat Jan 16 05:15:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 04:15:20 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
Message-ID: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>


I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 18:57:30 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>
> Using old (release) cm3
>
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>
> m3core (new, with LONGINT/LONGCARD)
> libm3 (new, with LONGINT/LONGCARD)
> sysutils
> m3middle
> m3linker
> m3front
> m3quake
> cm3
>
> This cm3 uses new run-time libraries.
>
> On 15 Jan 2010, at 18:45, Jay K wrote:
>
>>
>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>> I'm not sure, but our regular builds might do that.
>> Not so now though.
>> I think you might be saying however that such a compiler might have bugs in it?
>>
>> - Jay
>>
>>
>>
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>>
>>>
>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>
>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>> but I think what I had is the way to go.
>>> The bootstrapping pain is otherwise novel.
>>>
>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>
>>> The compiler doesn't otherwise use LONGINT.
>>> (My doing that it started using it.)
>>> It ought not until after the current release?
>>>
>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>> To: m3commit at elegosoft.com
>>>> From: hosking at elego.de
>>>> Subject: [M3commit] CVS Update: cm3
>>>>
>>>> CVSROOT: /usr/cvs
>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>
>>>> Modified files:
>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>
>>>> Log message:
>>>> Revert to VAL.
>>>>
>>>
> 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 05:29:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 15 Jan 2010 23:29:27 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>
Message-ID: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>

The old (release) libraries don't have the VAL stuff do they?

On 15 Jan 2010, at 23:15, Jay K wrote:

> 
> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>> 
>> Using old (release) cm3
>> 
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>> 
>> m3core (new, with LONGINT/LONGCARD)
>> libm3 (new, with LONGINT/LONGCARD)
>> sysutils
>> m3middle
>> m3linker
>> m3front
>> m3quake
>> cm3
>> 
>> This cm3 uses new run-time libraries.
>> 
>> On 15 Jan 2010, at 18:45, Jay K wrote:
>> 
>>> 
>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>> I'm not sure, but our regular builds might do that.
>>> Not so now though.
>>> I think you might be saying however that such a compiler might have bugs in it?
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> ________________________________
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> 
>>>> 
>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>> 
>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>> but I think what I had is the way to go.
>>>> The bootstrapping pain is otherwise novel.
>>>> 
>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>> 
>>>> The compiler doesn't otherwise use LONGINT.
>>>> (My doing that it started using it.)
>>>> It ought not until after the current release?
>>>> 
>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>> To: m3commit at elegosoft.com
>>>>> From: hosking at elego.de
>>>>> Subject: [M3commit] CVS Update: cm3
>>>>> 
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>> 
>>>>> Modified files:
>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>> 
>>>>> Log message:
>>>>> Revert to VAL.
>>>>> 
>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Sat Jan 16 06:14:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:14:16 +0000
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
References: <20100115215118.A9F482474001@birch.elegosoft.com>,
	,,<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>,
	, , <46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
Message-ID: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>


No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
It doesn't matter if x is INTEGER or not, right?
(In newer libraries, it is LONGINT).
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 23:29:27 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>
> The old (release) libraries don't have the VAL stuff do they?
>
> On 15 Jan 2010, at 23:15, Jay K wrote:
>
>>
>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>
>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>
>>> Using old (release) cm3
>>>
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>
>>> m3core (new, with LONGINT/LONGCARD)
>>> libm3 (new, with LONGINT/LONGCARD)
>>> sysutils
>>> m3middle
>>> m3linker
>>> m3front
>>> m3quake
>>> cm3
>>>
>>> This cm3 uses new run-time libraries.
>>>
>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>
>>>>
>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>> I'm not sure, but our regular builds might do that.
>>>> Not so now though.
>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>
>>>>>
>>>>>
>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>
>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>> but I think what I had is the way to go.
>>>>> The bootstrapping pain is otherwise novel.
>>>>>
>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>
>>>>> The compiler doesn't otherwise use LONGINT.
>>>>> (My doing that it started using it.)
>>>>> It ought not until after the current release?
>>>>>
>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>> To: m3commit at elegosoft.com
>>>>>> From: hosking at elego.de
>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>
>>>>>> Log message:
>>>>>> Revert to VAL.
>>>>>>
>>>>>
>>>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jan 16 06:16:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 05:16:11 +0000
Subject: [M3devel] release vs. head?
Message-ID: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>


Should we just make a new release branch?
Or I keep copying stuff over somewhat selectively?
  We do want LONGCARD in the release, I assume.
 
 
I'll diff the two trees again, see what varies.
Sometimes when I do that I find stuff to take.
 And take the LONGCARD changes.
 
 
 - Jay 		 	   		  

From hosking at cs.purdue.edu  Sat Jan 16 06:20:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:20:22 -0500
Subject: [M3devel] [M3commit]  LONGINT used by m3quake/cm3 packages
In-Reply-To: <COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
References: <20100115215118.A9F482474001@birch.elegosoft.com>, , ,
	<COL101-W5212E24248C3B9ED43F89EE6690@phx.gbl>, , ,
	<46AFC820-D62E-472B-A0D0-6957153ECE17@cs.purdue.edu>, ,
	<COL101-W36E9F26B4074904F190869E6690@phx.gbl>, ,
	<8089316A-A262-4CC7-8886-7350FC532D0F@cs.purdue.edu>,
	<COL101-W503658974AD9B5B26A0CF1E6680@phx.gbl>,
	<635BE76B-3EFD-4930-8029-DBBB14468869@cs.purdue.edu>
	<COL101-W50D90BAB1355AF693D05CCE6680@phx.gbl>
Message-ID: <DB076F7D-29E4-41E3-B0FA-1D02B33CD6C7@cs.purdue.edu>

That's fine.

On 16 Jan 2010, at 00:14, Jay K wrote:

> 
> No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
> It doesn't matter if x is INTEGER or not, right?
> (In newer libraries, it is LONGINT).
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 23:29:27 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> The old (release) libraries don't have the VAL stuff do they?
>> 
>> On 15 Jan 2010, at 23:15, Jay K wrote:
>> 
>>> 
>>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>> 
>>>> Using old (release) cm3
>>>> 
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>> 
>>>> m3core (new, with LONGINT/LONGCARD)
>>>> libm3 (new, with LONGINT/LONGCARD)
>>>> sysutils
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses new run-time libraries.
>>>> 
>>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>> 
>>>>> 
>>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>>> I'm not sure, but our regular builds might do that.
>>>>> Not so now though.
>>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>> 
>>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>>> but I think what I had is the way to go.
>>>>>> The bootstrapping pain is otherwise novel.
>>>>>> 
>>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>> 
>>>>>> The compiler doesn't otherwise use LONGINT.
>>>>>> (My doing that it started using it.)
>>>>>> It ought not until after the current release?
>>>>>> 
>>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: hosking at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>> 
>>>>>>> Log message:
>>>>>>> Revert to VAL.
>>>>>>> 
>>>>>> 
>>>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Sat Jan 16 06:21:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 00:21:26 -0500
Subject: [M3devel] release vs. head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <99ACAE0F-41FB-4A46-A570-D10C9AA7C872@cs.purdue.edu>

At this point, what substantive differences are there between the release branch and the trunk other than LONGCARD?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 00:16, Jay K wrote:

> 
> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>  We do want LONGCARD in the release, I assume.
> 
> 
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
> And take the LONGCARD changes.
> 
> 
> - Jay 		 	   		  

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

From jay.krell at cornell.edu  Sat Jan 16 12:11:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings
Message-ID: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>


Any of these worrisome?

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






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

From jay.krell at cornell.edu  Sat Jan 16 13:50:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 12:50:43 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>


Some of these are fixed in a newer version by adding parens.

The rest I just #pragma warning'ed away.

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings



Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression






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

From jay.krell at cornell.edu  Sat Jan 16 14:45:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 13:45:22 +0000
Subject: [M3devel] longint/longcard/atomics copied from head to release
In-Reply-To: <20100116134209.79B3A2474001@birch.elegosoft.com>
References: <20100116134209.79B3A2474001@birch.elegosoft.com>
Message-ID: <COL101-W37005FD9263CE8B4674E89E6680@phx.gbl>


There's also more "val" reversion here.

Attached should match this. Pity no cvs command or web page can show it.

(I try to make up for CVS lameness just by remembering a lot...not a good technique..)

 

 - Jay

 
> Date: Sat, 16 Jan 2010 14:42:09 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/16 14:42:09
> 
> Modified files:
> cm3/m3-comm/events/src/: Tag: release_branch_cm3_5_8 
> EventStubLib.m3 
> cm3/m3-comm/sharedobjgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 
> Type.i3 Type.m3 Value.m3 
> cm3/m3-comm/stubgen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 CodeForType.m3 Type.i3 
> Type.m3 Value.m3 
> cm3/m3-db/stable/src/: Tag: release_branch_cm3_5_8 StableLog.i3 
> StableLog.m3 
> cm3/m3-db/stablegen/src/: Tag: release_branch_cm3_5_8 
> AstToType.m3 GenModuleCode.m3 
> GenTypeCode.m3 Type.i3 Type.m3 
> Value.m3 
> cm3/m3-libs/libm3/src/pickle/ver2/: Tag: release_branch_cm3_5_8 
> ConvertPacking.m3 
> PickleStubs.i3 
> PickleStubs.m3 
> cm3/m3-libs/m3core/src/runtime/common/: Tag: 
> release_branch_cm3_5_8 
> RTBuiltin.mx 
> RTPacking.i3 
> RTPacking.m3 RTTipe.i3 
> RTTipe.m3 
> cm3/m3-sys/m3cggen/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> BuiltinTypes.m3 m3makefile 
> cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.i3 
> CG.m3 TipeDesc.i3 Token.m3 
> cm3/m3-sys/m3front/src/types/: Tag: release_branch_cm3_5_8 
> RecordType.i3 RecordType.m3 
> SubrangeType.m3 
> cm3/m3-sys/m3middle/src/: Tag: release_branch_cm3_5_8 M3CG.i3 
> M3CG.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 
> M3CG_Binary.i3 M3CG_Check.m3 
> M3CG_Ops.i3 M3CG_Rd.m3 M3CG_Wr.m3 
> cm3/m3-sys/m3quake/src/: Tag: release_branch_cm3_5_8 
> QCompiler.m3 QScanner.i3 
> cm3/m3-sys/m3tools/src/: Tag: release_branch_cm3_5_8 M3Const.m3 
> M3Type.i3 M3Type.m3 
> cm3/m3-tools/m3browser/src/: Tag: release_branch_cm3_5_8 Main.m3 
> cm3/m3-tools/m3tk/src/fe/: Tag: release_branch_cm3_5_8 
> StandardAsText.m3 WiredStandard.m3 
> cm3/m3-tools/m3tk/src/pl/: Tag: release_branch_cm3_5_8 
> M3LTextToType.m3 M3LTypeEquiv.m3 
> M3LTypeToText.i3 M3LTypeToText.m3 
> cm3/m3-tools/m3tk/src/sem/: Tag: release_branch_cm3_5_8 
> M3CMkStd.m3 M3CStdTypes.i3 
> M3CStdTypes.m3 M3CTypeChkUtil.i3 
> M3CTypeChkUtil.m3 
> cm3/m3-tools/m3tk/src/syn/: Tag: release_branch_cm3_5_8 
> M3CLex.m3 M3CParse.m3 M3CToken.i3 
> Added files:
> cm3/m3-sys/m3front/src/builtinTypes/: Tag: 
> release_branch_cm3_5_8 
> LCard.i3 LCard.m3 
> 
> Log message:
> copy from head: LONGINT, LONGCARD, and atomics come along for the ride
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100116/9c6bd348/attachment-0002.txt>

From rodney_bates at lcwb.coop  Sat Jan 16 18:49:12 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 16 Jan 2010 11:49:12 -0600
Subject: [M3devel] Hello m3devel.
In-Reply-To: <20100115214653.129010@gmx.com>
References: <20100115214653.129010@gmx.com>
Message-ID: <4B51FC18.1000104@lcwb.coop>



Highjinks at gmx.com wrote:
> Just dropping in to say "Hi" and let you guys know what I'm up to.
> 
> Since I'm new to the list, and Modula 3, I wont clog up the list with 
> novice questions. However, I do have fifteen years experience developing 
> in Assembler, C, Ada, and Forth. I'm picking up Modula3, IMO, about an 
> order of magnitude faster than I picked up Ada.

As an old Ada refugee, I am glad to hear from someone making the same
transition, and glad to hear your estimate of learning time ratio.
It is the same as the ratio of language definition page counts!

> 
> My current platform is the AMD64_LINUX setup. And from the looks of it 
> the development team here has been struggling a bit with 32bit/64bit 
> issues. Is my observation correct? If so, what could I, an M3 newbie, do 
> to assist?
> 
> I'm checking out the CM3 sources, anonymously, from the repository right 
> now.
> 
> If there is anything I can do, just let me know.
> -- 
> Chris <Highjinks at gmx.com>
> 


From hosking at cs.purdue.edu  Sat Jan 16 19:48:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:12 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
Message-ID: <2629BE63-3067-41FD-8A0F-E1F20C79C4FD@cs.purdue.edu>

Yes, those are potentially worrisome.  I've not seen them before.  dtoa has failed in the past because of warnings.  Which compiler?

On 16 Jan 2010, at 06:11, Jay K wrote:

> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Sat Jan 16 19:48:49 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 16 Jan 2010 13:48:49 -0500
Subject: [M3devel] dtoa warnings
In-Reply-To: <COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>
Message-ID: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 16 Jan 2010, at 07:50, Jay K wrote:

> Some of these are fixed in a newer version by adding parens.
> The rest I just #pragma warning'ed away.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sat, 16 Jan 2010 11:11:28 +0000
> Subject: [M3devel] dtoa warnings
> 
> Any of these worrisome?
>  
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
> C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
> c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression
> 
> 
> 
> 
> 
> 

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

From jay.krell at cornell.edu  Sat Jan 16 21:03:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 20:03:07 +0000
Subject: [M3devel] dtoa warnings
In-Reply-To: <E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
References: <COL101-W2DD91923773C425225B0DE6680@phx.gbl>,
	<COL101-W25BDF3359AB87027BE5DE0E6680@phx.gbl>,
	<E49BB919-1898-4FE3-B529-3C1336B6E2BD@cs.purdue.edu>
Message-ID: <COL101-W15A68491F1F3F5ADA4096CE6680@phx.gbl>


A lot/all of the assignment within conditional you can see are ok because in the newer version they doubled the parens. That is the gcc convention for quashing them that unfortunately Microsoft C doesn't recognize.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>cl -c -W4 -Wall -DIEEE_8087 -TC dtoa.h | more

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.


...

 

These I can fix from current source.

 

 

C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common>\cygwin\bin\gcc-4.exe -DIEEE_8087 -c -Wall dtoa.h
dtoa.h: In function 'Balloc':
dtoa.h:530: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'mult':
dtoa.h:809: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'pow5mult':
dtoa.h:891: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'lshift':
dtoa.h:972: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'd2b':
dtoa.h:1274: warning: suggest parentheses around assignment used as truth value
dtoa.h:1278: warning: suggest parentheses around assignment used as truth value
dtoa.h:1279: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'match':
dtoa.h:1473: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'hexnan':
dtoa.h:1505: warning: suggest parentheses around assignment used as truth value
dtoa.h:1533: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_strtod':
dtoa.h:1857: warning: suggest parentheses around assignment used as truth value
dtoa.h:1917: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'nrv_alloc':
dtoa.h:2600: warning: suggest parentheses around assignment used as truth value
dtoa.h: In function 'm3_dtoa':
dtoa.h:2780: warning: suggest parentheses around assignment used as truth value
dtoa.h:2934: warning: suggest parentheses around assignment used as truth value
dtoa.h:3095: warning: suggest parentheses around assignment used as truth value
dtoa.h:3133: warning: suggest parentheses around assignment used as truth value


 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 16 Jan 2010 13:48:49 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] dtoa warnings

I suggest we leave the warnings in place (remove the nowarn pragma) and vet each of them for correctness sometime.




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 16 Jan 2010, at 07:50, Jay K wrote:

Some of these are fixed in a newer version by adding parens.
The rest I just #pragma warning'ed away.
 
 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 16 Jan 2010 11:11:28 +0000
Subject: [M3devel] dtoa warnings

Any of these worrisome?
 
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1188) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1190) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1195) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1197) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1274) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1503) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1505) : warning C4245: '+=' : conversion from 'int' to 'ULong', signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1762) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(1930) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2291) : warning C4127: conditional expression is constant
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2319) : warning C4244: '=' : conversion from 'double' to 'ULong', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2572) : warning C4018: '<=' : signed/unsigned mismatch
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2818) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '>>' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2819) : warning C4554: '<<' : check operator precedence for possible error; use parentheses to clarify precedence
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2962) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2964) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(2983) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3026) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3208) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3238) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3251) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3257) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3271) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
C:\dev2\cm3.2\m3-libs\m3core\src\Csupport\Common\dtoa.h(3304) : warning C4102: 'trimzeros' : unreferenced label
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1851) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1911) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2429) : warning C4701: potentially uninitialized local variable 'bd' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2428) : warning C4701: potentially uninitialized local variable 'bb' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2430) : warning C4701: potentially uninitialized local variable 'bs' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2432) : warning C4701: potentially uninitialized local variable 'delta' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(524) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(819) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(833) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(885) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(890) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(894) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(912) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(915) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(966) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1268) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1272) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1273) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1282) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1467) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1495) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1499) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(1527) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2774) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2928) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3089) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3127) : warning C4706: assignment within conditional expression
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2903) : warning C4701: potentially uninitialized local variable 'ilim' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2937) : warning C4701: potentially uninitialized local variable 'ilim1' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(3311) : warning C4701: potentially uninitialized local variable 'mlo' used
c:\dev2\cm3.2\m3-libs\m3core\src\csupport\common\dtoa.h(2594) : warning C4706: assignment within conditional expression







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

From jay.krell at cornell.edu  Sun Jan 17 00:39:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Jan 2010 23:39:09 +0000
Subject: [M3devel] signed overflow warnings in hand.c
Message-ID: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>


In C signed overflow is not defined.

Sometimes compilers take advantage of that and make optimizations assuming there is no overflow.

 

 

$ gcc-4 -O2 -Wstrict-overflow=4 -c hand.c
hand.c: In function `m3_div':
hand.c:244: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:245: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c: In function `m3_divL':
hand.c:256: warning: assuming signed overflow does not occur when distributing n
egation across division
hand.c:257: warning: assuming signed overflow does not occur when distributing n
egation across division

jay at jay1 /cygdrive/c/dev2/cm3/m3-libs/m3core/src/Csupport/Common

 

 

Is there a way to write this using unsigned math only?

 

I was expecting warnings on the new functions unused functions I added.

 

 - Jay

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

From jay.krell at cornell.edu  Sun Jan 17 06:10:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>
Message-ID: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>


The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/5881e0f4/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 06:46:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>
Message-ID: <COL101-W30215B137331232907B941E6670@phx.gbl>


The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/0e1628c2/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 06:48:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W30215B137331232907B941E6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	<COL101-W30215B137331232907B941E6670@phx.gbl>
Message-ID: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>


(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

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

From jay.krell at cornell.edu  Sun Jan 17 06:57:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>


The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

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

From jay.krell at cornell.edu  Sun Jan 17 07:04:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 06:04:39 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <COL101-W63EE738E1345D2DACEFC08E6670@phx.gbl>


Actually there is also a problem passing 64 bit integers to K&R functions.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: Re: [M3devel] bugs in hand.c division








The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

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

From jay.krell at cornell.edu  Sun Jan 17 08:19:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,
	, , <COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
Message-ID: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>


Visual C++ and Sun cc also had problems here.

Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.

  -1 vs 1.

Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.

Anyone feel free to confirm my findings, please. :)

(likewise with INT64_MIN)

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

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

From jay.krell at cornell.edu  Sun Jan 17 08:28:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 07:28:47 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>,,, ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W39BAA31431BFCDBA81269AE6670@phx.gbl>
Message-ID: <COL101-W22756264B636CB0F28608E6670@phx.gbl>


sorry, that wasn't right. But there were problems with Microsoft Visual C++ and Sun cc, and gcc.

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 07:19:56 +0000
Subject: Re: [M3devel] bugs in hand.c division



Visual C++ and Sun cc also had problems here.
Visual C++ only had LONG_MIN / LONG_MIN wrong, optimized or not.
  -1 vs 1.
Sun cc same as gcc: LONG_MIN divided by negative wrong, unless optimized.
Anyone feel free to confirm my findings, please. :)
(likewise with INT64_MIN)
 
 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division



(Of course I'll have to look into the mod functions as well. :) )

 - Jay




From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division



The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division



The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

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

From roland.illig at gmx.de  Sun Jan 17 08:49:45 2010
From: roland.illig at gmx.de (Roland Illig)
Date: Sun, 17 Jan 2010 08:49:45 +0100
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, , ,
	<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>, ,
	<COL101-W30215B137331232907B941E6670@phx.gbl>,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>
Message-ID: <4B52C119.7080808@gmx.de>

Jay K schrieb:
> The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> What is that supposed to equal?
> For any version that doesn't "crash", the result is LONG_MIN.

That's the best result one can get besides throwing an exception. With 
unlimited integers, the result would be LONG_MAX + 1, which equals 
LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
arithmetics.

Roland


From jay.krell at cornell.edu  Sun Jan 17 09:56:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 08:56:59 +0000
Subject: [M3devel] bugs in hand.c division
In-Reply-To: <4B52C119.7080808@gmx.de>
References: <COL101-W46F7E49124DC581D7218DBE6680@phx.gbl>, ,
	,,<COL101-W617CD0888E2474B52696DFE6670@phx.gbl>,
	, , <COL101-W30215B137331232907B941E6670@phx.gbl>, ,
	<COL101-W51CD868EB99BFC5DF4B7CBE6670@phx.gbl>,
	<COL101-W3821B959D6A749C87F512EE6670@phx.gbl>,
	<4B52C119.7080808@gmx.de>
Message-ID: <COL101-W162860C88378BBA3019641E6670@phx.gbl>


Understood. I put that back -- depending on C compiler flags,
LONG_MIN / -1 will either be LONG_MIN or trap.
Trap seems reasonable.
Though Modula-3 might mandate the consistent LONG_MIN?
Or leave it implementation defined?


The real bugs here were:
  LONG_MIN / negative (other than -1) was returning positive 
  possibly long long problem with K&R style, I'm pretty sure 
  possibly slightly fragile code wrt signed overflow. 


   funny thing is though, the reason I went looking into this
   was because mailing list threads lead me to believe my
   functions that are meant to look for overflow might be
   broken by the optimizer; it doesn't seem to notice them 
   but the funny stuff m3_div was doing, the optimizer 
   sees opportunity in and warns..so I started writing
   something using unsigned math, which isn't subject
   to such fragility, started testing it by comparison
   to the existing..found the existing to be wrong 


  I didn't really understand the code that was there.
  
But from the spec and behavior I could see -- round down negative results.
   Which you can do by roughly - ((abs(a) + abs(b) - 1) / abs(b))
   Round up the positive result.

 - Jay


> Date: Sun, 17 Jan 2010 08:49:45 +0100
> From: roland.illig at gmx.de
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] bugs in hand.c division
> 
> Jay K schrieb:
> > The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> > What is that supposed to equal?
> > For any version that doesn't "crash", the result is LONG_MIN.
> 
> That's the best result one can get besides throwing an exception. With 
> unlimited integers, the result would be LONG_MAX + 1, which equals 
> LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
> arithmetics.
> 
> Roland
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/644bba0e/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 10:38:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:38:46 +0000
Subject: [M3devel] in favor of mixed operators..
Message-ID: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>


http://python-history.blogspot.com/2009/03/problem-with-integer-division.html


He argues that for a "high level" language, of course
I should be able to add int to long, int to float, etc.
And that int / int should not be int.
At least Modula-3 spells them differently, / vs. MOD.


Of course, "high level" vs. "systems" vs. "one size to fit all"...


Anyway, I give up here.


 - Jay




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

From jay.krell at cornell.edu  Sun Jan 17 10:36:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:36:55 +0000
Subject: [M3devel] integer division rounding?
Message-ID: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>


Modula-3 apparently specifies integer division as rounding down.
http://www.modula3.com/cm3/doc/reference/arithmetic.html

C used to leave it unspecified. So it could be fast.
Fortran rounded to zero.
C's ldiv function rounds to zero.
C now rounds to zero with C99.
  The rationale was that nobody using Fortran seemed to mind.
Java apparently rounds toward zero.
C# apparently rounds toward zero.


I'm assuming we are stuck being different here?

 - Jay

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

From jay.krell at cornell.edu  Sun Jan 17 10:41:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 09:41:26 +0000
Subject: [M3devel] rd/wr beyond 2GB on 32bit?
Message-ID: <COL101-W501F667E0F501DC8B6E0C1E6670@phx.gbl>


Anyone have ideas or time to think about or work on fixing rd/wr to support going past 2GB on 32bit platforms?
Well, it's easy to get to 64bits.
  - is that enough? Probably. How many rd/wr are "infinite" and long enough lived to exceed 64bits?
  - at what cost to breaking existing code? I sent approximate diffs. A little gnarly.
   Maybe add SeekL, LengthL, etc.?

 - Jay




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

From jay.krell at cornell.edu  Sun Jan 17 11:44:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:44:53 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>


-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/065bb5f7/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 11:50:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 10:50:18 +0000
Subject: [M3devel] integer division/mod questions?
Message-ID: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>


I think I missed a sign.




-2147483648 - 2147483647  * -2
 actually -2147483648 + 2 * 2147483647

  actually 2147483646

which agrees.

so 




-2147483648 div 2147483647 = -2 
-2147483648 mod 2147483647 = 2147483646 

-2 * 2147483647 + 2147483646  = -2147483648

I'll make sure m3_mod works this way if it doesn't already.
Presumably we are stuck with these rules.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: integer division/mod questions?
Date: Sun, 17 Jan 2010 10:44:53 +0000








-2147483648 div 2147483647 ?
-2147483648 mod 2147483647 ?

quotient = -1, remainer = -1 seems reasonable.
2147483647 * -1 + -1 == -2147483648


However, Modula-3 specifies div as rounding down, so

-2147483648 div 2147483647  == -2

and then

http://www.modula3.com/cm3/doc/reference/arithmetic.html

The value x DIV y is the floor of 
the quotient of x and y; that is, the maximum integer 
not exceeding the real number z such that z * y = x.
For integers x and y, the value of x MOD y is 
defined to be x - y * (x DIV y).


This means that for positive y, the value of x MOD y
lies in the interval [0 .. y-1], regardless of 
the sign of x.  For negative y, the value of
x MOD y lies in the interval [y+1 .. 0], regardless 
of the sign of x.


-2147483648 - 2147483647  * -2

-2147483648 +2  (due to overflow)


-2147483646

which contradicts the second part.

Maybe I'm confused? I should work this all through again?

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/7702d6cc/attachment-0002.html>

From wagner at elegosoft.com  Sun Jan 17 12:38:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 12:38:16 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
Message-ID: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Should we just make a new release branch?
> Or I keep copying stuff over somewhat selectively?
>   We do want LONGCARD in the release, I assume.
>
> I'll diff the two trees again, see what varies.
> Sometimes when I do that I find stuff to take.
>  And take the LONGCARD changes.

 From a release engineering point of view this is more or less
a nightmare. We cannot make incompatible extensions to the feature
set after the fourth release candidate.

The only clean way I'd see to even get the LONGINT changes into the
next release would be to start anew. Meaning declaring 5.8.4 as
the latest release and develop 5.9 on the trunk. Of course we'd
have to carefully merge back any fixes that might be missing on the
trunk right now.

That said, I have currently neither the time nor the energy to do all
that cleanly. I didn't even get round to set up release builds
on new.elego.de via Hudson in order to cover the FreeBSD4 target
platform we recently lost in the release due to my home machine's
complete crash in December. So the release engineering support is not
in the best of states I must admit.

I could live with declaring 5.8.RC4 as an intermediate release,
but somebody really needs to do all the housekeeping of comparing
and merging branches. And we shouldn't start a new release branch
until things have settled down.

Is anybody interested in taking over some of the release engineering
tasks (including Hudson management and re-targeting to the new release)?

Please keep in mind that we haven't managed to get out a stable release
for several years now.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Sun Jan 17 14:21:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 14:21:37 +0100
Subject: [M3devel] Hudson RELENG builds broken
Message-ID: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>

Several Hudson builds are currently broken due to

new source -> compiling ProcessPosixCommon.m3
"../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
qualification '.' (sleep)
1 error encountered
new source -> compiling ProcessPosix.m3

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
for example.

I'm really not sure that we should copy the incompatible
LONGINT and LONGCARD changes to this release branch...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Sun Jan 17 14:33:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:33:42 +0000
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <COL101-W3172F677C46972D488A4F8E6670@phx.gbl>


Sorry, my fault, should be ok now.
Nothing to do with LONGINT/LONGCARD.

 - Jay


> Date: Sun, 17 Jan 2010 14:21:37 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Hudson RELENG builds broken
> 
> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown  
> qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/d601908b/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 14:42:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:42:57 +0000
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>


We can stick with the current release branch if that is indeed much easier.



I thought there was some agreement we shouldn't release LONGINT as it was.
I can undo the changes if we want.
It's not easy with cvs (not much is) but I can do it.
It's easy for me to diff the trees, just using windiff or diff (again, cvs
seems not to help).



Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
but diff tells us better.


I'm still planning on setting up some more machines and can do FreeBSD4.
(I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
I have to check if Modula-3 actually works on them first...)


Does anyone have the missing steps for the cvsup bug report, like the configuration file,
can show the callstacks, try it with user threads..etc..?


 - Jay


> Date: Sun, 17 Jan 2010 12:38:16 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > Should we just make a new release branch?
> > Or I keep copying stuff over somewhat selectively?
> >   We do want LONGCARD in the release, I assume.
> >
> > I'll diff the two trees again, see what varies.
> > Sometimes when I do that I find stuff to take.
> >  And take the LONGCARD changes.
> 
>  From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/dfa99ae5/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 17 14:55:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Jan 2010 13:55:34 +0000
Subject: [M3devel] how division and modulo work in hand.c?
Message-ID: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>


I have to admit I don't fully understand
the division and modulo code in hand.c.


I don't understand the old division code,
but the documenation and behavior are
clear: round down. I understand
why my version works, though it might
depend on non-guaranteed behavior in C division
for the same sign cases. An earlier version
was clearer since it avoided doing anything
with negative numbers execpt negating them
(and carefully at that).


Modulo is much less clear to me.
>From testing vs. the documentation, I know the
old code was wrong, though close.
I made some guesses based on the old code and
ran a variety of inputs through it.
My version matches the old version, except
where the old version is wrong.
I could write a clearly correct version, but it
would be perhaps much less efficient, just
computing a - b * div(a, b).


I tried running all 32bit inputs through some of it but it was
going to take too long.
I could maybe leave that running a few days if needed.

 - Jay

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

From hosking at cs.purdue.edu  Sun Jan 17 17:05:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:05:44 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>

What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

On 17 Jan 2010, at 04:36, Jay K wrote:

> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> C used to leave it unspecified. So it could be fast.
> Fortran rounded to zero.
> C's ldiv function rounds to zero.
> C now rounds to zero with C99.
>   The rationale was that nobody using Fortran seemed to mind.
> Java apparently rounds toward zero.
> C# apparently rounds toward zero.
> 
> 
> I'm assuming we are stuck being different here?
> 
>  - Jay
> 

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

From hosking at cs.purdue.edu  Sun Jan 17 17:08:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:08:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
Message-ID: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>

On 17 Jan 2010, at 05:50, Jay K wrote:

> I think I missed a sign.
> 
> -2147483648 - 2147483647  * -2
>  actually -2147483648 + 2 * 2147483647
>   actually 2147483646
> 
> which agrees.
> 
> so 
> 
> -2147483648 div 2147483647 = -2 
> -2147483648 mod 2147483647 = 2147483646 
> 
> -2 * 2147483647 + 2147483646  = -2147483648
> 
> I'll make sure m3_mod works this way if it doesn't already.
> Presumably we are stuck with these rules.

Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: integer division/mod questions?
> Date: Sun, 17 Jan 2010 10:44:53 +0000
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 
> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of the quotient of x and y; that is, the maximum integer not exceeding the real number z such that z * y = x. For integers x and y, the value of x MOD y is defined to be x - y * (x DIV y). This means that for positive y, the value of x MOD y lies in the interval [0 .. y-1], regardless of the sign of x. For negative y, the value of x MOD y lies in the interval [y+1 .. 0], regardless of the sign of x. 
> 
> -2147483648 - 2147483647  * -2
> -2147483648 +2  (due to overflow)
> -2147483646
> 
> which contradicts the second part.
> 
> Maybe I'm confused? I should work this all through again?
> 
>  - Jay

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

From hosking at cs.purdue.edu  Sun Jan 17 17:10:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:10:18 -0500
Subject: [M3devel] Hudson RELENG builds broken
In-Reply-To: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
References: <20100117142137.ielpkqbxpccwko4c@mail.elegosoft.com>
Message-ID: <A15FF600-B5FD-4A12-9F35-3BA91BC69B4D@cs.purdue.edu>

On 17 Jan 2010, at 08:21, Olaf Wagner wrote:

> Several Hudson builds are currently broken due to
> 
> new source -> compiling ProcessPosixCommon.m3
> "../src/os/POSIX/ProcessPosixCommon.m3", line 92: unknown qualification '.' (sleep)
> 1 error encountered
> new source -> compiling ProcessPosix.m3
> 
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_LINUX/101/console
> for example.
> 
> I'm really not sure that we should copy the incompatible
> LONGINT and LONGCARD changes to this release branch...

I think we definitely should.  There were some rough edges in the implementation of LONGINT/LONGCARD that needed tidying.  This is our first release with them and we should make sure to have it right for the release.  The problem you see above is something we can fix!

> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From hosking at cs.purdue.edu  Sun Jan 17 17:12:13 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:12:13 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs.	head?
In-Reply-To: <20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
Message-ID: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>

I think that we are closest now to a release we can be happy with than for some time.  It would be a huge shame not to push this out the door.

On 17 Jan 2010, at 06:38, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Should we just make a new release branch?
>> Or I keep copying stuff over somewhat selectively?
>>  We do want LONGCARD in the release, I assume.
>> 
>> I'll diff the two trees again, see what varies.
>> Sometimes when I do that I find stuff to take.
>> And take the LONGCARD changes.
> 
> From a release engineering point of view this is more or less
> a nightmare. We cannot make incompatible extensions to the feature
> set after the fourth release candidate.
> 
> The only clean way I'd see to even get the LONGINT changes into the
> next release would be to start anew. Meaning declaring 5.8.4 as
> the latest release and develop 5.9 on the trunk. Of course we'd
> have to carefully merge back any fixes that might be missing on the
> trunk right now.
> 
> That said, I have currently neither the time nor the energy to do all
> that cleanly. I didn't even get round to set up release builds
> on new.elego.de via Hudson in order to cover the FreeBSD4 target
> platform we recently lost in the release due to my home machine's
> complete crash in December. So the release engineering support is not
> in the best of states I must admit.
> 
> I could live with declaring 5.8.RC4 as an intermediate release,
> but somebody really needs to do all the housekeeping of comparing
> and merging branches. And we shouldn't start a new release branch
> until things have settled down.
> 
> Is anybody interested in taking over some of the release engineering
> tasks (including Hudson management and re-targeting to the new release)?
> 
> Please keep in mind that we haven't managed to get out a stable release
> for several years now.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

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

From hosking at cs.purdue.edu  Sun Jan 17 17:13:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:13:39 -0500
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs.	head?
In-Reply-To: <COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>,
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<COL101-W28CEB78682A1DA879274B1E6670@phx.gbl>
Message-ID: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>

On 17 Jan 2010, at 08:42, Jay K wrote:

> We can stick with the current release branch if that is indeed much easier.
> 
> 
> I thought there was some agreement we shouldn't release LONGINT as it was.

Indeed!

> I can undo the changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff or diff (again, cvs
> seems not to help).

Surely we can move forward on this.

> Many/most/all of the fixes went first into head, so there's "nothing" to merge back,
> but diff tells us better.

I agree.

> I'm still planning on setting up some more machines and can do FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them first...)

Let's not worry about additional targets. 

> Does anyone have the missing steps for the cvsup bug report, like the configuration file,
> can show the callstacks, try it with user threads..etc..?

Maybe cvsup should not be part of the release?

> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more or less
> > a nightmare. We cannot make incompatible extensions to the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT changes into the
> > next release would be to start anew. Meaning declaring 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of course we'd
> > have to carefully merge back any fixes that might be missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the energy to do all
> > that cleanly. I didn't even get round to set up release builds
> > on new.elego.de via Hudson in order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my home machine's
> > complete crash in December. So the release engineering support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate release,
> > but somebody really needs to do all the housekeeping of comparing
> > and merging branches. And we shouldn't start a new release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the release engineering
> > tasks (including Hudson management and re-targeting to the new release)?
> > 
> > Please keep in mind that we haven't managed to get out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > 

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

From hosking at cs.purdue.edu  Sun Jan 17 17:39:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 11:39:03 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
Message-ID: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>

TRUNC_DIV_EXPR
FLOOR_DIV_EXPR
CEIL_DIV_EXPR
ROUND_DIV_EXPR
These nodes represent integer division operations that return an integer result. TRUNC_DIV_EXPR rounds towards zero, FLOOR_DIV_EXPRrounds towards negative infinity, CEIL_DIV_EXPR rounds towards positive infinity and ROUND_DIV_EXPR rounds to the closest integer. Integer division in C and C++ is truncating, i.e. TRUNC_DIV_EXPR.
The behavior of these operations on signed arithmetic overflow, when dividing the minimum signed integer by minus one, is controlled by the flag_wrapv and flag_trapv variables. 

TRUNC_MOD_EXPR
FLOOR_MOD_EXPR
CEIL_MOD_EXPR
ROUND_MOD_EXPR
These nodes represent the integer remainder or modulus operation. The integer modulus of two operands a and b is defined as a - (a/b)*b where the division calculated using the corresponding division operator. Hence for TRUNC_MOD_EXPR this definition assumes division using truncation towards zero, i.e. TRUNC_DIV_EXPR. Integer remainder in C and C++ uses truncating division, i.e.TRUNC_MOD_EXPR. 

This is a quote from the gcc internals manual.  I've always wondered why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for known positive operands.  What would be wrong about using them also for negative operands?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 17 Jan 2010, at 08:55, Jay K wrote:

> I have to admit I don't fully understand
> the division and modulo code in hand.c.
> 
> 
> I don't understand the old division code,
> but the documenation and behavior are
> clear: round down. I understand
> why my version works, though it might
> depend on non-guaranteed behavior in C division
> for the same sign cases. An earlier version
> was clearer since it avoided doing anything
> with negative numbers execpt negating them
> (and carefully at that).
> 
> 
> Modulo is much less clear to me.
> From testing vs. the documentation, I know the
> old code was wrong, though close.
> I made some guesses based on the old code and
> ran a variety of inputs through it.
> My version matches the old version, except
> where the old version is wrong.
> I could write a clearly correct version, but it
> would be perhaps much less efficient, just
> computing a - b * div(a, b).
> 
> 
> I tried running all 32bit inputs through some of it but it was
> going to take too long.
> I could maybe leave that running a few days if needed.
> 
>  - Jay
> 

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

From rodney_bates at lcwb.coop  Sun Jan 17 18:29:28 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 17 Jan 2010 11:29:28 -0600
Subject: [M3devel] integer division rounding?
In-Reply-To: <9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
	<9CF818E7-2374-4083-ACFA-81C5E9AE0167@cs.purdue.edu>
Message-ID: <4B5348F8.6070605@lcwb.coop>



Tony Hosking wrote:
> What do Pascal and Modula-2 and Oberon do?  M3 is in the same family...

For all of these, it is not so easy to decide what is the authoritative
definition.  They all suffer from worse dialect proliferation than Modula-3.
----------------------------------------------------------------------------
Original  Pascal report "The programming Language Pascal", Acta
Informatica, 1, 35-6 (1971) just says div is "division with truncation"
and the usual relationship: "m mod n = m-((m div n)*n)"

Does "truncate" mean towards zero or towards minus infinity?  Read on.
----------------------------------------------------------------------------
"An Axiomatic Definition of the Programming Langauge Pascal",
by C. A. R. Hoare and N. Wirth (apparently a tech report from
Eidgenoessische Technische Hochschule Zuerich (November 1972) says only:

"3.10. (m>=0) ^ ((n>0) => m-n < (m div n)*n <= m"

leaving div undefined for either operand negative.  It does give the
usual relationship.

----------------------------------------------------------------------------
"A Draft Proposal for Pascal", by A.M.Addyman (I have no citation
info for this, except the heading "technical contributions"--maybe
this was SIGPLAN?) says:

"It shall be an error if j is zero, otherwise the value of i div j
shall be such that
abs(i) - abs(j) < abs((i div j) * j) <= abs(i)
where the value shall be zero if abs(i)<abs(j), otherwise the sign
of the value shall be positive if i and j have the same sign and
negative if i and j have different signs.

This is truncating toward zero, which agrees with my memory about Pascal.
------------------------------------------------------------------------------
A "Draft ISO Standard for Pascal" that I have, dated 1982-08-12,
says the same thing about div, but adds:

"A term of the form i mod j shall be an error if j is zero or negative, otherwise the
value of i mod j shall be that value of (i-(k*j)) for integral k such that
0 <= i mod j < j."

disallowing negative j.
-----------------------------------------------------------------------------------
"Programming in Modula-2", Niklaus Wirth, 4th edition, Springer-Verlag, 1988, says:

"x DIV y is equal to the truncated quotient of x/y
  x MOD y is equal to the remainder of the division x DIV y
  x = (x DIV y) * y + (x MOD y), 0 <= (x MOD y) < y"

the last condition implying that MOD is either undefined or an error
for negative y.
-----------------------------------------------------------------------------------

I don't have any Oberon variant definitions quickly accessible.

I recall disliking the Pascal/M2 habit of truncating towards zero as both
inconsistent with traditional mathematics and not want you need as a programmer,
at least in the application of doing subscript arithmetic in circular buffers.
I was glad to see Modula-3 fix that.

> 
> On 17 Jan 2010, at 04:36, Jay K wrote:
> 
>> Modula-3 apparently specifies integer division as rounding down.
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> C used to leave it unspecified. So it could be fast.
>> Fortran rounded to zero.
>> C's ldiv function rounds to zero.
>> C now rounds to zero with C99.
>>   The rationale was that nobody using Fortran seemed to mind.
>> Java apparently rounds toward zero.
>> C# apparently rounds toward zero.
>>
>>
>> I'm assuming we are stuck being different here?
>>
>>  - Jay
>>
> 


From wagner at elegosoft.com  Sun Jan 17 19:44:29 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 17 Jan 2010 19:44:29 +0100
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re:
	release	vs. head?
In-Reply-To: <A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
References: <COL101-W642FC30B5775EF9434C989E6680@phx.gbl>
	<20100117123816.oxptrfhk0goowkk0@mail.elegosoft.com>
	<A72AFF19-2355-4EBD-8393-5FC0E503E7C7@cs.purdue.edu>
Message-ID: <20100117194429.pvmnaij280s4gck0@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> I think that we are closest now to a release we can be happy with   
> than for some time.  It would be a huge shame not to push this out   
> the door.

OK, I doubt there is very much interest from other users how we do this,
so let's be unorthodox again ;-) Let's just stick to the existing
release branch and let RC 5.8.5 be somewhat incompatible with RC 5.8.4.
Everything else would be too much hassle for too few users
(at least I think so). As I doubt there's anybody who wants to start
the release engineering again, we will just use the existing branch
and move forward.

Any objections?

Olaf

> On 17 Jan 2010, at 06:38, Olaf Wagner wrote:
>
>> Quoting Jay K <jay.krell at cornell.edu>:
>>
>>> Should we just make a new release branch?
>>> Or I keep copying stuff over somewhat selectively?
>>>  We do want LONGCARD in the release, I assume.
>>>
>>> I'll diff the two trees again, see what varies.
>>> Sometimes when I do that I find stuff to take.
>>> And take the LONGCARD changes.
>>
>> From a release engineering point of view this is more or less
>> a nightmare. We cannot make incompatible extensions to the feature
>> set after the fourth release candidate.
>>
>> The only clean way I'd see to even get the LONGINT changes into the
>> next release would be to start anew. Meaning declaring 5.8.4 as
>> the latest release and develop 5.9 on the trunk. Of course we'd
>> have to carefully merge back any fixes that might be missing on the
>> trunk right now.
>>
>> That said, I have currently neither the time nor the energy to do all
>> that cleanly. I didn't even get round to set up release builds
>> on new.elego.de via Hudson in order to cover the FreeBSD4 target
>> platform we recently lost in the release due to my home machine's
>> complete crash in December. So the release engineering support is not
>> in the best of states I must admit.
>>
>> I could live with declaring 5.8.RC4 as an intermediate release,
>> but somebody really needs to do all the housekeeping of comparing
>> and merging branches. And we shouldn't start a new release branch
>> until things have settled down.
>>
>> Is anybody interested in taking over some of the release engineering
>> tasks (including Hudson management and re-targeting to the new release)?
>>
>> Please keep in mind that we haven't managed to get out a stable release
>> for several years now.
>>
>> Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Sun Jan 17 21:19:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:19:14 -0500
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100117201914.GD11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 09:36:55AM +0000, Jay K wrote:
> 
> Modula-3 apparently specifies integer division as rounding down.
> http://www.modula3.com/cm3/doc/reference/arithmetic.html

In my experience, the rounding direction on division as supported by 
hardware seems is correlated with whether the processor uses one's 
complement or two's complement arithmetic.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:34:06 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:34:06 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
Message-ID: <20100117203406.GE11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> 
> -2147483648 div 2147483647 ?
> -2147483648 mod 2147483647 ?
> 
> quotient = -1, remainer = -1 seems reasonable.
> 2147483647 * -1 + -1 == -2147483648
> 

There are two kinds of binary integer arithmetic -- two's complement 
and one's complement.  In my experience, two's complement machines tend 
to have the remainder being the same sign as the dividend; one's 
complement machines semm to have a remainder the same sign as the 
divisor.

One's complement machines are all but extinct these days.

> 
> However, Modula-3 specifies div as rounding down, so
> 
> -2147483648 div 2147483647  == -2
> 
> and then
> 
> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> 
> The value x DIV y is the floor of 
> the quotient of x and y; that is, the maximum integer 
> not exceeding the real number z such that z * y = x.
> For integers x and y, the value of x MOD y is 
> defined to be x - y * (x DIV y).
> 
> 
> This means that for positive y, the value of x MOD y
> lies in the interval [0 .. y-1], regardless of 
> the sign of x.  For negative y, the value of
> x MOD y lies in the interval [y+1 .. 0], regardless 
> of the sign of x.

And this is consistent with MOD producing a canonical representative of 
an equivalence class modulo y.  It's what's wanted for a lot of 
algorithms.  What it returns for negative y isn't as important, but 
it is important to have positive MODuli for positive y no matter what 
the sign of x is.

But it's not what most two's-complement processors produce naturally.  
Having a MODulo operation that is mathematically well-behaved takes 
extra effort on these machines.

And it's also important to have a remainder that corresponds to the 
division operator.  On two's complement machines you have to either
  * use extra instructions to correct the result of the divide 
    instruction to correspond to the mathematically desirable MOD 
    operator, or
  * Have a separate remainder operation that does correspond to 
    division.

On one's complement machines MOD will have the same effect as remainder.
On two's complement, different.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:39:42 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:39:42 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>
Message-ID: <20100117203942.GF11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> On 17 Jan 2010, at 05:50, Jay K wrote:
> 
> > I think I missed a sign.
> > 
> > -2147483648 - 2147483647  * -2
> >  actually -2147483648 + 2 * 2147483647
> >   actually 2147483646
> > 
> > which agrees.
> > 
> > so 
> > 
> > -2147483648 div 2147483647 = -2 
> > -2147483648 mod 2147483647 = 2147483646 
> > 
> > -2 * 2147483647 + 2147483646  = -2147483648
> > 
> > I'll make sure m3_mod works this way if it doesn't already.
> > Presumably we are stuck with these rules.
> 
> Yep.  I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how.  Anyone?

It gives results that satisfy important mathematical identities, such as

     (a + m) MOD m = a MOD m

which makes it easier to reason about the correctness of algorithms and 
program  transformations.

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 17 21:48:30 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 15:48:30 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
Message-ID: <20100117204830.GG11416@topoi.pooq.com>

On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> 
> This is a quote from the gcc internals manual.  I've always wondered 
> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for 
> known positive operands.  What would be wrong about using them also 
> for negative operands?

What does cm3cg use for operands that are not known to be positive?

-- hendrik


From hosking at cs.purdue.edu  Sun Jan 17 22:19:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Jan 2010 15:19:21 -0600
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <20100117204830.GG11416@topoi.pooq.com>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>
	<20100117204830.GG11416@topoi.pooq.com>
Message-ID: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>

It calls the C routines in hand.c.

Sent from my iPhone

On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
>>
>> This is a quote from the gcc internals manual.  I've always wondered
>> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
>> known positive operands.  What would be wrong about using them also
>> for negative operands?
>
> What does cm3cg use for operands that are not known to be positive?
>
> -- hendrik


From jay.krell at cornell.edu  Mon Jan 18 02:01:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:01:39 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203942.GF11416@topoi.pooq.com>
References: <COL101-W5697CAA4F0EE5C52153986E6670@phx.gbl>,
	<67D603C3-650C-4542-BD8B-D566C8F01BFF@cs.purdue.edu>,
	<20100117203942.GF11416@topoi.pooq.com>
Message-ID: <COL101-W61AE85464E81AF91D50FA3E6660@phx.gbl>


Thanks Hendrik. I didn't realize the relationship to one's complement.

In my little experimentation:

 C modulo, which I assume is machine modulo, returns the sign of the first parameter.

 Modula-3 specifies it to have the sign of the second parameter.

 The "formula" appears to hold either way.

  But I'd have to double check.

 

 

Hand.c used "tricks" to implement div and mod.

My replacement functions are clear for div but still tricky for mod.

I don't understand the tricks.

In fact I just guessed and wrote something similar to the original, but different.

 

 

One goal was to avoid dependency on signed arithmetic overflow, though

 I compromised somewhat, I think. That is, I'm not sure if negative / negative

  and negative mod negative in C depend on overflow.

  What gcc was telling me is the "trick" in the old div function did depend

  on modulo. Ultimately I'm not sure if this dependency was even a problem or not,

  as the bug at least for div tended to occur more with unoptimized compilation.

  Optimization actually tended to fix the bug. But it did vary with compilers.

  Specifically dividing and moding LONG_MIN (or INT64_MIN) by negative numbers

  produced a result with the wrong sign. There was probably also a problem

  with K&R style. The "crash" or "trap" was appropriate.

 

 

I was *actually* wondering if depency on overflow would be a problem

for the other functions I added, but apparently not.

Still I might consider writing them to use only unsigned, or deleting them.

 

 

One of my implied questions is:
  Do people believe my changes are correct?

  Please look at them.

  Esp. mod.

 

 

 - Jay

 
> Date: Sun, 17 Jan 2010 15:39:42 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> On Sun, Jan 17, 2010 at 11:08:15AM -0500, Tony Hosking wrote:
> > On 17 Jan 2010, at 05:50, Jay K wrote:
> > 
> > > I think I missed a sign.
> > > 
> > > -2147483648 - 2147483647 * -2
> > > actually -2147483648 + 2 * 2147483647
> > > actually 2147483646
> > > 
> > > which agrees.
> > > 
> > > so 
> > > 
> > > -2147483648 div 2147483647 = -2 
> > > -2147483648 mod 2147483647 = 2147483646 
> > > 
> > > -2 * 2147483647 + 2147483646 = -2147483648
> > > 
> > > I'll make sure m3_mod works this way if it doesn't already.
> > > Presumably we are stuck with these rules.
> > 
> > Yep. I seem to remember reading some rationale somewhere sometime somehow, but I forget where when how. Anyone?
> 
> It gives results that satisfy important mathematical identities, such as
> 
> (a + m) MOD m = a MOD m
> 
> which makes it easier to reason about the correctness of algorithms and 
> program transformations.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/0791186c/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jan 18 02:06:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:06:32 +0000
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
Message-ID: <COL101-W4203E93E82A73319794582E6660@phx.gbl>


I *speculate*:

   If the inputs to div or mod are known to have the same sign: don't bother calling the functions.

      Certainly that is clear for two positive inputs in the old functions.

   If either input to div is known to be zero, ditto. Presumably not a common case.

      And *maybe* we want to alter how divide by zero works to reliably trap or not trap.

 

  For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.

    (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)

 

 

 - Jay


 
> From: hosking at cs.purdue.edu
> To: hendrik at topoi.pooq.com
> Date: Sun, 17 Jan 2010 15:19:21 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how division and modulo work in hand.c?
> 
> It calls the C routines in hand.c.
> 
> Sent from my iPhone
> 
> On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> >>
> >> This is a quote from the gcc internals manual. I've always wondered
> >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> >> known positive operands. What would be wrong about using them also
> >> for negative operands?
> >
> > What does cm3cg use for operands that are not known to be positive?
> >
> > -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/95985a3a/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jan 18 02:11:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 01:11:20 +0000
Subject: [M3devel] another change in hand.c
Message-ID: <COL101-W46DA48ECED7FEDC4F05B82E6660@phx.gbl>


Also I changed set_eq and set_ne to just use memcmp.

 

 

That certainly appears correct.

I believe I added some tests to m3-sys/m3tests.

I also changed the integrated backend to call memcmp directly.

Given the input is known to be ulongs not just bytes, this

might be a deoptimization. However hand.c isn't necessarily

compiled with optimizations.

 

 

You know, memcmp generally handles any alignment.

First it often has to handle a leading unaligned part before

proceeding to compare data in larger chunks.

Whereas if you know the alignment you can be faster.

 

 

I believe m3front inlines for small sets anyway.

 

 

 - Jay

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

From mika at async.async.caltech.edu  Mon Jan 18 02:58:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:58:33 -0800
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl> 
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <20100118015833.708F71A207C@async.async.caltech.edu>


Jay I think the following paragraph is important and demonstrates why
this article is perhaps less relevant to Modula-3:

When you write a function implementing a numeric algorithm (for example,
calculating the phase of the moon) you typically expect the arguments
to be specified as floating point numbers. However, since Python doesnt
have type declarations, nothing is there to stop a caller from providing
you with integer arguments. In a statically typed language, like C,
the compiler will coerce the arguments to floats, but Python does no
such thing  the algorithm is run with integer values until the wonders
of mixed-mode arithmetic produce intermediate results that are floats.

     Mika

Jay K writes:
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml
>
>
>He argues that for a "high level" language=2C of course
>I should be able to add int to long=2C int to float=2C etc.
>And that int / int should not be int.
>At least Modula-3 spells them differently=2C / vs. MOD.
>
>
>Of course=2C "high level" vs. "systems" vs. "one size to fit all"...
>
>
>Anyway=2C I give up here.
>
>
> - Jay
>
>
>
>
> 		 	   		  =
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
>ml<br><br><br>He argues that for a "high level" language=2C of course<br>I =
>should be able to add int to long=2C int to float=2C etc.<br>And that int /=
> int should not be int.<br>At least Modula-3 spells them differently=2C / v=
>s. MOD.<br><br><br>Of course=2C "high level" vs. "systems" vs. "one size to=
> fit all"...<br><br><br>Anyway=2C I give up here.<br><br><br>&nbsp=3B- Jay<=
>br><br><br><br><br> 		 	   		  </body>
></html>=
>
>--_671e4a34-689a-4d86-98d3-1f8935f7844b_--


From mika at async.async.caltech.edu  Mon Jan 18 02:59:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sun, 17 Jan 2010 17:59:59 -0800
Subject: [M3devel] integer division rounding?
In-Reply-To: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl> 
References: <COL101-W169D0A02AD78DBCDFDE75AE6670@phx.gbl>
Message-ID: <20100118015959.BB9911A207C@async.async.caltech.edu>

Jay K writes:
>--_80188ab7-0cb8-4a34-8b91-f5a76ee2640e_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Modula-3 apparently specifies integer division as rounding down.
>http://www.modula3.com/cm3/doc/reference/arithmetic.html
>
>C used to leave it unspecified. So it could be fast.
>Fortran rounded to zero.
>C's ldiv function rounds to zero.
>C now rounds to zero with C99.
>  The rationale was that nobody using Fortran seemed to mind.
>Java apparently rounds toward zero.
>C# apparently rounds toward zero.
>
>
>I'm assuming we are stuck being different here?
>
> - Jay
>

This is because Modula-3 has MOD while C has "remainder" (%).

If you use the normal definition of MOD you're stuck with making
DIV match it I think...

    Mika


From hendrik at topoi.pooq.com  Mon Jan 18 03:21:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 17 Jan 2010 21:21:35 -0500
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118015833.708F71A207C@async.async.caltech.edu>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
	<20100118015833.708F71A207C@async.async.caltech.edu>
Message-ID: <20100118022134.GA23436@topoi.pooq.com>

On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> 
> Jay I think the following paragraph is important and demonstrates why
> this article is perhaps less relevant to Modula-3:
> 
> When you write a function implementing a numeric algorithm (for example,
> calculating the phase of the moon) you typically expect the arguments
> to be specified as floating point numbers. However, since Python doesnt
> have type declarations, nothing is there to stop a caller from providing
> you with integer arguments. In a statically typed language, like C,
> the compiler will coerce the arguments to floats, but Python does no
> such thing  the algorithm is run with integer values until the wonders
> of mixed-mode arithmetic produce intermediate results that are floats.
> 
>      Mika
> 
> Jay K writes:
> >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> >ml
> >
> >
> >He argues that for a "high level" language=2C of course

He identifies python as a high-level language.  His arguments about what 
a high-level language should do are based on python's absence of static 
typing.  Thus he comes to his conclusion, having identified the concept 
of "high level" with "no static typing".  Presumably he thinls that 
types are an inconvenience inflicted by the desire for run-time 
efficiency.  Many people believe this, failing entirely to notice that 
static typing is a powerful tool in the pursuit of correctness.

-- hendrik


From jay.krell at cornell.edu  Mon Jan 18 04:37:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 03:37:30 +0000
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <20100118022134.GA23436@topoi.pooq.com>
References: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>,
	<20100118015833.708F71A207C@async.async.caltech.edu>,
	<20100118022134.GA23436@topoi.pooq.com>
Message-ID: <COL101-W38145B37DE6AD23BE9C563E6660@phx.gbl>


I am mostly a believer in static types.

 

Though there sure is an interesting place in

languages like C#, C++, ML, where the compiler

is *obligated* in many contexts to deduce static

type and in which it really isn't very controversial.

 

This leads to, for example, qsort that can "easily"

inline the comparison function and beat C.

 

C# has this nifty "LINQ" stuff where to actually

have the programmer state the static types

would be quite onerous.

 

 

A similar scenario is "expression templates" in C++.

Where you have a + b * c / d and the types

of a, b, c, d are a variety of vectors/matrices,

and there are no actual intermediate computations done,

just one inner loop, because the type of the overloads

doesn't hold an intermediate result but rather sort of "directions"

on how to proceed. See Todd Veldhuzien's fascinating work.

http://en.wikipedia.org/wiki/Expression_templates

 

 

The dynamic type proponents do have strong arguments in some situations:

 - You are going to throw out the code soon anyway, sometimes.

 - You have to run it, test it, and that somewhat substitutes for whatever checks the "compiler" makes.

 

 - Jay





 
> Date: Sun, 17 Jan 2010 21:21:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] in favor of mixed operators..
> 
> On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:
> > 
> > Jay I think the following paragraph is important and demonstrates why
> > this article is perhaps less relevant to Modula-3:
> > 
> > When you write a function implementing a numeric algorithm (for example,
> > calculating the phase of the moon) you typically expect the arguments
> > to be specified as floating point numbers. However, since Python doesnt
> > have type declarations, nothing is there to stop a caller from providing
> > you with integer arguments. In a statically typed language, like C,
> > the compiler will coerce the arguments to floats, but Python does no
> > such thing the algorithm is run with integer values until the wonders
> > of mixed-mode arithmetic produce intermediate results that are floats.
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_671e4a34-689a-4d86-98d3-1f8935f7844b_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=
> > >ml
> > >
> > >
> > >He argues that for a "high level" language=2C of course
> 
> He identifies python as a high-level language. His arguments about what 
> a high-level language should do are based on python's absence of static 
> typing. Thus he comes to his conclusion, having identified the concept 
> of "high level" with "no static typing". Presumably he thinls that 
> types are an inconvenience inflicted by the desire for run-time 
> efficiency. Many people believe this, failing entirely to notice that 
> static typing is a powerful tool in the pursuit of correctness.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/3ce6d925/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jan 18 14:05:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 18 Jan 2010 13:05:58 +0000
Subject: [M3devel] FW: __int128 coming to gcc
In-Reply-To: <1263819673.24181.ezmlm@gcc.gnu.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
Message-ID: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>


gcc 4.6 apparently will have __int128.

How long until we have LONGLONGINT or INT128?

Presumably we should have LONGLONGINT or INT128 to expose it?

:)

 

 

Or, again, I should look at the arithemetic library...

 

 

 - Jay

 

 

Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
 
... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  	review
	255919 by: Kai Tietz <ktietz70@>
 
...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
.... 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100118/9e165e65/attachment-0002.html>

From hosking at cs.purdue.edu  Mon Jan 18 14:47:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 08:47:41 -0500
Subject: [M3devel] how division and modulo work in hand.c?
In-Reply-To: <COL101-W4203E93E82A73319794582E6660@phx.gbl>
References: <COL101-W57B3EF55700E136A6A3A1EE6670@phx.gbl>,
	<3F35CC2B-9EAF-4E77-B22A-27579D379C69@cs.purdue.edu>,
	<20100117204830.GG11416@topoi.pooq.com>,
	<0D8DEA24-5E91-4804-9E0D-DF791E406CDB@cs.purdue.edu>
	<COL101-W4203E93E82A73319794582E6660@phx.gbl>
Message-ID: <533DD3F9-B74D-4796-AD6D-CA3986A610C1@cs.purdue.edu>

cm3cg currently only uses FLOOR_DIV_EXPR for known positive integers.  For anything else it calls out to the library.

On 17 Jan 2010, at 20:06, Jay K wrote:

> I *speculate*:
>    If the inputs to div or mod are known to have the same sign: don't bother calling the functions.
>       Certainly that is clear for two positive inputs in the old functions.
>    If either input to div is known to be zero, ditto. Presumably not a common case.
>       And *maybe* we want to alter how divide by zero works to reliably trap or not trap.
>  
>   For example, CARDINAL and LONGCARD DIV and MOD need not call the functions ever.
>     (again, caveat, maybe for zero, maybe, not currently, but if we make trapping divide by zero controllable)
>  
>  
>  - Jay
> 
>  
> > From: hosking at cs.purdue.edu
> > To: hendrik at topoi.pooq.com
> > Date: Sun, 17 Jan 2010 15:19:21 -0600
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] how division and modulo work in hand.c?
> > 
> > It calls the C routines in hand.c.
> > 
> > Sent from my iPhone
> > 
> > On Jan 17, 2010, at 2:48 PM, hendrik at topoi.pooq.com wrote:
> > 
> > > On Sun, Jan 17, 2010 at 11:39:03AM -0500, Tony Hosking wrote:
> > >>
> > >> This is a quote from the gcc internals manual. I've always wondered
> > >> why cm3cg uses the built-in FLOOR_DIV_EXPR/FLOOR_MOD_EXPR only for
> > >> known positive operands. What would be wrong about using them also
> > >> for negative operands?
> > >
> > > What does cm3cg use for operands that are not known to be positive?
> > >
> > > -- hendrik

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

From hosking at cs.purdue.edu  Mon Jan 18 15:03:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 09:03:21 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
Message-ID: <298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>

On 18 Jan 2010, at 08:05, Jay K wrote:

> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)

Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as

BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]

>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....

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

From Highjinks at gmx.com  Mon Jan 18 23:11:15 2010
From: Highjinks at gmx.com (Chris)
Date: Mon, 18 Jan 2010 23:11:15 +0100 (CET)
Subject: [M3devel] Explicit types.
Message-ID: <20100118181413.6aaac7d6.Highjinks@gmx.com>

I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.

I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
	
	TYPE UnsignedInt64 ...
	TYPE SignedInt64 ...
	TYPE UnsignedInt32 ...
	TYPE SignedInt32 ...

etc...

Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.

Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.

I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.

I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.

-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Mon Jan 18 23:17:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 18 Jan 2010 17:17:54 -0500
Subject: [M3devel] Explicit types.
In-Reply-To: <20100118181413.6aaac7d6.Highjinks@gmx.com>
References: <20100118181413.6aaac7d6.Highjinks@gmx.com>
Message-ID: <1F367F97-CA3E-4EE4-A103-C446A21BF339@cs.purdue.edu>

Hi Chris,

I think we gave settled on a good fit for long integer types for Modula-3.  Things are unlikely to change further.

--  Tony

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 18 Jan 2010, at 17:11, Chris wrote:

> I've spent some time perusing the source tree, and particularly anything dealing with 32/64 bit portability.
> 
> I'm wondering if it might make sense to define some explicit 32bit and 64bit types, perhaps at the library level, to ease porting. Types such as ...
> 	
> 	TYPE UnsignedInt64 ...
> 	TYPE SignedInt64 ...
> 	TYPE UnsignedInt32 ...
> 	TYPE SignedInt32 ...
> 
> etc...
> 
> Eventually the goal, as I understand it, is to have a 64bit LongInt type, however the above might serve useful as an intermediate step. The primary advantage to this approach is that the developers would know exactly what the machine representation of the variable/value is. No guesswork involved.
> 
> Also, as a step to full 64bit compatibility, it might make sense to define some sort of Region/Arena based memory manager that could be used in lieu of, or as an alternative to, the runtime garbage collector. Not as flexible, but far more predictable.
> 
> I'm doing some hacking on the tests, and I might try this approach with my local sources just to see how well(or poorly) it would work.
> 
> I'm still wrapping my brain around Modula 3s reference types, Thier slightly different from what I'm used to.
> 
> -- 
> Chris <Highjinks at gmx.com>

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

From rodney_bates at lcwb.coop  Wed Jan 20 01:39:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 19 Jan 2010 18:39:22 -0600
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <20100117203406.GE11416@topoi.pooq.com>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
Message-ID: <4B5650BA.6030601@lcwb.coop>



hendrik at topoi.pooq.com wrote:
> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>> -2147483648 div 2147483647 ?
>> -2147483648 mod 2147483647 ?
>>
>> quotient = -1, remainer = -1 seems reasonable.
>> 2147483647 * -1 + -1 == -2147483648
>>
> 
> There are two kinds of binary integer arithmetic -- two's complement 
> and one's complement.  In my experience, two's complement machines tend 
> to have the remainder being the same sign as the dividend; one's 
> complement machines semm to have a remainder the same sign as the 
> divisor.
> 
> One's complement machines are all but extinct these days.

Tony, you were concerned about showing your age, but 20 years is but an
evening past.  I remember programming ones-complement arithmetic
in assembly language, definitely more decades ago than two.
And that was not my first job.

There is a positive zero and a negative zero, and which one you get
can depend on the operation and operand values that produced the
result, so you have to check for both of them, often with two
separate conditional branches.

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?


> 
>> However, Modula-3 specifies div as rounding down, so
>>
>> -2147483648 div 2147483647  == -2
>>
>> and then
>>
>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>
>> The value x DIV y is the floor of 
>> the quotient of x and y; that is, the maximum integer 
>> not exceeding the real number z such that z * y = x.
>> For integers x and y, the value of x MOD y is 
>> defined to be x - y * (x DIV y).
>>
>>
>> This means that for positive y, the value of x MOD y
>> lies in the interval [0 .. y-1], regardless of 
>> the sign of x.  For negative y, the value of
>> x MOD y lies in the interval [y+1 .. 0], regardless 
>> of the sign of x.
> 
> And this is consistent with MOD producing a canonical representative of 
> an equivalence class modulo y.  It's what's wanted for a lot of 
> algorithms.  What it returns for negative y isn't as important, but 
> it is important to have positive MODuli for positive y no matter what 
> the sign of x is.
> 
> But it's not what most two's-complement processors produce naturally.  
> Having a MODulo operation that is mathematically well-behaved takes 
> extra effort on these machines.
> 
> And it's also important to have a remainder that corresponds to the 
> division operator.  On two's complement machines you have to either
>   * use extra instructions to correct the result of the divide 
>     instruction to correspond to the mathematically desirable MOD 
>     operator, or
>   * Have a separate remainder operation that does correspond to 
>     division.
> 
> On one's complement machines MOD will have the same effect as remainder.
> On two's complement, different.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed Jan 20 03:45:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:45:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <COL101-W5066919E7799495954BF25E6640@phx.gbl>


> There is a positive zero and a negative zero, and which one you get 

 
 Rodney you reminded me of something I forgot to ask: 
 
 
Is 0 div -1 = 0 or -1?
 
 
In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
If 0> -0, then 0 div -1 should equal -1 instead of 0.
 
 
My current code I believe returns 0 for 0 div anything.
  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
 
 
The previous code probably also but I'll have to double check.
  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
 
 
  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
 
 
  Nice if anyone can reproduce the problem with K&R + long long as well.
  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
 
 
  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
 
 
  In particular, LONG_MIN div or mod -1 can trap.
 
 
  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
 
 
(anywhere I say "LONG_MIN", INT64_MIN has similar problem)
 
 
 
 - Jay


----------------------------------------
> Date: Tue, 19 Jan 2010 18:39:22 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>
> hendrik at topoi.pooq.com wrote:
>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>> -2147483648 div 2147483647 ?
>>> -2147483648 mod 2147483647 ?
>>>
>>> quotient = -1, remainer = -1 seems reasonable.
>>> 2147483647 * -1 + -1 == -2147483648
>>>
>>
>> There are two kinds of binary integer arithmetic -- two's complement
>> and one's complement. In my experience, two's complement machines tend
>> to have the remainder being the same sign as the dividend; one's
>> complement machines semm to have a remainder the same sign as the
>> divisor.
>>
>> One's complement machines are all but extinct these days.
>
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past. I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
>
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
>
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines? Electromechanical accounting machines?
>
>
>>
>>> However, Modula-3 specifies div as rounding down, so
>>>
>>> -2147483648 div 2147483647 == -2
>>>
>>> and then
>>>
>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>
>>> The value x DIV y is the floor of
>>> the quotient of x and y; that is, the maximum integer
>>> not exceeding the real number z such that z * y = x.
>>> For integers x and y, the value of x MOD y is
>>> defined to be x - y * (x DIV y).
>>>
>>>
>>> This means that for positive y, the value of x MOD y
>>> lies in the interval [0 .. y-1], regardless of
>>> the sign of x. For negative y, the value of
>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>> of the sign of x.
>>
>> And this is consistent with MOD producing a canonical representative of
>> an equivalence class modulo y. It's what's wanted for a lot of
>> algorithms. What it returns for negative y isn't as important, but
>> it is important to have positive MODuli for positive y no matter what
>> the sign of x is.
>>
>> But it's not what most two's-complement processors produce naturally.
>> Having a MODulo operation that is mathematically well-behaved takes
>> extra effort on these machines.
>>
>> And it's also important to have a remainder that corresponds to the
>> division operator. On two's complement machines you have to either
>> * use extra instructions to correct the result of the divide
>> instruction to correspond to the mathematically desirable MOD
>> operator, or
>> * Have a separate remainder operation that does correspond to
>> division.
>>
>> On one's complement machines MOD will have the same effect as remainder.
>> On two's complement, different.
>>
>> -- hendrik
>> 		 	   		  

From jay.krell at cornell.edu  Wed Jan 20 03:59:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 02:59:43 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>


That paper also suggests a more efficient algorithm we should probably adopt:
 
 
/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}

 
long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}
 
 
Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)

 
We'd probably want to be sure the / followed by % got optimized into just one divide though.
 
 
or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.
 
 
Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Date: Wed, 20 Jan 2010 02:45:43 +0000
> Subject: Re: [M3devel] integer division/mod questions?
>
>
>> There is a positive zero and a negative zero, and which one you get
>
>
> Rodney you reminded me of something I forgot to ask:
>
>
> Is 0 div -1 = 0 or -1?
>
>
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>
>
> My current code I believe returns 0 for 0 div anything.
> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>
>
> The previous code probably also but I'll have to double check.
> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>
>
> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>
>
> Nice if anyone can reproduce the problem with K&R + long long as well.
> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>
>
> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>
>
> In particular, LONG_MIN div or mod -1 can trap.
>
>
> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>
>
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>
>
>
> - Jay
>
>
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>>
>>
>>
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>>
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>>
>>>
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>>
>>> One's complement machines are all but extinct these days.
>>
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>>
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>>
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>>
>>
>>>
>>>> However, Modula-3 specifies div as rounding down, so
>>>>
>>>> -2147483648 div 2147483647 == -2
>>>>
>>>> and then
>>>>
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>>
>>>>
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>>
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>>
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>>
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>>
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>>
>>> -- hendrik
>>> 		 	   		  

From hosking at cs.purdue.edu  Wed Jan 20 11:07:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:07:45 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	<20100117203406.GE11416@topoi.pooq.com>,
	<4B5650BA.6030601@lcwb.coop>
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
Message-ID: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>

These are all overflow examples correct?  In which case the meaning is undefined?

But certainly, 0 DIV -1 should be 0.

I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy.  In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations?  I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.

On 19 Jan 2010, at 21:45, Jay K wrote:

> 
>> There is a positive zero and a negative zero, and which one you get 
> 
> 
> Rodney you reminded me of something I forgot to ask: 
> 
> 
> Is 0 div -1 = 0 or -1?
> 
> 
> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> If 0> -0, then 0 div -1 should equal -1 instead of 0.
> 
> 
> My current code I believe returns 0 for 0 div anything.
>  And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> 
> 
> The previous code probably also but I'll have to double check.
>  The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> 
> 
>  Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> 
> 
>  Nice if anyone can reproduce the problem with K&R + long long as well.
>  I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> 
> 
>  The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> 
> 
>  In particular, LONG_MIN div or mod -1 can trap.
> 
> 
>  div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> 
> 
> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>> 
>> hendrik at topoi.pooq.com wrote:
>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>> -2147483648 div 2147483647 ?
>>>> -2147483648 mod 2147483647 ?
>>>> 
>>>> quotient = -1, remainer = -1 seems reasonable.
>>>> 2147483647 * -1 + -1 == -2147483648
>>>> 
>>> 
>>> There are two kinds of binary integer arithmetic -- two's complement
>>> and one's complement. In my experience, two's complement machines tend
>>> to have the remainder being the same sign as the dividend; one's
>>> complement machines semm to have a remainder the same sign as the
>>> divisor.
>>> 
>>> One's complement machines are all but extinct these days.
>> 
>> Tony, you were concerned about showing your age, but 20 years is but an
>> evening past. I remember programming ones-complement arithmetic
>> in assembly language, definitely more decades ago than two.
>> And that was not my first job.
>> 
>> There is a positive zero and a negative zero, and which one you get
>> can depend on the operation and operand values that produced the
>> result, so you have to check for both of them, often with two
>> separate conditional branches.
>> 
>> Anyone remember nines- or tens-complement arithmetic on decimal
>> machines? Electromechanical accounting machines?
>> 
>> 
>>> 
>>>> However, Modula-3 specifies div as rounding down, so
>>>> 
>>>> -2147483648 div 2147483647 == -2
>>>> 
>>>> and then
>>>> 
>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>> 
>>>> The value x DIV y is the floor of
>>>> the quotient of x and y; that is, the maximum integer
>>>> not exceeding the real number z such that z * y = x.
>>>> For integers x and y, the value of x MOD y is
>>>> defined to be x - y * (x DIV y).
>>>> 
>>>> 
>>>> This means that for positive y, the value of x MOD y
>>>> lies in the interval [0 .. y-1], regardless of
>>>> the sign of x. For negative y, the value of
>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>> of the sign of x.
>>> 
>>> And this is consistent with MOD producing a canonical representative of
>>> an equivalence class modulo y. It's what's wanted for a lot of
>>> algorithms. What it returns for negative y isn't as important, but
>>> it is important to have positive MODuli for positive y no matter what
>>> the sign of x is.
>>> 
>>> But it's not what most two's-complement processors produce naturally.
>>> Having a MODulo operation that is mathematically well-behaved takes
>>> extra effort on these machines.
>>> 
>>> And it's also important to have a remainder that corresponds to the
>>> division operator. On two's complement machines you have to either
>>> * use extra instructions to correct the result of the divide
>>> instruction to correspond to the mathematically desirable MOD
>>> operator, or
>>> * Have a separate remainder operation that does correspond to
>>> division.
>>> 
>>> On one's complement machines MOD will have the same effect as remainder.
>>> On two's complement, different.
>>> 
>>> -- hendrik
>>> 		 	   		  



From hosking at cs.purdue.edu  Wed Jan 20 11:09:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 05:09:33 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>

C specifies truncated division.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 19 Jan 2010, at 21:59, Jay K wrote:

> 
> That paper also suggests a more efficient algorithm we should probably adopt:
> 
> 
> /* Floored division */
> long divF( long D, long d )
> {
> long q = D/d;
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
> return q;
> }
> 
> 
> long modF( long D, long d )
> {
> long r = D%d;
> if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
> return r;
> }
> 
> 
> Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
> or (r < 0) ^ (d < 0)
> 
> 
> We'd probably want to be sure the / followed by % got optimized into just one divide though.
> 
> 
> or maybe what I have is fine.
> As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
> I am assuming C never "rounds", but either truncates or "floors".
> e.g. 1/2 in the face of rounding is 1.
> 
> 
> Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
>> Date: Wed, 20 Jan 2010 02:45:43 +0000
>> Subject: Re: [M3devel] integer division/mod questions?
>> 
>> 
>>> There is a positive zero and a negative zero, and which one you get
>> 
>> 
>> Rodney you reminded me of something I forgot to ask:
>> 
>> 
>> Is 0 div -1 = 0 or -1?
>> 
>> 
>> In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
>> If 0> -0, then 0 div -1 should equal -1 instead of 0.
>> 
>> 
>> My current code I believe returns 0 for 0 div anything.
>> And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
>> 
>> 
>> The previous code probably also but I'll have to double check.
>> The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
>> 
>> 
>> Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
>> 
>> 
>> Nice if anyone can reproduce the problem with K&R + long long as well.
>> I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
>> 
>> 
>> The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
>> 
>> 
>> In particular, LONG_MIN div or mod -1 can trap.
>> 
>> 
>> div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
>> 
>> 
>> (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> Date: Tue, 19 Jan 2010 18:39:22 -0600
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] integer division/mod questions?
>>> 
>>> 
>>> 
>>> hendrik at topoi.pooq.com wrote:
>>>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
>>>>> -2147483648 div 2147483647 ?
>>>>> -2147483648 mod 2147483647 ?
>>>>> 
>>>>> quotient = -1, remainer = -1 seems reasonable.
>>>>> 2147483647 * -1 + -1 == -2147483648
>>>>> 
>>>> 
>>>> There are two kinds of binary integer arithmetic -- two's complement
>>>> and one's complement. In my experience, two's complement machines tend
>>>> to have the remainder being the same sign as the dividend; one's
>>>> complement machines semm to have a remainder the same sign as the
>>>> divisor.
>>>> 
>>>> One's complement machines are all but extinct these days.
>>> 
>>> Tony, you were concerned about showing your age, but 20 years is but an
>>> evening past. I remember programming ones-complement arithmetic
>>> in assembly language, definitely more decades ago than two.
>>> And that was not my first job.
>>> 
>>> There is a positive zero and a negative zero, and which one you get
>>> can depend on the operation and operand values that produced the
>>> result, so you have to check for both of them, often with two
>>> separate conditional branches.
>>> 
>>> Anyone remember nines- or tens-complement arithmetic on decimal
>>> machines? Electromechanical accounting machines?
>>> 
>>> 
>>>> 
>>>>> However, Modula-3 specifies div as rounding down, so
>>>>> 
>>>>> -2147483648 div 2147483647 == -2
>>>>> 
>>>>> and then
>>>>> 
>>>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
>>>>> 
>>>>> The value x DIV y is the floor of
>>>>> the quotient of x and y; that is, the maximum integer
>>>>> not exceeding the real number z such that z * y = x.
>>>>> For integers x and y, the value of x MOD y is
>>>>> defined to be x - y * (x DIV y).
>>>>> 
>>>>> 
>>>>> This means that for positive y, the value of x MOD y
>>>>> lies in the interval [0 .. y-1], regardless of
>>>>> the sign of x. For negative y, the value of
>>>>> x MOD y lies in the interval [y+1 .. 0], regardless
>>>>> of the sign of x.
>>>> 
>>>> And this is consistent with MOD producing a canonical representative of
>>>> an equivalence class modulo y. It's what's wanted for a lot of
>>>> algorithms. What it returns for negative y isn't as important, but
>>>> it is important to have positive MODuli for positive y no matter what
>>>> the sign of x is.
>>>> 
>>>> But it's not what most two's-complement processors produce naturally.
>>>> Having a MODulo operation that is mathematically well-behaved takes
>>>> extra effort on these machines.
>>>> 
>>>> And it's also important to have a remainder that corresponds to the
>>>> division operator. On two's complement machines you have to either
>>>> * use extra instructions to correct the result of the divide
>>>> instruction to correspond to the mathematically desirable MOD
>>>> operator, or
>>>> * Have a separate remainder operation that does correspond to
>>>> division.
>>>> 
>>>> On one's complement machines MOD will have the same effect as remainder.
>>>> On two's complement, different.
>>>> 
>>>> -- hendrik
>>>> 		 	   		  

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

From jay.krell at cornell.edu  Wed Jan 20 12:20:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:20:03 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
Message-ID: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>


Ok with changing LONGINT to be __int128, *but*

you really should not change it with a compiler flag.

For any given platform, "basics" like this should not change meaning.

It makes it such that you can't link code safely.

 

 

Basically, "platform" or "target" should map to one "ABI".

 

 

I really kind of like what I proposed earlier.

  Let the user define things.

  TYPE INT64 = BITS 64 FOR INTEGER;

  TYPE INT128 = BITS 128 FOR INTEGER;

 

TYPE INT256 = BITS 256 FOR INTEGER;

  (* either an error, or the compiler generates calls to multi-precision library *)

 

 

This is btw why the user thread stuff should be either 1) a runtime alterable decision

or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).

So that there aren't multiple ABIs and you can link together any code for

a given platform.

With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.

That forces recompilation of everything affected.

 

 

 - Jay

 


Subject: Re: [M3devel] __int128 coming to gcc
From: darko at darko.org
Date: Wed, 20 Jan 2010 14:23:32 +1100
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu


I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.




On 19/01/2010, at 1:03 AM, Tony Hosking wrote:



On 18 Jan 2010, at 08:05, Jay K wrote:


gcc 4.6 apparently will have __int128.
How long until we have LONGLONGINT or INT128?
Presumably we should have LONGLONGINT or INT128 to expose it?
:)



Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as


BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]



 Or, again, I should look at the arithemetic library...
 
 
 - Jay
 
 
Date: Mon, 18 Jan 2010 13:01:13 +0000
From: gcc-patches-digest-help@
To: gcc-patches@
Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091


gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091

... 
[patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
255919 by: Kai Tietz <ktietz70@>

...

--Forwarded Message Attachment--
Date: Mon, 18 Jan 2010 14:01:00 +0100
Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
From: ktietz70@
To: joseph@
CC: gcc-patches@


Hello,
 
this is the recent version of the __int128 type support as gcc
extension. Comments in parser for C and C++ are updated and complex
type and tests are added.
 
ChangeLog gcc/
....

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

From jay.krell at cornell.edu  Wed Jan 20 12:21:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:21:00 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>,
	<D59F2B55-C5AA-41CD-9B59-C0D6E070DB1A@cs.purdue.edu>
Message-ID: <COL101-W557F59387EF941814B75F4E6640@phx.gbl>


Only lately with C99.

Prior to that it was unspecified.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 05:09:33 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

C specifies truncated division.




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 19 Jan 2010, at 21:59, Jay K wrote:


That paper also suggests a more efficient algorithm we should probably adopt:


/* Floored division */
long divF( long D, long d )
{
long q = D/d;
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) q = q-1;
return q;
}


long modF( long D, long d )
{
long r = D%d;
if ((r> 0 && d < 0) || (r < 0 && d> 0)) r = r+d;
return r;
}


Though the condition should be perhaps the equivalent (r < 0) != (d < 0)
or (r < 0) ^ (d < 0)


We'd probably want to be sure the / followed by % got optimized into just one divide though.


or maybe what I have is fine.
As long as the inputs are the same sign, the current code does just one / or one %. It is only for mixed sign inputs that you need more care.
I am assuming C never "rounds", but either truncates or "floors".
e.g. 1/2 in the face of rounding is 1.


Integer division probably not a big concern anyway, esp. with any negative numbers. The main place I ever see division/mod used is hash tables, and the numbers are always positive (I rarely see negative numbers used anywhere in "systems" programming actually -- file sizes, array indices, array sizes..all positive; "math" needs floating point often...)


- Jay


----------------------------------------

From: jay.krell at cornell.edu

To: rodney_bates at lcwb.coop; m3devel at elegosoft.com

Date: Wed, 20 Jan 2010 02:45:43 +0000

Subject: Re: [M3devel] integer division/mod questions?






There is a positive zero and a negative zero, and which one you get





Rodney you reminded me of something I forgot to ask:





Is 0 div -1 = 0 or -1?





In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.

If 0> -0, then 0 div -1 should equal -1 instead of 0.





My current code I believe returns 0 for 0 div anything.

And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.





The previous code probably also but I'll have to double check.

The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.





Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.





Nice if anyone can reproduce the problem with K&R + long long as well.

I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.





The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.





In particular, LONG_MIN div or mod -1 can trap.





div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.





(anywhere I say "LONG_MIN", INT64_MIN has similar problem)







- Jay





----------------------------------------


Date: Tue, 19 Jan 2010 18:39:22 -0600


From: rodney_bates at lcwb.coop


To: m3devel at elegosoft.com


Subject: Re: [M3devel] integer division/mod questions?











hendrik at topoi.pooq.com wrote:



On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:




-2147483648 div 2147483647 ?




-2147483648 mod 2147483647 ?









quotient = -1, remainer = -1 seems reasonable.




2147483647 * -1 + -1 == -2147483648












There are two kinds of binary integer arithmetic -- two's complement



and one's complement. In my experience, two's complement machines tend



to have the remainder being the same sign as the dividend; one's



complement machines semm to have a remainder the same sign as the



divisor.







One's complement machines are all but extinct these days.





Tony, you were concerned about showing your age, but 20 years is but an


evening past. I remember programming ones-complement arithmetic


in assembly language, definitely more decades ago than two.


And that was not my first job.





There is a positive zero and a negative zero, and which one you get


can depend on the operation and operand values that produced the


result, so you have to check for both of them, often with two


separate conditional branches.





Anyone remember nines- or tens-complement arithmetic on decimal


machines? Electromechanical accounting machines?














However, Modula-3 specifies div as rounding down, so









-2147483648 div 2147483647 == -2









and then









http://www.modula3.com/cm3/doc/reference/arithmetic.html









The value x DIV y is the floor of




the quotient of x and y; that is, the maximum integer




not exceeding the real number z such that z * y = x.




For integers x and y, the value of x MOD y is




defined to be x - y * (x DIV y).














This means that for positive y, the value of x MOD y




lies in the interval [0 .. y-1], regardless of




the sign of x. For negative y, the value of




x MOD y lies in the interval [y+1 .. 0], regardless




of the sign of x.







And this is consistent with MOD producing a canonical representative of



an equivalence class modulo y. It's what's wanted for a lot of



algorithms. What it returns for negative y isn't as important, but



it is important to have positive MODuli for positive y no matter what



the sign of x is.







But it's not what most two's-complement processors produce naturally.



Having a MODulo operation that is mathematically well-behaved takes



extra effort on these machines.







And it's also important to have a remainder that corresponds to the



division operator. On two's complement machines you have to either



* use extra instructions to correct the result of the divide



instruction to correspond to the mathematically desirable MOD



operator, or



* Have a separate remainder operation that does correspond to



division.







On one's complement machines MOD will have the same effect as remainder.



On two's complement, different.







-- hendrik



    

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

From jay.krell at cornell.edu  Wed Jan 20 12:27:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:27:17 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>, ,
	<20100117203406.GE11416@topoi.pooq.com>, ,
	<4B5650BA.6030601@lcwb.coop>,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>
Message-ID: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>


No, not overflow examples.

 

 

LONG_MIN divided by any negative number was a negative number.

  But I believe it should be positive.

  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.

    The result is representable.

  LONG_MIN mod negative numbers also had the wrong sign.

 

 

You don't really have to view a diff.

I left the old functions m3_mod, m3_div, present, renamed

to m3_mod_old, m3_div_old.

 

 

So you can see both versions.

The new versions don't look particularly like the old ones.

The "proof" to me is the behavior per testing.

There is test code in there as well, under #if 0.

I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.

Mostly on Darwin/x86 though.

Both with gcc (4.0.1) and gcc-4.2.

 

 

Old:

 

static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}


 

long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}


 

"new" or "current":

 

long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}


 

long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}


 

In the case of div, I believe my code is clear and I understand it.

But perhaps could be more efficient.

 

 

In the case of mod, I don't know what is going on actually.

I just made it look something like old and tested it.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5cd68a5d/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan 20 12:31:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:31:18 +0000
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>,
	,,<20100117203406.GE11416@topoi.pooq.com>,
	, , <4B5650BA.6030601@lcwb.coop>, ,
	<COL101-W5066919E7799495954BF25E6640@phx.gbl>, ,
	<3EC6FA9F-C77C-4B90-A67A-9C12BBC59536@cs.purdue.edu>,
	<COL101-W27FC9FA217FA4483FAC192E6640@phx.gbl>
Message-ID: <COL101-W22FDCE853B21D87623183FE6640@phx.gbl>


Actually I think the new mod/div functions are still a little

risky for negative div or mod negative.

They'd more reliable/predictable/portable if if they used unsigned

numbers.

 

 

The reason I started looking at this stuff is because I was

reading about gcc assuming signed overflow won't occur

and then making optimizations with that assumption.

You can ask it to warn when it does so.
I thought this might break the new but unused m3_add and

such. The warning triggered for the existing div (but not mod) functions.

So I set about rewriting them to use unsigned math, which

is the recommendation here -- because its overflow is

well defined by the C standard -- and then comparing

mine with the previous/current code..and noticed wrong behavior

in the previous/current.

 

 - Jay



 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 11:27:17 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?



No, not overflow examples.
 
 
LONG_MIN divided by any negative number was a negative number.
  But I believe it should be positive.
  I don't believe e.g. LONG_MIN DIV -2 is something involving overflow.
    The result is representable.
  LONG_MIN mod negative numbers also had the wrong sign.
 
 
You don't really have to view a diff.
I left the old functions m3_mod, m3_div, present, renamed
to m3_mod_old, m3_div_old.
 
 
So you can see both versions.
The new versions don't look particularly like the old ones.
The "proof" to me is the behavior per testing.
There is test code in there as well, under #if 0.
I did various testing on Darwin/x86, Darwin/amd64, NT386, Solaris/sparc32, Linux/x86.
Mostly on Darwin/x86 though.
Both with gcc (4.0.1) and gcc-4.2.
 
 
Old:
 
static long __cdecl m3_div_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  
  if ((a == 0) && (b != 0))  {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? (a) / (b) : -1 - (a-1) / (-b);
  } else /* a < 0 */ { c = (b >= 0) ? -1 - (-1-a) / (b) : (-a) / (-b);
  }
  return c;
}

 
long __cdecl m3_mod_old
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  register long c;
  if ((a == 0) && (b != 0)) {  c = 0;
  } else if (a > 0)  {  c = (b >= 0) ? a % b : b + 1 + (a-1) % (-b);
  } else /* a < 0 */ {  c = (b >= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
  }
  return c;
}

 
"new" or "current":
 
long __cdecl m3_div
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a / b);
  else
  {
    /* round negative result down by rounding positive result up
       unsigned math is much better defined, see gcc -Wstrict-overflow=4 */
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    return -(ST)((ua + ub - 1) / ub);
  }
}

 
long __cdecl m3_mod
    ANSI((      long b, long a))
      KR((b, a) long b; long a;)
{
  typedef  long ST; /* signed type */
  typedef ulong UT; /* unsigned type */
  int aneg = (a < 0);
  int bneg = (b < 0);
  if (aneg == bneg || a == 0 || b == 0)
    return (a % b);
  else
  {
    UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
    UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
    a = (ST)(ub - 1 - (ua + ub - 1) % ub);
    return (bneg ? -a : a);
  }
}

 
In the case of div, I believe my code is clear and I understand it.
But perhaps could be more efficient.
 
 
In the case of mod, I don't know what is going on actually.
I just made it look something like old and tested it.
 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 05:07:45 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] integer division/mod questions?
> 
> These are all overflow examples correct? In which case the meaning is undefined?
> 
> But certainly, 0 DIV -1 should be 0.
> 
> I haven't had a chance to diff the previous code with your new code, but in the long time the previous code was in place there had never been a complaint that DIV was buggy. In the overflow cases surely we are allowed to go with whatever the hardware produces, so long as the code is efficient for non-overflow situations? I suppose one thing to ensure is that the compile-time evaluation (TInt) and the run-time evaluations are consistent, otherwise there will be confusion.
> 
> On 19 Jan 2010, at 21:45, Jay K wrote:
> 
> > 
> >> There is a positive zero and a negative zero, and which one you get 
> > 
> > 
> > Rodney you reminded me of something I forgot to ask: 
> > 
> > 
> > Is 0 div -1 = 0 or -1?
> > 
> > 
> > In particular, in floating point, 0 / -1 is presumably -0 and 0 / 1 is presumably +0. Modula-3 is specified as returning the largest integer not greater than the floating point result. So the question then is, is 0> -0? Or are they equal? Integer-wise, there is no -0.
> > If 0> -0, then 0 div -1 should equal -1 instead of 0.
> > 
> > 
> > My current code I believe returns 0 for 0 div anything.
> > And I believe "the mod formula" holds as correct, since my testing checks that. I'll have to double double check.
> > 
> > 
> > The previous code probably also but I'll have to double check.
> > The previous code isn't necessarily the definition of correct though, since it was pretty clearly wrong for some cases.
> > 
> > 
> > Which is imply the question: Everyone agrees with me that the previous code was wrong? In particular, for LONG_MIN div negative, it was giving negative results, but I believe the result should be positive. Mod had a similar problem.
> > 
> > 
> > Nice if anyone can reproduce the problem with K&R + long long as well.
> > I don't like making changes here without some kind of independent confirmation, though I'm also pretty sure of myself..a contradiction I realize.
> > 
> > 
> > The previous code and I believe the current code are inconsistent as to when it would "trap", depending on compiler and optimization level. I assume that is ok for now, though in future we might want to make it predictable and honor the FloatMode stuff, but until that time, "unpredictable" is ok.
> > 
> > 
> > In particular, LONG_MIN div or mod -1 can trap.
> > 
> > 
> > div clearly has little choice. Mod I have to think about -- mod should be zero, right? LONG_MIN "evenly" divides by -1, the answer can't be represented, but the remainder can (it is zero). So maybe we should special case that to ensure it doesn't trap.
> > 
> > 
> > (anywhere I say "LONG_MIN", INT64_MIN has similar problem)
> > 
> > 
> > 
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> Date: Tue, 19 Jan 2010 18:39:22 -0600
> >> From: rodney_bates at lcwb.coop
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] integer division/mod questions?
> >> 
> >> 
> >> 
> >> hendrik at topoi.pooq.com wrote:
> >>> On Sun, Jan 17, 2010 at 10:44:53AM +0000, Jay K wrote:
> >>>> -2147483648 div 2147483647 ?
> >>>> -2147483648 mod 2147483647 ?
> >>>> 
> >>>> quotient = -1, remainer = -1 seems reasonable.
> >>>> 2147483647 * -1 + -1 == -2147483648
> >>>> 
> >>> 
> >>> There are two kinds of binary integer arithmetic -- two's complement
> >>> and one's complement. In my experience, two's complement machines tend
> >>> to have the remainder being the same sign as the dividend; one's
> >>> complement machines semm to have a remainder the same sign as the
> >>> divisor.
> >>> 
> >>> One's complement machines are all but extinct these days.
> >> 
> >> Tony, you were concerned about showing your age, but 20 years is but an
> >> evening past. I remember programming ones-complement arithmetic
> >> in assembly language, definitely more decades ago than two.
> >> And that was not my first job.
> >> 
> >> There is a positive zero and a negative zero, and which one you get
> >> can depend on the operation and operand values that produced the
> >> result, so you have to check for both of them, often with two
> >> separate conditional branches.
> >> 
> >> Anyone remember nines- or tens-complement arithmetic on decimal
> >> machines? Electromechanical accounting machines?
> >> 
> >> 
> >>> 
> >>>> However, Modula-3 specifies div as rounding down, so
> >>>> 
> >>>> -2147483648 div 2147483647 == -2
> >>>> 
> >>>> and then
> >>>> 
> >>>> http://www.modula3.com/cm3/doc/reference/arithmetic.html
> >>>> 
> >>>> The value x DIV y is the floor of
> >>>> the quotient of x and y; that is, the maximum integer
> >>>> not exceeding the real number z such that z * y = x.
> >>>> For integers x and y, the value of x MOD y is
> >>>> defined to be x - y * (x DIV y).
> >>>> 
> >>>> 
> >>>> This means that for positive y, the value of x MOD y
> >>>> lies in the interval [0 .. y-1], regardless of
> >>>> the sign of x. For negative y, the value of
> >>>> x MOD y lies in the interval [y+1 .. 0], regardless
> >>>> of the sign of x.
> >>> 
> >>> And this is consistent with MOD producing a canonical representative of
> >>> an equivalence class modulo y. It's what's wanted for a lot of
> >>> algorithms. What it returns for negative y isn't as important, but
> >>> it is important to have positive MODuli for positive y no matter what
> >>> the sign of x is.
> >>> 
> >>> But it's not what most two's-complement processors produce naturally.
> >>> Having a MODulo operation that is mathematically well-behaved takes
> >>> extra effort on these machines.
> >>> 
> >>> And it's also important to have a remainder that corresponds to the
> >>> division operator. On two's complement machines you have to either
> >>> * use extra instructions to correct the result of the divide
> >>> instruction to correspond to the mathematically desirable MOD
> >>> operator, or
> >>> * Have a separate remainder operation that does correspond to
> >>> division.
> >>> 
> >>> On one's complement machines MOD will have the same effect as remainder.
> >>> On two's complement, different.
> >>> 
> >>> -- hendrik
> >>> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/5a443bbb/attachment-0002.html>

From jay.krell at cornell.edu  Wed Jan 20 12:40:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:40:03 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
Message-ID: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>


So..I have m3back using Target.Int a bunch.

And converting back and forth some between Target.Int and

INTEGER and doing match with Target.Int.

And various operations can fail.

 

 

And my current diff results in:

 

 

  new source -> compiling Lex.m3  
  "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed  
  "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed  
  2 errors encountered  
  new source -> compiling Scan.i3  

 

 

  which is nice to see, it means my code is actually running.  

 

 

  So I look at the code in question:  

 

 

  PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN): Word.T  
  VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN 
...

    IF signed AND
       ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
        (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
      RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
....

 

 

-FIRST(INTEGER).

 

 

What is that supposed to do?

 

 

I mean, I kind of know, I'm slightly playing stupid, partly not.

Does the compiler know what is an INTEGER vs. what is a "Word"?

Or it is just obligated to assume everything is a Word?

 To do the negation at compile time and ignore the overflow?

 

 

Does the language need work here?

I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

 

 

 - Jay

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

From jay.krell at cornell.edu  Wed Jan 20 12:55:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 11:55:14 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
Message-ID: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>


I propose we add WarningHandler, set_warning_handler.

The signatures are either identical to the existing ErrorHandler, set_error_handler.

Or possibly there is a warning "level".

For now I'm implementing it such that the warning level

is hardcoded as 2.

 

 

This is so I can report but ignore the overflows when I use TInt in m3back.

 

 

 - Jay





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

From jay.krell at cornell.edu  Wed Jan 20 16:05:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 20 Jan 2010 15:05:23 +0000
Subject: [M3devel] m3back using Target.Int in place of INTEGER a lot now
In-Reply-To: <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
Message-ID: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>


This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.

I did look through pretty much every single line in search of the one bug I saw working on it.

It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.

Which broke INC, it was adding 0 instead 1.

You could see the bug in RTIO.PutString where it just kept outputing the first character.

So I use TInt.Multiply instead.

 

 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3



diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100120/2a2f079c/attachment-0002.html>

From hendrik at topoi.pooq.com  Wed Jan 20 17:23:15 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:23:15 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
References: <COL101-W5066919E7799495954BF25E6640@phx.gbl>
	<COL101-W499FA4792060FF914A2FBBE6640@phx.gbl>
Message-ID: <20100120162315.GA18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 02:59:43AM +0000, Jay K wrote:
>  
> Integer division probably not a big concern anyway, esp. with any 
> negative numbers. The main place I ever see division/mod used is hash 
> tables, and the numbers are always positive

And that's where it's important that the remainder has the same sign as 
the divisor.

> (I rarely see negative numbers used anywhere in "systems" programming 
> actually -- file sizes, array indices, array sizes..all positive; 
> "math" needs floating point often...)

You can get negative numbers in the subscripting calculations for an 
array whose subscripts are in the range like 10000..10345.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:26:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:26:20 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com>
	<4B5650BA.6030601@lcwb.coop>
Message-ID: <20100120162620.GB18214@topoi.pooq.com>

On Tue, Jan 19, 2010 at 06:39:22PM -0600, Rodney M. Bates wrote:
> 
> Tony, you were concerned about showing your age, but 20 years is but an
> evening past.  I remember programming ones-complement arithmetic
> in assembly language, definitely more decades ago than two.
> And that was not my first job.
> 
> There is a positive zero and a negative zero, and which one you get
> can depend on the operation and operand values that produced the
> result, so you have to check for both of them, often with two
> separate conditional branches.
> 
> Anyone remember nines- or tens-complement arithmetic on decimal
> machines?

Conputers, no.  The decimal computer I used has signed-magnitude 
representation.  And it did addition by looking pairs of digits up in an 
array in RAM.  YOu could get interesting effects by replacing the 
addition tables.

>  Electromechanical accounting machines?

Yes.  I remember using these when studying statistics.

-- hendrik


From hendrik at topoi.pooq.com  Wed Jan 20 17:30:39 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 20 Jan 2010 11:30:39 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <20100120163039.GC18214@topoi.pooq.com>

On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> 
> you really should not change it with a compiler flag.
> 
> For any given platform, "basics" like this should not change meaning.
> 
> It makes it such that you can't link code safely.
> 
>  
> 
>  
> 
> Basically, "platform" or "target" should map to one "ABI".
> 
>  
> 
>  
> 
> I really kind of like what I proposed earlier.
> 
>   Let the user define things.
>
>   TYPE INT64 = BITS 64 FOR INTEGER;
> 
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> 
> TYPE INT256 = BITS 256 FOR INTEGER;
> 
> 
>   (* either an error, or the compiler generates calls to multi-precision library *)

Well, with INTEGER being defined as the type for efficient integer 
arithmetic, you's have to say

  TYPE INT64 = BITS 64 FOR LONGINT;

  TYPE INT128 = BITS 128 FOR LONGINT;

 

TYPE INT256 = BITS 256 FOR LONGINT;

and on many current machines, file offset should then be defined as 
BITS64 instead of LONGINT.

-- hendrik

> This is btw why the user thread stuff should be either 1) a runtime alterable decision


From rcolebur at SCIRES.COM  Wed Jan 20 21:02:11 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 20 Jan 2010 15:02:11 -0500
Subject: [M3devel] integer division/mod questions?
In-Reply-To: <4B5650BA.6030601@lcwb.coop>
References: <COL101-W50ED71DF4E3C6EADCAF59CE6670@phx.gbl>
	<20100117203406.GE11416@topoi.pooq.com> <4B5650BA.6030601@lcwb.coop>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8710CDD6ED53@ATLEX02-SRV.SCIRES.LOCAL>

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Tuesday, January 19, 2010 7:39 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] integer division/mod questions?

Anyone remember nines- or tens-complement arithmetic on decimal
machines?  Electromechanical accounting machines?

[Randy Coleburn] 
[Randy Coleburn] My first "programming" experience dates back to the old IBM tabulating machine where you had to plug up the wires to form the tabulating logic.  Also, the old keypunch machines, card sorters, etc.  My first real computer had core memory and we used the old teletype machines with canary yellow paper and paper tape.  But, given where we are today, I don't think any of us would remember these as "the good ol' days" of computing, though I do have some fond memories.

Regards,
Randy


From hosking at cs.purdue.edu  Thu Jan 21 00:50:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:50:08 -0500
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>
Message-ID: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>

I don't understand why you need this.
Why would you have overflows in m3back?
Are you constant folding or something?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:55, Jay K wrote:

> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>  
>  
> This is so I can report but ignore the overflows when I use TInt in m3back.
>  
>  
>  - Jay
> 
> 
> 
> 
> 

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

From hosking at cs.purdue.edu  Thu Jan 21 00:59:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 18:59:30 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
Message-ID: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 10:05, Jay K wrote:

> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 

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

From hosking at cs.purdue.edu  Thu Jan 21 01:02:33 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:02:33 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
Message-ID: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>

But INTEGER is the natural integer size.  Not the maximum (perhaps less efficient) integer size supported by the compiler.
What's wrong with:

BITS 64 FOR LONGINT

?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 06:20, Jay K wrote:

> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 

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

From hosking at cs.purdue.edu  Thu Jan 21 01:03:01 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:03:01 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100120163039.GC18214@topoi.pooq.com>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<20100120163039.GC18214@topoi.pooq.com>
Message-ID: <2EF1DA6A-281F-49EA-8612-AD30CE6D7EBB@cs.purdue.edu>

Yes, exactly.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 11:30, hendrik at topoi.pooq.com wrote:

> On Wed, Jan 20, 2010 at 11:20:03AM +0000, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> 
>> you really should not change it with a compiler flag.
>> 
>> For any given platform, "basics" like this should not change meaning.
>> 
>> It makes it such that you can't link code safely.
>> 
>> 
>> 
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> 
>> 
>> 
>> I really kind of like what I proposed earlier.
>> 
>>  Let the user define things.
>> 
>>  TYPE INT64 = BITS 64 FOR INTEGER;
>> 
>>  TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> 
>> 
>>  (* either an error, or the compiler generates calls to multi-precision library *)
> 
> Well, with INTEGER being defined as the type for efficient integer 
> arithmetic, you's have to say
> 
>  TYPE INT64 = BITS 64 FOR LONGINT;
> 
>  TYPE INT128 = BITS 128 FOR LONGINT;
> 
> 
> 
> TYPE INT256 = BITS 256 FOR LONGINT;
> 
> and on many current machines, file offset should then be defined as 
> BITS64 instead of LONGINT.
> 
> -- hendrik
> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision

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

From hosking at cs.purdue.edu  Thu Jan 21 01:35:17 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:35:17 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>
Message-ID: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>

On 20 Jan 2010, at 19:29, Darko wrote:

> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.

M3 defines all arithmetic as operating on the base type.  It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.

> You're using the syntax for packed types in your example, but I think they'd have to be subranges.

Sorry, yes. [Jet-lag]

> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.

Agreed!

> 
> 
> 
> On 20/01/2010, at 10:20 PM, Jay K wrote:
> 
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>  
>  
> Basically, "platform" or "target" should map to one "ABI".
>  
>  
> I really kind of like what I proposed earlier.
>   Let the user define things.
>   TYPE INT64 = BITS 64 FOR INTEGER;
>   TYPE INT128 = BITS 128 FOR INTEGER;
>  
> TYPE INT256 = BITS 256 FOR INTEGER;
>   (* either an error, or the compiler generates calls to multi-precision library *)
>  
>  
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>  
>  
>  - Jay
> 
>  
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
> 
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
> 
> 
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
> 
> On 18 Jan 2010, at 08:05, Jay K wrote:
> 
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
> 
> Why would we not simply expand LONGINT?  It doesn't matter even if it is slow.  Then 64-bit can be expressed as
> 
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
> 
>  Or, again, I should look at the arithemetic library...
>  
>  
>  - Jay
>  
>  
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> 
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
> 
> ... 
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for  review
> 255919 by: Kai Tietz <ktietz70@>
> 
> ...
> 
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
> 
> 
> Hello,
>  
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>  
> ChangeLog gcc/
> ....
> 
> 
> 
> 

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

From Highjinks at gmx.com  Thu Jan 21 01:50:20 2010
From: Highjinks at gmx.com (Chris)
Date: Thu, 21 Jan 2010 01:50:20 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
Message-ID: <20100120205327.e8547d50.Highjinks@gmx.com>

It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.

Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
Trestle is easy to write for, but it really is butt ugly.

Is anyone else looking at this area of the system?


-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Thu Jan 21 01:58:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 19:58:44 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <D04D87A0-B24A-4EE3-95AE-90D4F3A78938@cs.purdue.edu>

That would be a great idea.  Given that we are linking with X11R6 anyway...  :-)

On 20 Jan 2010, at 19:50, Chris wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. Bring the X interface up to date(X11R6) and support things like DRM, XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
> 
> Is anyone else looking at this area of the system?
> 
> 
> -- 
> Chris <Highjinks at gmx.com>

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

From hosking at cs.purdue.edu  Thu Jan 21 02:00:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 20 Jan 2010 20:00:39 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place of
	INTEGER a lot now
In-Reply-To: <5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>
Message-ID: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>

Jay, I don't know what you are talking about there being a bug in TWord.Multiply.

This little program prints out 2, as would be expected:

MODULE Main;
IMPORT RTIO, TInt, TWord, Target;

VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.


On 20 Jan 2010, at 18:59, Tony Hosking wrote:

> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 20 Jan 2010, at 10:05, Jay K wrote:
> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>>  
>>  - Jay
>>  
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>>  
>> > Date: Wed, 20 Jan 2010 16:01:32 +0000
>> > To: m3commit at elegosoft.com
>> > From: jkrell at elego.de
>> > Subject: [M3commit] CVS Update: cm3
>> > 
>> > CVSROOT: /usr/cvs
>> > Changes by: jkrell at birch. 10/01/20 16:01:32
>> > 
>> > Modified files:
>> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
>> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
>> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
>> > 
>> > Log message:
>> > convert much of m3back to use Target.Int instead of INTEGER
>> > This should at least allow it to propagate constant LONGINTs
>> > as well as perhaps otherwise help with implementing LONGINT,
>> > since the virtual stack is now of Target.Int instead of INTEGER
>> > 
>> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>> > 
>> > Also note that there's still a lot of "INTEGER" used.
>> > 
> 

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

From jay.krell at cornell.edu  Thu Jan 21 03:49:15 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:49:15 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
Message-ID: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>


That would be fine too.
Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
 
  - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:02:33 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; darko at darko.org
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
> What's wrong with:
>
> BITS 64 FOR LONGINT
>
> ?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:20, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:50:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:50:05 +0000
Subject: [M3devel] proposed addition m3cg_ops: set_warning_handler
In-Reply-To: <87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
References: <COL101-W46DE0CA09AD635B38A29DE6640@phx.gbl>,
	<87EEB023-4FB2-400B-ACD5-C4E872469571@cs.purdue.edu>
Message-ID: <COL101-W1693D675BA116E2C556EF9E6630@phx.gbl>


> Are you constant folding or something?

Exactly.
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 18:50:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] proposed addition m3cg_ops: set_warning_handler
>
>
>
> I don't understand why you need this.
> Why would you have overflows in m3back?
> Are you constant folding or something?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 06:55, Jay K wrote:
>
> I propose we add WarningHandler, set_warning_handler.
> The signatures are either identical to the existing ErrorHandler, set_error_handler.
> Or possibly there is a warning "level".
> For now I'm implementing it such that the warning level
> is hardcoded as 2.
>
>
> This is so I can report but ignore the overflows when I use TInt in m3back.
>
>
> - Jay
>
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:52:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:52:13 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>


I'll look into it again.
There's definitely a problem somewhere.
 Maybe in my change. Maybe.
 
 
Using TInt.Multiply vs. TWord.Multiply made the difference
between INC() incrementing by zero or the correct amount.
I had some number, I multiplied it by a variable
that also happened to be 1, and I got zero.
This was the only problem I ran into in changing
from INTEGER to Target.Int.
 
 
 - Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>
>
>
>
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>
> This little program prints out 2, as would be expected:
>
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
>
> VAR i := TInt.Two;
> j: Target.Int;
> buf: ARRAY[0..10] OF CHAR;
> BEGIN
> TWord.Multiply (i, TInt.One, j);
> FOR k := 0 TO TInt.ToChars (i, buf) DO
> RTIO.PutChar(buf[k]);
> END;
> RTIO.PutChar('\n');
> RTIO.Flush();
> END Main.
>
>
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 20 Jan 2010, at 10:05, Jay K wrote:
>
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>
> - Jay
>
> ________________________________
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
>
> diff attached
>
>
>
>
>
>
>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>> To: m3commit at elegosoft.com
>> From: jkrell at elego.de
>> Subject: [M3commit] CVS Update: cm3
>>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>
>> Modified files:
>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>
>> Log message:
>> convert much of m3back to use Target.Int instead of INTEGER
>> This should at least allow it to propagate constant LONGINTs
>> as well as perhaps otherwise help with implementing LONGINT,
>> since the virtual stack is now of Target.Int instead of INTEGER
>>
>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>
>> Also note that there's still a lot of "INTEGER" used.
>>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 03:54:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 02:54:10 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
Message-ID: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>


> I think the idea that "basics" don't change
> meaning doesn't wash because you can't
> make assumptions about what hardware you're
> running on and therefore might be condemning
> the language to inefficiency on certain hardware.
>
> Agreed!

 
The "basics" *for a given target*.
LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
Some other future platform can use 56 bits or 128 bits or whatever.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 19:35:17 -0500
> To: darko at darko.org
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] __int128 coming to gcc
>
>
>
> On 20 Jan 2010, at 19:29, Darko wrote:
>
> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>
> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>
> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>
> Sorry, yes. [Jet-lag]
>
> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>
> Agreed!
>
>
>
>
> On 20/01/2010, at 10:20 PM, Jay K wrote:
>
> Ok with changing LONGINT to be __int128, *but*
> you really should not change it with a compiler flag.
> For any given platform, "basics" like this should not change meaning.
> It makes it such that you can't link code safely.
>
>
> Basically, "platform" or "target" should map to one "ABI".
>
>
> I really kind of like what I proposed earlier.
> Let the user define things.
> TYPE INT64 = BITS 64 FOR INTEGER;
> TYPE INT128 = BITS 128 FOR INTEGER;
>
> TYPE INT256 = BITS 256 FOR INTEGER;
> (* either an error, or the compiler generates calls to multi-precision library *)
>
>
> This is btw why the user thread stuff should be either 1) a runtime alterable decision
> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
> So that there aren't multiple ABIs and you can link together any code for
> a given platform.
> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
> That forces recompilation of everything affected.
>
>
> - Jay
>
>
> ________________________________
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Wed, 20 Jan 2010 14:23:32 +1100
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: hosking at cs.purdue.edu
>
> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>
>
> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>
> On 18 Jan 2010, at 08:05, Jay K wrote:
>
> gcc 4.6 apparently will have __int128.
> How long until we have LONGLONGINT or INT128?
> Presumably we should have LONGLONGINT or INT128 to expose it?
> :)
>
> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>
> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>
> Or, again, I should look at the arithemetic library...
>
>
> - Jay
>
>
> Date: Mon, 18 Jan 2010 13:01:13 +0000
> From: gcc-patches-digest-help@
> To: gcc-patches@
> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
>
> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>
> ...
> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> 255919 by: Kai Tietz
>
> ...
>
> --Forwarded Message Attachment--
> Date: Mon, 18 Jan 2010 14:01:00 +0100
> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
> From: ktietz70@
> To: joseph@
> CC: gcc-patches@
>
>
>
> Hello,
>
> this is the recent version of the __int128 type support as gcc
> extension. Comments in parser for C and C++ are updated and complex
> type and tests are added.
>
> ChangeLog gcc/
> ....
>
>
>
>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 04:57:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 03:57:45 +0000
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>,
	<5C25DD4F-D84F-435E-BBEE-73DF1265E396@darko.org>
Message-ID: <COL101-W404F04F00E1BF980DD7075E6630@phx.gbl>


But you need certain things to not change *per platform* if you expect to be able to link code together and not crash.
Different platforms of course can use different sizes and such.
 
 
It should not be possible to compile one module with one size INTEGER and nother with another size, if they can be linked together.
 
 
Various systems do allow that sort of thing and it is imho a bad idea.
It leads to "ABI bifurcation".
Like, let's say you want to provide a library for use by "anyone".
You end up having to compile it multiple times with various options, so that no matter what your user uses, there is a variant that matches.
Sometimes this stuff gets checked at link time, sometimes not.
 
 
Again this is why the way user threads is an "option" isn't great.
You have to recompile everything if you switch the option.
(I believe there are incrementality bugs here as well; basically many sorts of m3makefile edits are not handled correctly by cm3; for example moving a source file from one package to another..)
 
 
Having [0L .. Long.Shift(1L, 129)] work and use a 128bit LONGINT is a fine idea, agreed. "LONGINT" can indicate "possibly less efficient.
 
 
However, this is again a dangerous change *on preexisting platforms*, because it leads to LAST(LONGINT) changing.
 
 
 - Jay


----------------------------------------
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Thu, 21 Jan 2010 14:34:26 +1100
> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I think you want to get away from concrete representations on particular platforms. All you need to know is that INTEGER is a good, efficient size for the platform, and LONGINT is possibly bigger size but still reasonably efficient. That way the code will compile on any platform and you don't care what size INTEGER or LONGINT is. If this were a Star Wars movie Obiwan would be saying "Use Abstraction, Jay".
>
>
> On 21/01/2010, at 1:54 PM, Jay K wrote:
>
>
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>>
>> Agreed!
>
>
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
>
>
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>>
>>
>>
>> On 20 Jan 2010, at 19:29, Darko wrote:
>>
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>>
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>>
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>>
>> Sorry, yes. [Jet-lag]
>>
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>>
>> Agreed!
>>
>>
>>
>>
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>>
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>>
>>
>> Basically, "platform" or "target" should map to one "ABI".
>>
>>
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>>
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>>
>>
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>>
>>
>> - Jay
>>
>>
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>>
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>>
>>
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>>
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>>
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>>
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>>
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>>
>> Or, again, I should look at the arithemetic library...
>>
>>
>> - Jay
>>
>>
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>>
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>>
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>>
>> ...
>>
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>>
>>
>>
>> Hello,
>>
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>>
>> ChangeLog gcc/
>> ....
>>
>>
>>
>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Thu Jan 21 08:02:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:02:41 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
Message-ID: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>


Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.

 

 

MODULE Main;
IMPORT RTIO, Target, TInt, TWord;

VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.


 

prints 0.

 

The code in m3back:

 

 

PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...

        (* Beware TWord.Multiply: x * 1 = 0 *)

        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;


 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


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

From jay.krell at cornell.edu  Thu Jan 21 08:14:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 07:14:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <COL101-W2749C76BB19D4AA0997E77E6630@phx.gbl>


TInt.Multiply is reasonable anyway, since the code wasn't using Word.Multiply but just INTEGER *.

 

 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 07:02:41 +0000
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now



Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply? 
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 


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

From hosking at cs.purdue.edu  Thu Jan 21 09:36:24 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:36:24 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
Message-ID: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>

Subranges have a memory size that depends on the size of the subrange.  All arithmetic is performed using the precision of the base type however.

These things are all documented in the language spec.

On 20 Jan 2010, at 21:49, Jay K wrote:

> 
> That would be fine too.
> Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
> 
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:02:33 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; darko at darko.org
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
>> What's wrong with:
>> 
>> BITS 64 FOR LONGINT
>> 
>> ?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 06:20, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 		 	   		  



From hosking at cs.purdue.edu  Thu Jan 21 09:37:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:37:00 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
References: <1263819673.24181.ezmlm@gcc.gnu.org>,
	<COL101-W113B9C9BC919AABA22EFCBE6660@phx.gbl>,
	<298CA829-42E7-4C84-8E24-9BD25A62D28F@cs.purdue.edu>, ,
	<3C1B92E3-47F3-4494-83E9-E64F5311FB6F@darko.org>,
	<COL101-W41F002A043B1F0B32A27D4E6640@phx.gbl>,
	<1696C6EA-E081-48F1-BC42-B0FB866A9D79@darko.org>,
	<074EA4B2-E1CD-4FC2-A4B6-C02848DD3084@cs.purdue.edu>
	<COL101-W49FB2117893101185DC3C0E6630@phx.gbl>
Message-ID: <B4981016-C75D-468E-9506-87C48506C00F@cs.purdue.edu>

Agreed, yes, the sizes are in the target definition.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:54, Jay K wrote:

> 
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>> 
>> Agreed!
> 
> 
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> On 20 Jan 2010, at 19:29, Darko wrote:
>> 
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>> 
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>> 
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>> 
>> Sorry, yes. [Jet-lag]
>> 
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>> 
>> Agreed!
>> 
>> 
>> 
>> 
>> On 20/01/2010, at 10:20 PM, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu Jan 21 09:38:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:38:45 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W236A596B7446D4793B7590E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W236A596B7446D4793B7590E6630@phx.gbl>
Message-ID: <1DFF961A-09C7-4BAF-8593-D8128577786D@cs.purdue.edu>

INC is defined on INTEGER values, not Word.T.

I think your problem is somewhere else.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 20 Jan 2010, at 21:52, Jay K wrote:

> 
> I'll look into it again.
> There's definitely a problem somewhere.
> Maybe in my change. Maybe.
> 
> 
> Using TInt.Multiply vs. TWord.Multiply made the difference
> between INC() incrementing by zero or the correct amount.
> I had some number, I multiplied it by a variable
> that also happened to be 1, and I got zero.
> This was the only problem I ran into in changing
> from INTEGER to Target.Int.
> 
> 
> - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 20:00:39 -0500
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
>> 
>> 
>> 
>> 
>> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
>> 
>> This little program prints out 2, as would be expected:
>> 
>> MODULE Main;
>> IMPORT RTIO, TInt, TWord, Target;
>> 
>> VAR i := TInt.Two;
>> j: Target.Int;
>> buf: ARRAY[0..10] OF CHAR;
>> BEGIN
>> TWord.Multiply (i, TInt.One, j);
>> FOR k := 0 TO TInt.ToChars (i, buf) DO
>> RTIO.PutChar(buf[k]);
>> END;
>> RTIO.PutChar('\n');
>> RTIO.Flush();
>> END Main.
>> 
>> 
>> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
>> 
>> Where's the bug in TWord.Multiply?
>> If there were a bug we would have seen it by now surely?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 10:05, Jay K wrote:
>> 
>> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
>> I did look through pretty much every single line in search of the one bug I saw working on it.
>> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
>> Which broke INC, it was adding 0 instead 1.
>> You could see the bug in RTIO.PutString where it just kept outputing the first character.
>> So I use TInt.Multiply instead.
>> 
>> - Jay
>> 
>> ________________________________
>> From: jay.krell at cornell.edu
>> To: jkrell at elego.de; m3commit at elegosoft.com
>> Date: Wed, 20 Jan 2010 15:02:27 +0000
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> diff attached
>> 
>> 
>> 
>> 
>> 
>> 
>>> Date: Wed, 20 Jan 2010 16:01:32 +0000
>>> To: m3commit at elegosoft.com
>>> From: jkrell at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: jkrell at birch. 10/01/20 16:01:32
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3
>>> 
>>> Log message:
>>> convert much of m3back to use Target.Int instead of INTEGER
>>> This should at least allow it to propagate constant LONGINTs
>>> as well as perhaps otherwise help with implementing LONGINT,
>>> since the virtual stack is now of Target.Int instead of INTEGER
>>> 
>>> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
>>> 
>>> Also note that there's still a lot of "INTEGER" used.
>>> 
>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu Jan 21 09:40:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 03:40:36 -0500
Subject: [M3devel] [M3commit] m3back using Target.Int in place
	of	INTEGER a lot now
In-Reply-To: <COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
References: <20100120150133.04F542474001@birch.elegosoft.com>, ,
	<COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>
Message-ID: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>

You should not assume that aliasing works for any of these operations.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 02:02, Jay K wrote:

> Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
>  
>  
> MODULE Main;
> IMPORT RTIO, Target, TInt, TWord;
> VAR a,b:Target.Int;
> BEGIN
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
> EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
> TWord.Multiply(a, b, a);
> RTIO.PutText(TInt.ToText(a));
> RTIO.Flush();
> END Main.
> 
>  
> prints 0.
>  
> The code in m3back:
>  
>  
> PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
> ...
>         (* Beware TWord.Multiply: x * 1 = 0 *)
>         IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
>           t.Err("doindex_address: multiply overflowed");
>         END;
> 
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Wed, 20 Jan 2010 20:00:39 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now
> 
> Jay, I don't know what you are talking about there being a bug in TWord.Multiply.
> 
> This little program prints out 2, as would be expected:
> 
> MODULE Main;
> IMPORT RTIO, TInt, TWord, Target;
> 
> VAR i := TInt.Two;
>     j: Target.Int;
>     buf: ARRAY[0..10] OF CHAR;
> BEGIN
>   TWord.Multiply (i, TInt.One, j);
>   FOR k := 0 TO TInt.ToChars (i, buf) DO
>     RTIO.PutChar(buf[k]);
>   END;
>   RTIO.PutChar('\n');
>   RTIO.Flush();
> END Main.
> 
> 
> On 20 Jan 2010, at 18:59, Tony Hosking wrote:
> 
> Where's the bug in TWord.Multiply?
> If there were a bug we would have seen it by now surely?
> 
> 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 20 Jan 2010, at 10:05, Jay K wrote:
> 
> This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
> I did look through pretty much every single line in search of the one bug I saw working on it.
> It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
> Which broke INC, it was adding 0 instead 1.
> You could see the bug in RTIO.PutString where it just kept outputing the first character.
> So I use TInt.Multiply instead.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Wed, 20 Jan 2010 15:02:27 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> diff attached
> 
> 
> 
> 
> 
>  
> > Date: Wed, 20 Jan 2010 16:01:32 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/20 16:01:32
> > 
> > Modified files:
> > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> > M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> > cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> > 
> > Log message:
> > convert much of m3back to use Target.Int instead of INTEGER
> > This should at least allow it to propagate constant LONGINTs
> > as well as perhaps otherwise help with implementing LONGINT,
> > since the virtual stack is now of Target.Int instead of INTEGER
> > 
> > Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> > 
> > Also note that there's still a lot of "INTEGER" used.
> > 
> 
> 
> 

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

From jay.krell at cornell.edu  Thu Jan 21 09:42:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 08:42:40 +0000
Subject: [M3devel] [M3commit] m3back using Target.Int in
	place	of	INTEGER a lot now
In-Reply-To: <8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
References: <20100120150133.04F542474001@birch.elegosoft.com>,
	, , <COL101-W51C18DB4CA5DDECC7168CEE6640@phx.gbl>, ,
	<COL101-W2352D8FA2289DC727A1E35E6640@phx.gbl>, ,
	<5C7ABC30-9520-4FC0-87A5-B57FDC3914AD@cs.purdue.edu>, ,
	<DF554B03-3449-4A18-84FD-76FA7A4186A6@cs.purdue.edu>,
	<COL101-W49E3B655A8FCC0848A06F1E6630@phx.gbl>,
	<8AB90935-0C2B-4BF7-80A7-D0EBA22636AC@cs.purdue.edu>
Message-ID: <COL101-W366A4B875AA2D047EF4DE9E6630@phx.gbl>


I changed it to no longer:

 

        IF NOT TInt.Multiply(stop0.imm, tsize, tint) THEN
          t.Err("doindex_address: multiply overflowed");
        END;
        stop0.imm := tint;


 - Jay
 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 03:40:36 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] m3back using Target.Int in place of INTEGER a lot now


You should not assume that aliasing works for any of these operations.



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 21 Jan 2010, at 02:02, Jay K wrote:

Hm. Ok. TInt.Multiply allows aliasing but TWord.Multiply does not.
 
 
MODULE Main;
IMPORT RTIO, Target, TInt, TWord;
VAR a,b:Target.Int;
BEGIN
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), a);
EVAL TInt.FromInt(1, BYTESIZE(INTEGER), b);
TWord.Multiply(a, b, a);
RTIO.PutText(TInt.ToText(a));
RTIO.Flush();
END Main.

 
prints 0.
 
The code in m3back:
 
 
PROCEDURE doindex_address (t: T; shift, size: INTEGER; neg: BOOLEAN) =
...
        (* Beware TWord.Multiply: x * 1 = 0 *)
        IF NOT TInt.Multiply(stop0.imm, tsize, stop0.imm) THEN
          t.Err("doindex_address: multiply overflowed");
        END;

 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 20 Jan 2010 20:00:39 -0500
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] m3back using Target.Int in place of INTEGER a lot now


Jay, I don't know what you are talking about there being a bug in TWord.Multiply.


This little program prints out 2, as would be expected:



MODULE Main;
IMPORT RTIO, TInt, TWord, Target;


VAR i := TInt.Two;
    j: Target.Int;
    buf: ARRAY[0..10] OF CHAR;
BEGIN
  TWord.Multiply (i, TInt.One, j);
  FOR k := 0 TO TInt.ToChars (i, buf) DO
    RTIO.PutChar(buf[k]);
  END;
  RTIO.PutChar('\n');
  RTIO.Flush();
END Main.




On 20 Jan 2010, at 18:59, Tony Hosking wrote:

Where's the bug in TWord.Multiply?
If there were a bug we would have seen it by now surely?




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 20 Jan 2010, at 10:05, Jay K wrote:

This is fairly large and tedious. If anyone has the patience to look at every single line, please do. Thanks.
I did look through pretty much every single line in search of the one bug I saw working on it.
It turns out the bug was in TWord though. TWord.Multiply(x, 1) = 0.
Which broke INC, it was adding 0 instead 1.
You could see the bug in RTIO.PutString where it just kept outputing the first character.
So I use TInt.Multiply instead.
 
 - Jay
 


From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Wed, 20 Jan 2010 15:02:27 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached





 
> Date: Wed, 20 Jan 2010 16:01:32 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/20 16:01:32
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 
> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 
> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 
> 
> Log message:
> convert much of m3back to use Target.Int instead of INTEGER
> This should at least allow it to propagate constant LONGINTs
> as well as perhaps otherwise help with implementing LONGINT,
> since the virtual stack is now of Target.Int instead of INTEGER
> 
> Beware that TWord.Multiply(x, 1) = 0, so I use TInt.Multiply instead
> 
> Also note that there's still a lot of "INTEGER" used.
> 



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

From jay.krell at cornell.edu  Thu Jan 21 10:11:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 09:11:24 +0000
Subject: [M3devel] atomics addressing modes, it looks like none needed
Message-ID: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>


I tried a few differnt switches.

They always seem to get the actual address into a register.


C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod


long __cdecl _InterlockedExchange(long volatile*, long);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedIncrement(long volatile*);
#pragma intrinsic(_InterlockedIncrement)

 

 

long __cdecl _InterlockedExchangeAdd(long volatile*, long);
#pragma intrinsic(_InterlockedExchangeAdd)

 

 

long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
#pragma intrinsic(_InterlockedCompareExchange)

 

 

long F1(volatile long* a)
{
return _InterlockedIncrement(&a[10]);
}

 


typedef struct S1 { int a; long b; } S1;

long F2(volatile S1* a)
{
return _InterlockedExchangeAdd(&a->b, 123);
}

 


long F3(volatile S1* a)
{
return _InterlockedCompareExchange(&a->b, 1, 2);
}

 


long F4(volatile S1* a)
{
return _InterlockedExchange(&a->b, 1);
}


 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

t.c
; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08


        TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
        .686P
        .XMM
        include listing.inc
        .model  flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC  _F1
; Function compile flags: /Ogtpy
; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F1     PROC

; 15   : return _InterlockedIncrement(&a[10]);

  00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
  00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
  00007 b8 01 00 00 00   mov     eax, 1
  0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
  00010 40               inc     eax

; 16   : }

  00011 c3               ret     0
_F1     ENDP
_TEXT   ENDS
PUBLIC  _F2
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F2     PROC

; 23   : return _InterlockedExchangeAdd(&a->b, 123);

  00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
  00029 83 c1 04         add     ecx, 4
  0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax

; 24   : }

  00030 c3               ret     0
_F2     ENDP
_TEXT   ENDS
PUBLIC  _F3
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F3     PROC

; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);

  00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
  00044 b9 01 00 00 00   mov     ecx, 1
  00049 83 c2 04         add     edx, 4
  0004c b8 02 00 00 00   mov     eax, 2
  00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx

; 30   : }

  00055 c3               ret     0
_F3     ENDP
_TEXT   ENDS
PUBLIC  _F4
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_a$ = 8                                                 ; size = 4
_F4     PROC

; 35   : return _InterlockedExchange(&a->b, 1);

  00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
  00064 b8 01 00 00 00   mov     eax, 1
  00069 83 c1 04         add     ecx, 4
  0006c 87 01            xchg    DWORD PTR [ecx], eax

; 36   : }

  0006e c3               ret     0
_F4     ENDP
_TEXT   ENDS
END

C:\dev2\cm3.2\m3-sys\m3back\src>



probably should try IA64 though.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/282ae614/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan 21 14:29:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 13:29:12 +0000
Subject: [M3devel] fetch_and_op?
Message-ID: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>


(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)



Tony, are you sure you want to return the old value, not the new value?

That's not great on x86.

I believe for "or" and "and", you end up having to do a compare exchange loops.

 

 

For xor, add, sub, you can compute the old value, ok.

But if caller wanted the old value, he can do that himself also.

Caller can also write a compare_exchange loop.

 

 

Therefore, I think it should be:

 

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)


There is of course value in storing the value in mem and stack, since mem

can change right away.

 

 

 - Jay

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

From dabenavidesd at yahoo.es  Thu Jan 21 14:57:31 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 13:57:31 +0000 (GMT)
Subject: [M3devel] in favor of mixed operators..
In-Reply-To: <COL101-W5400DBBA7EF4A10022D7F5E6670@phx.gbl>
Message-ID: <512318.52973.qm@web23601.mail.ird.yahoo.com>

Hi all:
I think you could research some deep into gcc lists
http://gcc.gnu.org/ml/gcc/2006-12/msg00467.html 
>From what I read you are getting different results depending of optimization with overflowing

I hope this helps a bit.

El dom, 17/1/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] in favor of mixed operators..
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 04:38
> 
> 
> 
> 
>  
> http://python-history.blogspot.com/2009/03/problem-with-integer-division.html
> 
> 
> He argues that for a "high level" language, of
> course
> I should be able to add int to long, int to float, etc.
> And that int / int should not be int.
> At least Modula-3 spells them differently, / vs. MOD.
> 
> 
> Of course, "high level" vs. "systems"
> vs. "one size to fit all"...
> 
> 
> Anyway, I give up here.
> 
> 
>  - Jay
> 
> 
> 
> 
>  		 	   		  
> 


      


From hosking at cs.purdue.edu  Thu Jan 21 15:21:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:21:22 -0500
Subject: [M3devel] atomics addressing modes, it looks like none needed
In-Reply-To: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
References: <COL101-W46FE6AB1F7902E549E761FE6630@phx.gbl>
Message-ID: <1A39E99D-F8A7-4D8A-B1E6-AC9D4A53651E@cs.purdue.edu>

OK, so no indexed mode?  gcc may generate it differently.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 04:11, Jay K wrote:

> I tried a few differnt switches.
> They always seem to get the actual address into a register.
> 
> C:\dev2\cm3.2\m3-sys\m3back\src>type t.c && cl -c -Ox -FAsc t.c && type t.cod
> 
> long __cdecl _InterlockedExchange(long volatile*, long);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedIncrement(long volatile*);
> #pragma intrinsic(_InterlockedIncrement)
>  
>  
> long __cdecl _InterlockedExchangeAdd(long volatile*, long);
> #pragma intrinsic(_InterlockedExchangeAdd)
>  
>  
> long __cdecl _InterlockedCompareExchange(long volatile*, long, long);
> #pragma intrinsic(_InterlockedCompareExchange)
>  
>  
> long F1(volatile long* a)
> {
> return _InterlockedIncrement(&a[10]);
> }
>  
> 
> typedef struct S1 { int a; long b; } S1;
> long F2(volatile S1* a)
> {
> return _InterlockedExchangeAdd(&a->b, 123);
> }
>  
> 
> long F3(volatile S1* a)
> {
> return _InterlockedCompareExchange(&a->b, 1, 2);
> }
>  
> 
> long F4(volatile S1* a)
> {
> return _InterlockedExchange(&a->b, 1);
> }
> 
>  
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
> t.c
> ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08
> 
>         TITLE   C:\dev2\cm3.2\m3-sys\m3back\src\t.c
>         .686P
>         .XMM
>         include listing.inc
>         .model  flat
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
> PUBLIC  _F1
> ; Function compile flags: /Ogtpy
> ; File c:\dev2\cm3.2\m3-sys\m3back\src\t.c
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F1     PROC
> ; 15   : return _InterlockedIncrement(&a[10]);
>   00000 8b 44 24 04      mov     eax, DWORD PTR _a$[esp-4]
>   00004 8d 48 28         lea     ecx, DWORD PTR [eax+40]
>   00007 b8 01 00 00 00   mov     eax, 1
>   0000c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
>   00010 40               inc     eax
> ; 16   : }
>   00011 c3               ret     0
> _F1     ENDP
> _TEXT   ENDS
> PUBLIC  _F2
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F2     PROC
> ; 23   : return _InterlockedExchangeAdd(&a->b, 123);
>   00020 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00024 b8 7b 00 00 00   mov     eax, 123               ; 0000007bH
>   00029 83 c1 04         add     ecx, 4
>   0002c f0 0f c1 01      lock     xadd   DWORD PTR [ecx], eax
> ; 24   : }
>   00030 c3               ret     0
> _F2     ENDP
> _TEXT   ENDS
> PUBLIC  _F3
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F3     PROC
> ; 29   : return _InterlockedCompareExchange(&a->b, 1, 2);
>   00040 8b 54 24 04      mov     edx, DWORD PTR _a$[esp-4]
>   00044 b9 01 00 00 00   mov     ecx, 1
>   00049 83 c2 04         add     edx, 4
>   0004c b8 02 00 00 00   mov     eax, 2
>   00051 f0 0f b1 0a      lock     cmpxchg DWORD PTR [edx], ecx
> ; 30   : }
>   00055 c3               ret     0
> _F3     ENDP
> _TEXT   ENDS
> PUBLIC  _F4
> ; Function compile flags: /Ogtpy
> _TEXT   SEGMENT
> _a$ = 8                                                 ; size = 4
> _F4     PROC
> ; 35   : return _InterlockedExchange(&a->b, 1);
>   00060 8b 4c 24 04      mov     ecx, DWORD PTR _a$[esp-4]
>   00064 b8 01 00 00 00   mov     eax, 1
>   00069 83 c1 04         add     ecx, 4
>   0006c 87 01            xchg    DWORD PTR [ecx], eax
> ; 36   : }
>   0006e c3               ret     0
> _F4     ENDP
> _TEXT   ENDS
> END
> C:\dev2\cm3.2\m3-sys\m3back\src>
> 
> 
> probably should try IA64 though.
>  
>  
>  - Jay

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

From hosking at cs.purdue.edu  Thu Jan 21 15:23:59 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 09:23:59 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>
Message-ID: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 08:29, Jay K wrote:

> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 

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

From dabenavidesd at yahoo.es  Thu Jan 21 15:28:50 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 21 Jan 2010 14:28:50 +0000 (GMT)
Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release
	vs. head?
In-Reply-To: <58C7AE9A-3CFD-4CFC-BA7C-36286E549BF6@cs.purdue.edu>
Message-ID: <1444.87625.qm@web23608.mail.ird.yahoo.com>

Hi:
this problem was present in the code since some time ago, even before merge original cvsup sources in cm3 tree. You could see a how to repeat detailed here:
http://aivwiki.alma.cl/index.php/Installing_CVSup
This wiki entry has more than a year of existence.
I couldn't deep more because because some time ago I repeated the sequence and got the same result (first try works, and background doesn't). But not too long ago I repeated and got even worse the first attempt (non-background process didn't work) neither background so I just guessed something could be wrong on both cases with LINUXLIBC6 systems.

Please could you give me some pointers to build CM3 system with user threads on AMD64_LINUX or LINUXLIBC6 to see if this repeats 

Thanks in advance

--- El dom, 17/1/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release vs. head?
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 17 de enero, 2010 11:13
> On 17 Jan
> 2010, at 08:42, Jay K
> wrote:
> We can stick
> with the current release branch if that is indeed much
> easier.
> 
> 
> I thought there was some agreement we shouldn't release
> LONGINT as it was.
> 
> Indeed!
> I can undo the
> changes if we want.
> It's not easy with cvs (not much is) but I can do it.
> It's easy for me to diff the trees, just using windiff
> or diff (again, cvs
> seems not to help).
> 
> Surely we can move forward on this.
> Many/most/all of
> the fixes went first into head, so there's
> "nothing" to merge back,
> but diff tells us better.
> 
> I agree.
> I'm still
> planning on setting up some more machines and can do
> FreeBSD4.
> (I have PPC64_DARWIN and PPC32_OPENBSD about ready, but
> I have to check if Modula-3 actually works on them
> first...)
> 
> Let's not worry about additional
> targets. 
> Does anyone have
> the missing steps for the cvsup bug report, like the
> configuration file,
> can show the callstacks, try it with user threads..etc..?
> 
> Maybe cvsup should not be part of the
> release?
> 
> 
>  - Jay
> 
> 
> > Date: Sun, 17 Jan 2010 12:38:16 +0100
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Release Engineering: 5.8 -->
> 5.9? was: Re: release	vs.	head?
> > 
> > Quoting Jay K <jay.krell at cornell.edu>:
> > 
> > > Should we just make a new release branch?
> > > Or I keep copying stuff over somewhat
> selectively?
> > > We do want LONGCARD in the release, I assume.
> > >
> > > I'll diff the two trees again, see what
> varies.
> > > Sometimes when I do that I find stuff to take.
> > > And take the LONGCARD changes.
> > 
> > From a release engineering point of view this is more
> or less
> > a nightmare. We cannot make incompatible extensions to
> the feature
> > set after the fourth release candidate.
> > 
> > The only clean way I'd see to even get the LONGINT
> changes into the
> > next release would be to start anew. Meaning declaring
> 5.8.4 as
> > the latest release and develop 5.9 on the trunk. Of
> course we'd
> > have to carefully merge back any fixes that might be
> missing on the
> > trunk right now.
> > 
> > That said, I have currently neither the time nor the
> energy to do all
> > that cleanly. I didn't even get round to set up
> release builds
> > on new.elego.de via Hudson in
> order to cover the FreeBSD4 target
> > platform we recently lost in the release due to my
> home machine's
> > complete crash in December. So the release engineering
> support is not
> > in the best of states I must admit.
> > 
> > I could live with declaring 5.8.RC4 as an intermediate
> release,
> > but somebody really needs to do all the housekeeping
> of comparing
> > and merging branches. And we shouldn't start a new
> release branch
> > until things have settled down.
> > 
> > Is anybody interested in taking over some of the
> release engineering
> > tasks (including Hudson management and re-targeting to
> the new release)?
> > 
> > Please keep in mind that we haven't managed to get
> out a stable release
> > for several years now.
> > 
> > Olaf
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869
> fax: +49 30 23 45 86 95
> > http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> > 
> 
> 


      


From hendrik at topoi.pooq.com  Thu Jan 21 19:02:29 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:02:29 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
Message-ID: <20100121180229.GA13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
> Subranges have a memory size that depends on the size of the subrange.  
> All arithmetic is performed using the precision of the base type 
> however.

If the compiler can prove it makes no difference, shorter arithmetic is 
sometimes possible.

-- hendrik


From hendrik at topoi.pooq.com  Thu Jan 21 19:14:56 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 21 Jan 2010 13:14:56 -0500
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <20100121181456.GC13592@topoi.pooq.com>

On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> 
> Seems like modernising it might attract some more developers. i.e. 
> Bring the X interface up to date(X11R6) and support things like DRM, 
> XRandr, etc... And update OpenGL for NURBS, VBOs, etc...

I hear the OpenGL itself is undergoing massive change at the moment.  We 
may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
told, no longer deals in individual triangles, squares, and the like, 
but only in arrays of same, to better use graphic card parallelism.

-- hendrik


From peter.mckinna at gmail.com  Thu Jan 21 20:33:54 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 22 Jan 2010 06:33:54 +1100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100120205327.e8547d50.Highjinks@gmx.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
Message-ID: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>

I've been looking at this area a bit. I have just completed the interface to
GLUT which should be ready to commit in a few weeks as soon as i get a few
more examples tested. This gives you the conventional opengl/X linking. Its
taken a while to get my head around swig which seems a better way to feed
into the C world. I have also nearly completed a new interface for mysql
giving it a safe M3 interface and gives the complete mysql.h api. I was
thinking of using swig for the gtk bindings but not sure how well the c++
mappings are handled

regards Peter

On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:

> It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui
> haven't been touched or updated since the early 90s.
>
> Seems like modernising it might attract some more developers. i.e. Bring
> the X interface up to date(X11R6) and support things like DRM, XRandr,
> etc... And update OpenGL for NURBS, VBOs, etc...
> Trestle is easy to write for, but it really is butt ugly.
>
> Is anyone else looking at this area of the system?
>
>
> --
> Chris <Highjinks at gmx.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/fe7d8419/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jan 21 23:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 21 Jan 2010 22:30:00 +0000
Subject: [M3devel] fetch_and_op?
In-Reply-To: <CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
Message-ID: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>


ok.

 

But notice that they offer both forms really since they also have "modifying asignment operators".
Is that useful/possible to expose?

 


http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html

 


"The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "

 


For now I'll probably just expose add, sub, xor, but not or and and.
We can do them later via a compareexchange loop (see winbase.h which
does something similar for different reasons: lack of intrinsics).

 


Still a ways away from calling this done, because modifying
m3x86.m3 so far requires a lot of guessing/patternmatching.
I don't understand e.g. what "locked" means (not the
one I introduced, what was there).

 


 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 09:23:59 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] fetch_and_op?

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.




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 21 Jan 2010, at 08:29, Jay K wrote:

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)


Tony, are you sure you want to return the old value, not the new value?
That's not great on x86.
I believe for "or" and "and", you end up having to do a compare exchange loops.
 
 
For xor, add, sub, you can compute the old value, ok.
But if caller wanted the old value, he can do that himself also.
Caller can also write a compare_exchange loop.
 
 
Therefore, I think it should be:
 
(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)

There is of course value in storing the value in mem and stack, since mem
can change right away.
 
 
 - Jay


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

From dragisha at m3w.org  Thu Jan 21 23:27:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 21 Jan 2010 23:27:12 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
Message-ID: <1264112832.3531.22.camel@faramir.m3w.org>

Modernizing of GUI is not so big a problem - lots of C(++) libraries
around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
- there's nothing like a manual touch! And I've wrapped pthreads, mysql,
sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.

Modula-3 philosophy (at least it looks to me sometimes) is to think
about Modula-3 legacy libraries/project like it's something carved in
stone... To be kosher we must use right (legacy of course and
all-platforms of coursier :)) libraries for every job.... Nice idea, esp
when we whink longer term maintenance... But what made projects like,
for example, Linux desktop successful is not single solution path - it's
diversity of possible solutions.

Main problem with diversity of solutions is multi-platform nature of
Modula-3 - solutions not multi-platform are not likely to be accepted...
And while it's relatively easy to wrte your Modula-3 code multiplatfom,
taking care of C(++) libraries can be real pain....

Thus said - I can tell you one thing - JUST DO IT :). I don't see a
problem if my projects work only on Linux - once I have incentive to go
through a hassle to make it work on Windows, I'll synchronize. But it's
important to to many things with Modula-3 - more will come a lot easier.

On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> I've been looking at this area a bit. I have just completed the
> interface to GLUT which should be ready to commit in a few weeks as
> soon as i get a few more examples tested. This gives you the
> conventional opengl/X linking. Its taken a while to get my head around
> swig which seems a better way to feed into the C world. I have also
> nearly completed a new interface for mysql giving it a safe M3
> interface and gives the complete mysql.h api. I was thinking of using
> swig for the gtk bindings but not sure how well the c++ mappings are
> handled 
>  
> regards Peter 
> 
> 
> On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
>         It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
>         in m3-ui haven't been touched or updated since the early 90s.
>         
>         Seems like modernising it might attract some more developers.
>         i.e. Bring the X interface up to date(X11R6) and support
>         things like DRM, XRandr, etc... And update OpenGL for NURBS,
>         VBOs, etc...
>         Trestle is easy to write for, but it really is butt ugly.
>         
>         Is anyone else looking at this area of the system?
>         
>         
>         --
>         Chris <Highjinks at gmx.com>
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Fri Jan 22 00:23:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 18:23:52 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <20100121180229.GA13592@topoi.pooq.com>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
Message-ID: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>

Possibly, but it would require some fairly strong type analysis in the compiler.  And of course it is not fully general.

On 21 Jan 2010, at 13:02, hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 03:36:24AM -0500, Tony Hosking wrote:
>> Subranges have a memory size that depends on the size of the subrange.  
>> All arithmetic is performed using the precision of the base type 
>> however.
> 
> If the compiler can prove it makes no difference, shorter arithmetic is 
> sometimes possible.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Fri Jan 22 01:02:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 21 Jan 2010 19:02:25 -0500
Subject: [M3devel] fetch_and_op?
In-Reply-To: <COL101-W444844DDB04656E4B49275E6630@phx.gbl>
References: <COL101-W12CA1803F3B1DFC1C654E7E6630@phx.gbl>,
	<CB754F8F-5F2E-4553-AA99-FB256E0AAAB4@cs.purdue.edu>
	<COL101-W444844DDB04656E4B49275E6630@phx.gbl>
Message-ID: <433C7056-D71E-4A01-8C82-7B3F44FC363F@cs.purdue.edu>

Wrong link.  I'm talking C not C++.

Here's the C link:

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf

PS I am shortly about to change the specs on compare exchange in M3CG_Ops.i3.  Stay tuned.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 21 Jan 2010, at 17:30, Jay K wrote:

> ok.
>  
> But notice that they offer both forms really since they also have "modifying asignment operators".
> Is that useful/possible to expose?
>  
> 
> http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html
>  
> 
> "The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "
>  
> 
> For now I'll probably just expose add, sub, xor, but not or and and.
> We can do them later via a compareexchange loop (see winbase.h which
> does something similar for different reasons: lack of intrinsics).
>  
> 
> Still a ways away from calling this done, because modifying
> m3x86.m3 so far requires a lot of guessing/patternmatching.
> I don't understand e.g. what "locked" means (not the
> one I introduced, what was there).
>  
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 21 Jan 2010 09:23:59 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] fetch_and_op?
> 
> I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.
> 
> 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 21 Jan 2010, at 08:29, Jay K wrote:
> 
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp; pop *)
> 
> 
> Tony, are you sure you want to return the old value, not the new value?
> That's not great on x86.
> I believe for "or" and "and", you end up having to do a compare exchange loops.
>  
>  
> For xor, add, sub, you can compute the old value, ok.
> But if caller wanted the old value, he can do that himself also.
> Caller can also write a compare_exchange loop.
>  
>  
> Therefore, I think it should be:
>  
> (* tmp := Mem [s1.A].t;
>    Mem [s1.A].t := tmp op s0.u;
>    s1.u := tmp op s0.u; pop *)
> 
> There is of course value in storing the value in mem and stack, since mem
> can change right away.
>  
>  
>  - Jay
> 
> 
> 

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

From Highjinks at gmx.com  Fri Jan 22 01:29:35 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 01:29:35 +0100 (CET)
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <20100121181456.GC13592@topoi.pooq.com>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	<20100121181456.GC13592@topoi.pooq.com>
Message-ID: <20100121203246.25046ad5.Highjinks@gmx.com>

On Thu, 21 Jan 2010 13:14:56 -0500
hendrik at topoi.pooq.com wrote:

> On Thu, Jan 21, 2010 at 01:50:20AM +0100, Chris wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...) in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers. i.e. 
> > Bring the X interface up to date(X11R6) and support things like DRM, 
> > XRandr, etc... And update OpenGL for NURBS, VBOs, etc...
> 
> I hear the OpenGL itself is undergoing massive change at the moment.  We 
> may have to replace its Modula 3 binding anyway.  The new OpenGL, I'm 
> told, no longer deals in individual triangles, squares, and the like, 
> but only in arrays of same, to better use graphic card parallelism.
> 
> -- hendrik

Definitely a chore. As an excercise I plan to start porting the NeHe tutorials over to Modula 3. However, a big question for me is where to begin.

Idealy an application written to the older standards should still be able to compile and run on new cards, which MIGHT mean mapping the current bindings over top a set bindings to the new standards. We'll see how the standards board deals with that issue.

Also upgrading the X bindings will also be a challenge. The nice thing about the current X window system is that it's far more modular than the X11R4 in the current library. That should make it easier to upgrade the interface systematically, one piece at a time.
-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 12:55:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 11:55:29 +0000
Subject: [M3devel] NT386 div/mod
Message-ID: <COL101-W5358CF13F1BCC0A6C02A8DE6620@phx.gbl>


It is interesting to note that NT386 doesn't use the m3_mod/div functions, but generates inline code:

 

PROCEDURE diffdivOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>
    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*   MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*   XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*   JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*   XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*   CDQ               *)
    END;
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*   JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab        *)
    noargOp(t, Op.oCDQ);                              (*   CDQ               *)
    idivOp(t, divisor);                               (*   IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*   CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*   JE  endlab        *)
    decOp(t, t.reg[EAX]);                             (*   DEC EAX           *)
    set_label(t, endlab);                             (* .endlab             *)
  END diffdivOp;

 

PROCEDURE diffmodOp (t: T; READONLY divisor: Operand; apos: BOOLEAN) =
  VAR
    diffsignlab := reserve_labels(t, 1, TRUE);
    endlab := reserve_labels(t, 1, TRUE);
  BEGIN
    <* ASSERT divisor.loc = OLoc.register *>

    movOp(t, t.reg[EDX], t.reg[EAX]);                 (*    MOV EDX, EAX      *)
    binOp(t, Op.oXOR, t.reg[EDX], divisor);           (*    XOR EDX, divisor  *)
    brOp(t, Cond.L, diffsignlab);                     (*    JL  diffsignlab   *)
    IF apos
      THEN binOp(t, Op.oXOR, t.reg[EDX], t.reg[EDX]); (*    XOR EDX, EDX      *)
      ELSE noargOp(t, Op.oCDQ);                       (*    CDQ               *)
    END;
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    brOp(t, Cond.Always, endlab);                     (*    JMP endlab        *)
    set_label(t, diffsignlab);                        (* .diffsignlab         *)
    noargOp(t, Op.oCDQ);                              (*    CDQ               *)
    idivOp(t, divisor);                               (*    IDIV EAX, divisor *)
    immOp(t, Op.oCMP, t.reg[EDX], TZero);             (*    CMP EDX, #0       *)
    brOp(t, Cond.E, endlab);                          (*    JE  endlab        *)
    binOp(t, Op.oADD, t.reg[EDX], divisor);           (*    ADD EDX, divisor  *)
    set_label(t, endlab);                             (* .endlab              *)
  END diffmodOp;


 

I haven't tested it yet, but of course you can see that same signed inputs are simpler, like with the code in hand.c.

I'm really starting to like CARDINAL and not INTEGER. :)

(Plus the subtlety that CARDINAL has a default initialization to 0 that Tony told me about.)

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/5bf37fec/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 22 13:05:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:05:10 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>


 > Linux desktop successful 

 

Haha. Military intelligence.

 

 

 > it's diversity of possible solutions.

 

Chaos! Lack of interop. Duplicated effort.

Granted, Darwinism/Capitalism, but very wasteful.

 


 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 


 

I'm sure we can win here, if we do anything.

  (I'm not volunteering. The idea of using Swig is good.)

Just wrap Qt or FLTK or Tk or wxWidgets or such.

Qt is my preferred.

  It seems to have the most active resources spent on it and

  is in the best condition already.

GTk on Windows doesn't seem to get enough attention.

Tk has a seemingly good track record in that

 people have successfully used it already from several

 languages: Python, Perl, Tcl (blech!), C.

wxWidgets also has Python bindings at least.

 

 

Things only get less clear if you worry about non Win32/64/XWindows

platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.

And Trestle doesn't support any of those anyway, and they are all

"obsolete" except non-X Mac (see also: iPhone!)

I'm surprised I haven't see that Qt supports iPhone.

If a library does support Carbon/Cocoa that is a point in favor imho.

 


 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/ad0b88a8/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 22 13:11:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:11:47 +0000
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <1264112832.3531.22.camel@faramir.m3w.org>
References: <20100120205327.e8547d50.Highjinks@gmx.com>,
	<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>,
	<1264112832.3531.22.camel@faramir.m3w.org>
Message-ID: <COL101-W10C5CCBC345BFB0C3AF22DE6620@phx.gbl>


> > Trestle is easy to write for, but it really is butt ugly.


 

I should point that making Trestle not look ugly is perhaps

a much smaller task than wrapping any other library.

 

 

Randy's Win32 changes to Trestle definitely make it look better for example.

 

 

It was previously asserted that X Trestle shall not look like Win32.

However, X Trestle doesn't look like anything except itself, right?

So I figure Win32 is among the good choices.

Besides, given that there is no "standard X look", even if X Trestle

does look like *something*, Win32 would still be preferable.

(This would remove the forking we have where only one fork

or another has a bug, X vs. Win32..really need to merge/refactor

that code, no matter the decision and the resulting look..)

 

 - Jay

 


From: jay.krell at cornell.edu
To: dragisha at m3w.org; peter.mckinna at gmail.com
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Modernising m3-ui?
Date: Fri, 22 Jan 2010 12:05:10 +0000



 > Linux desktop successful 
 
Haha. Military intelligence.
 
 
 > it's diversity of possible solutions.
 
Chaos! Lack of interop. Duplicated effort.
Granted, Darwinism/Capitalism, but very wasteful.
 

 > Main problem with diversity of solutions is multi-platform nature of 
 > Modula-3 - solutions not multi-platform are not likely to be accepted... 

 
I'm sure we can win here, if we do anything.
  (I'm not volunteering. The idea of using Swig is good.)
Just wrap Qt or FLTK or Tk or wxWidgets or such.
Qt is my preferred.
  It seems to have the most active resources spent on it and
  is in the best condition already.
GTk on Windows doesn't seem to get enough attention.
Tk has a seemingly good track record in that
 people have successfully used it already from several
 languages: Python, Perl, Tcl (blech!), C.
wxWidgets also has Python bindings at least.
 
 
Things only get less clear if you worry about non Win32/64/XWindows
platforms, like OS/2, Mac9, non-X Mac, Carbon/Cocoa, Win16, MS-DOS (framebuffer+mouse+keyboard), etc.
And Trestle doesn't support any of those anyway, and they are all
"obsolete" except non-X Mac (see also: iPhone!)
I'm surprised I haven't see that Qt supports iPhone.
If a library does support Carbon/Cocoa that is a point in favor imho.
 

 - Jay

 
> From: dragisha at m3w.org
> To: peter.mckinna at gmail.com
> Date: Thu, 21 Jan 2010 23:27:12 +0100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modernising m3-ui?
> 
> Modernizing of GUI is not so big a problem - lots of C(++) libraries
> around.... And after wrapping _LOTS OF_ C libraries I can tell one thing
> - there's nothing like a manual touch! And I've wrapped pthreads, mysql,
> sqlite, gtk, gtk2, zip, bzip2, zaptel, libpri .....and many more.
> 
> Modula-3 philosophy (at least it looks to me sometimes) is to think
> about Modula-3 legacy libraries/project like it's something carved in
> stone... To be kosher we must use right (legacy of course and
> all-platforms of coursier :)) libraries for every job.... Nice idea, esp
> when we whink longer term maintenance... But what made projects like,
> for example, Linux desktop successful is not single solution path - it's
> diversity of possible solutions.
> 
> Main problem with diversity of solutions is multi-platform nature of
> Modula-3 - solutions not multi-platform are not likely to be accepted...
> And while it's relatively easy to wrte your Modula-3 code multiplatfom,
> taking care of C(++) libraries can be real pain....
> 
> Thus said - I can tell you one thing - JUST DO IT :). I don't see a
> problem if my projects work only on Linux - once I have incentive to go
> through a hassle to make it work on Windows, I'll synchronize. But it's
> important to to many things with Modula-3 - more will come a lot easier.
> 
> On Fri, 2010-01-22 at 06:33 +1100, Peter McKinna wrote:
> > I've been looking at this area a bit. I have just completed the
> > interface to GLUT which should be ready to commit in a few weeks as
> > soon as i get a few more examples tested. This gives you the
> > conventional opengl/X linking. Its taken a while to get my head around
> > swig which seems a better way to feed into the C world. I have also
> > nearly completed a new interface for mysql giving it a safe M3
> > interface and gives the complete mysql.h api. I was thinking of using
> > swig for the gtk bindings but not sure how well the c++ mappings are
> > handled 
> > 
> > regards Peter 
> > 
> > 
> > On Thu, Jan 21, 2010 at 11:50 AM, Chris <Highjinks at gmx.com> wrote:
> > It looks like most of the libs(Trestle, X11R4, OpenGL, etc...)
> > in m3-ui haven't been touched or updated since the early 90s.
> > 
> > Seems like modernising it might attract some more developers.
> > i.e. Bring the X interface up to date(X11R6) and support
> > things like DRM, XRandr, etc... And update OpenGL for NURBS,
> > VBOs, etc...
> > Trestle is easy to write for, but it really is butt ugly.
> > 
> > Is anyone else looking at this area of the system?
> > 
> > 
> > --
> > Chris <Highjinks at gmx.com>
> > 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/9a1ddafa/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 22 13:39:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 12:39:21 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
Message-ID: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>


Anyone have any thoughts on how to implement LONGINT on NT386?

 


The code is setup to do pretty good constant folding and enregistration.

 


I did the work so that constant folding should work for LONGINT.

 


However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 

In particular, there is still this notion of an "operand"
that might be held in one register.


 

I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.

 


96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.


 

Returning LONGINT from a function also needs separate attention.

Maybe I really should go ahead and use an array of registers?

 


 - Jay

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

From hosking at cs.purdue.edu  Fri Jan 22 15:49:28 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 09:49:28 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>
Message-ID: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>

That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.

On 22 Jan 2010, at 07:39, Jay K wrote:

> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 

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

From hendrik at topoi.pooq.com  Fri Jan 22 20:13:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 22 Jan 2010 14:13:14 -0500
Subject: [M3devel] __int128 coming to gcc
In-Reply-To: <DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
References: <6731E9FF-FDFD-484E-B3BC-E0EEBD05DDA5@cs.purdue.edu>
	<COL101-W49450C1445C7473A195E5DE6630@phx.gbl>
	<FA1D813B-DAE8-47E8-9B4C-5CDB8422CB99@cs.purdue.edu>
	<20100121180229.GA13592@topoi.pooq.com>
	<DF4BEF19-B0F3-4A4E-A5E9-26E64E246FFB@cs.purdue.edu>
Message-ID: <20100122191314.GA6271@topoi.pooq.com>

On Thu, Jan 21, 2010 at 06:23:52PM -0500, Tony Hosking wrote:
> Possibly, but it would require some fairly strong type analysis in the 
compiler.

Analysis that could be done during code generation.

>  And of course it is not fully general.

Of course.  Optimisations only work when they can be proved to.  But 
when they do work, they can make a lot of difference.

-- hendrik


From rodney_bates at lcwb.coop  Fri Jan 22 20:56:37 2010
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Fri, 22 Jan 2010 19:56:37 -0000 (GMT)
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>
Message-ID: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>

>
> So..I have m3back using Target.Int a bunch.
>
> And converting back and forth some between Target.Int and
>
> INTEGER and doing match with Target.Int.
>
> And various operations can fail.
>
>
>
>
>
> And my current diff results in:
>
>
>
>
>
>   new source -> compiling Lex.m3
>   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
>   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
>   2 errors encountered
>   new source -> compiling Scan.i3
>
>
>
>
>
>   which is nice to see, it means my code is actually running.
>
>
>
>
>
>   So I look at the code in question:
>
>
>
>
>
>   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> Word.T
>   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> ...
>
>     IF signed AND
>        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
>         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
>       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> ....
>
>
>
>
>
> -FIRST(INTEGER).
>
>
>
>
>
> What is that supposed to do?
>
>
>
>
>
> I mean, I kind of know, I'm slightly playing stupid, partly not.
>
> Does the compiler know what is an INTEGER vs. what is a "Word"?
  ---------------------------------------------------------Word.T?

No, they are the same type.

> Or it is just obligated to assume everything is a Word?

It is obligated to do the builtin operators (unary - being one
of these) using signed interpretation of the value and functions
in Word using unsigned interpretation.

The signed operators don't assume anything about the machine
representation.  The functions in Word do assume two-s complement
binary, in order to be defined.  This is a low-level facility.

>  To do the negation at compile time and ignore the overflow?

This may be poorly specified.  The code sample you cite clearly assumes
this is what it does.  The compile errors indicate the assumption
has become wrong.

> Does the language need work here?

Overflow detection wars!  But surely, we could agree that compile time
arithmetic should do the same thing as runtime would, for a given
implementation.

> I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?

Yes, it's a statically unconditional overflow, and the language doesn't
specify what happens.

As long as we are assuming two-s complement binary, I would just remove
the - in front of FIRST(INTEGER). If the compiler does not consider it
and overflow error and wraps around, in this particular case, the - is
an identity operation on the bits.  Maybe the writer intended the -
to hint to a human reader that unsigned interpretation is about to be
applied to this value.

>
>
>
>
>  - Jay
>
>
>




From Highjinks at gmx.com  Fri Jan 22 22:09:53 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 22 Jan 2010 22:09:53 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
Message-ID: <20100122171259.f8cdc16c.Highjinks@gmx.com>

My opinion on what to do as far as these libs are concerned...

First, we should just stick to updating what's already there, right? Add bindings to Xrandr, XCBlib, Cairo, etc.. in a new X11R6 directory. Break down that X.i3 file into several smaller modules. Major changes should wait till later. Bindings to QT, GTK, etc.. are good ideas, but should be OPTIONAL, not required. Undoubtedly many platforms that will be running Modula 3 applications will not have one or either of these libraries installed.
Theres also the possibility of building our own Windowing toolkit. We already have Trestle. Maybe call it "Beam"?

The same with OpenGL. Point in case, MiniGLX. Theres a good chance that any platform using MiniGLX will not have X Windows, or any other Windowing environment installed. 

Consider embedded and kiosk environments. Modula 3 is well suited to these sorts of applications, but these environments are usually limited in the size and scope of the libraries and code they can run.

Later on, we could extend Trestle and even create our own Scenegraph library for OpenGL, if it makes sense to do so.  Hrrrmmm...Call the Scenegraph lib "Ray"?

I have a little free time coming up this weekend. I'll be porting some of the demos I have over to OpenGL, and doing a little M3/XCBlib hacking. Anyone want me to post these up somewhere, for the "lulz" as it were?

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 22 23:51:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:51:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
Message-ID: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>


I think there is a language hole here.The language should perhaps allow forunsigned literals and unsigned constantexpressions.

Something I don't quite have my head around as well,maybe a language/library hole, is how to doe.g. the below, without assuming two's complementrepresentation of signed integers.

Can we maybe add Word.AbsoluteValueOfInteger?The implementation would, roughly:  IF i < 0 THEN     i := -i;  END;  RETURN i;  END;
with the extra qualification that overflow is silent

 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.
Uh huh. This is why you need *different types* (or interfaces)for the variety of integer overflow behavior and not a runtimesetting. Otherwise the compiler can't know what theruntime behavior is.

As well, using static typing instead of a runtime setting,allows for efficiency. Imagine, say, if x86 does requireextra code to check for overflow.Well, if using "integer-with-silent-overflow", thatwould be omitted. If using "integer-with-overflow"the code would be included.

I introduce the error. It used to be silent.I changed it to a warning, for thevery specific case of negating FIRST(INTEGER).Any other overflow here, which is probably notpossible, will still error.
 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> >   new source -> compiling Lex.m3
> >   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> >   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> >   2 errors encountered
> >   new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> >   which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> >   So I look at the code in question:
> >
> >
> >
> >
> >
> >   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> >   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> >     IF signed AND
> >        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> >         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> >       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
>   ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation.  The functions in Word do assume two-s complement
> binary, in order to be defined.  This is a low-level facility.
> 
> >  To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified.  The code sample you cite clearly assumes
> this is what it does.  The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars!  But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits.  Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> >  - Jay
> >
> >
> >
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/e3ab2126/attachment-0002.html>

From jay.krell at cornell.edu  Fri Jan 22 23:53:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 22 Jan 2010 22:53:41 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W56A6FF0AF064BA0D485D6DE6620@phx.gbl>


I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From hosking at cs.purdue.edu  Sat Jan 23 00:52:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 22 Jan 2010 18:52:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>
Message-ID: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>

There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.

Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.

Constant expressions:

CONST x = Word.Plus(16_FFFF, 1)


On 22 Jan 2010, at 17:51, Jay K wrote:

> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 

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

From jay.krell at cornell.edu  Sat Jan 23 06:00:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 05:00:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W286ECA1F5DDC64BBA034F7E6610@phx.gbl>


Sorry, not literals.

 

How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?

 

How do I express -FIRST(INTEGER)? Without incurring signed overflow

while evaluating the constant expression?

 

For a one's complement system, nothing wrong with -FIRST(INTEGER).

  It equals LAST(INTEGER).

 

But for a two's complement system, evaluating -FIRST(INTEGER)

 incurs overflow.

 

Maybe:

 Word.Add(-(FIRST(INTEGER) + 1)), 1)

 

?

 

Probably. I'll try that.

 

You know, C has the same dilemna and similar solution.

not a great idea to write

unsigned u = (unsigned)-INT_MIN;

 

nor

 

unsigned u = -(unsigned)INT_MIN;

 

though the second is maybe ok.

The first incurs signed overflow in C as well.

Which isn't defined. The first also gets a warning

with some compilers: "negating unsigned is still unsigned".

 

An idiom is

unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;

 

derivation:

INT_MIN + 1 yields a negative number that can be safely negated.

Which yields a positive number one less than the desired value.

 

 

 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here.
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

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

From dragisha at m3w.org  Sat Jan 23 11:53:28 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 11:53:28 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244008.3883.777.camel@faramir.m3w.org>

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
>  > Linux desktop successful 
>  
> Haha. Military intelligence.

Orders of magnitude more than yours and mine favorite project.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sat Jan 23 12:06:04 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Jan 2010 12:06:04 +0100
Subject: [M3devel] Modernising m3-ui?
In-Reply-To: <COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
References: <20100120205327.e8547d50.Highjinks@gmx.com>
	,<3d9e5afc1001211133t709f7fb5v13505aad20b3036e@mail.gmail.com>
	,<1264112832.3531.22.camel@faramir.m3w.org>
	<COL101-W61CAFD6B415F6D11B8C722E6620@phx.gbl>
Message-ID: <1264244764.3883.803.camel@faramir.m3w.org>

What SWiG does is only tiniest possible piece of work. Modula-3's way is
not about accepting somebody's (especially C-world's) ideas on
modularity/API's/... and mappping variables/procedures/functions/... to
Modula-3 ones. C world  API's are more or less nightmare, my "favourite"
being pthreads which is full of compromises made to get (mainly) Sun's
signature on standard... sqlite3 is another one not too away from....

But, of course, it's everybody's right to spend her time SWiG-ging
around :)... Me, after tons of experience with it, I'll continue to work
mostly by hand. Automated solutions we need aren't in SWiG... To make,
for example, proper Modula-3 objects from Gtk gobjects, we need custom
conversions...

I've already dipped into this with Gtk and it's enlightening... It's
customary in Python/Perl (h2def, gtkdoc) world to use regexps for
parsing.... When I saw it first I smiled, but when I tried two different
tools and got same buggy output, it became more serious :). 

What we need to exploit widely available C libraries is good and
proper .h parser, and then some tools to rewrite them into Modula-3...
What SWiG offers is one posibility, but we need someone proficient with
Modula-3 to join them - first guy who tried it went Haskell some time
ago.

dd

On Fri, 2010-01-22 at 12:05 +0000, Jay K wrote:
> > Main problem with diversity of solutions is multi-platform nature
> of 
>  > Modula-3 - solutions not multi-platform are not likely to be
> accepted... 
> 
>  
> I'm sure we can win here, if we do anything.
>   (I'm not volunteering. The idea of using Swig is good.)
> Just wrap Qt or FLTK or Tk or wxWidgets or such.
> Qt is my preferred.
-- 
Dragi?a Duri? <dragisha at m3w.org>



From m3 at sol42.com  Sat Jan 23 12:17:07 2010
From: m3 at sol42.com (Daniel Solaz)
Date: Sat, 23 Jan 2010 12:17:07 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
Message-ID: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>

I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.

Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.

Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.

Regards.
-Daniel

From jay.krell at cornell.edu  Sat Jan 23 16:31:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 15:31:38 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>


 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000








I'll see what I can figure out.

I considered pushings pairs of operands in m3x86.m3 but I thinkthat won't work.

Noticing how integer vs. floating point is handledis perhaps useful, as this is another way in which m3cgis "homogenous" but backends have to act differentlybased on type.

 - Jay



From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?




That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
On 22 Jan 2010, at 07:39, Jay K wrote:Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.
 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From jay.krell at cornell.edu  Sat Jan 23 20:30:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Jan 2010 19:30:33 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
Message-ID: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>


Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?

As well, should we go the extra bit and disallow it even if it doesn't overflow?
  ie: on one's complement?

 

 

I already disallow it in some code -- depending on which code gets

hit in the backend. But this disallowing is new.

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
Date: Sat, 23 Jan 2010 05:00:34 +0000



Sorry, not literals.
 
How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
 
How do I express -FIRST(INTEGER)? Without incurring signed overflow
while evaluating the constant expression?
 
For a one's complement system, nothing wrong with -FIRST(INTEGER).
  It equals LAST(INTEGER).
 
But for a two's complement system, evaluating -FIRST(INTEGER)
 incurs overflow.
 
Maybe:
 Word.Add(-(FIRST(INTEGER) + 1)), 1)
 
?
 
Probably. I'll try that.
 
You know, C has the same dilemna and similar solution.
not a great idea to write
unsigned u = (unsigned)-INT_MIN;
 
nor
 
unsigned u = -(unsigned)INT_MIN;
 
though the second is maybe ok.
The first incurs signed overflow in C as well.
Which isn't defined. The first also gets a warning
with some compilers: "negating unsigned is still unsigned".
 
An idiom is
unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
 
derivation:
INT_MIN + 1 yields a negative number that can be safely negated.
Which yields a positive number one less than the desired value.
 
 
 - Jay



Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 18:52:05 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu





There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.


Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.



Constant expressions:


CONST x = Word.Plus(16_FFFF, 1)




On 22 Jan 2010, at 17:51, Jay K wrote:

I think there is a language hole here. 
The language should perhaps allow for
unsigned literals and unsigned constant
expressions.




Something I don't quite have my head around as well,
maybe a language/library hole, is how to do
e.g. the below, without assuming two's complement
representation of signed integers.




Can we maybe add Word.AbsoluteValueOfInteger?
The implementation would, roughly:
  IF i < 0 THEN 
    i := -i;
  END;
  RETURN i;
  END;


with the extra qualification that overflow is silent




 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.


Uh huh. This is why you need *different types* (or interfaces)
for the variety of integer overflow behavior and not a runtime
setting. Otherwise the compiler can't know what the
runtime behavior is.




As well, using static typing instead of a runtime setting,
allows for efficiency. Imagine, say, if x86 does require
extra code to check for overflow.
Well, if using "integer-with-silent-overflow", that
would be omitted. If using "integer-with-overflow"
the code would be included.




I introduce the error. It used to be silent.
I changed it to a warning, for the
very specific case of negating FIRST(INTEGER).
Any other overflow here, which is probably not
possible, will still error.


 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> > new source -> compiling Lex.m3
> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > 2 errors encountered
> > new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> > which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> > So I look at the code in question:
> >
> >
> >
> >
> >
> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> > IF signed AND
> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
> ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation. The functions in Word do assume two-s complement
> binary, in order to be defined. This is a low-level facility.
> 
> > To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified. The code sample you cite clearly assumes
> this is what it does. The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars! But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits. Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> > - Jay
> >
> >
> >
> 
> 

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

From Highjinks at gmx.com  Sat Jan 23 23:02:22 2010
From: Highjinks at gmx.com (Chris)
Date: Sat, 23 Jan 2010 23:02:22 +0100 (CET)
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
Message-ID: <20100123180535.9ee26d0e.Highjinks@gmx.com>

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hendrik at topoi.pooq.com  Sat Jan 23 23:13:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:13:35 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <20100123221335.GC6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> 
> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> 
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?

The only reason for disallowing it is overflow, and then only for an 
implementation that checks overflow.  But if it doesn't overflow, 
it doesn't overflow, and it's valid.

-- hendrik

> I already disallow it in some code -- depending on which code gets
> 
> hit in the backend. But this disallowing is new.

It might warrant a portability warning, if we issue such.

-- hendrik


From hendrik at topoi.pooq.com  Sat Jan 23 23:15:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 23 Jan 2010 17:15:03 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <20100123221503.GD6033@topoi.pooq.com>

On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
> 
> > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> > 
> > Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > 
> > Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> > 
> > Regards.
> > -Daniel
> 
> Good points.
> 
> I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> 
> Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> 
> So, bindings are the way to start at least. Alright then. Time to get hacking.

Especially bindings to subsystems and toolkits that are available in a 
variety fo platforms.

-- hendrik

> -- 
> Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Sun Jan 24 01:35:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:35:18 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123221503.GD6033@topoi.pooq.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>,
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<20100123221503.GD6033@topoi.pooq.com>
Message-ID: <COL101-W45BB63A36E65A8F0A9421E6600@phx.gbl>


 > wraps the native toolkit on each platform

 

I don't think wrapping native is the way to go.

Too much work to then have a common interface.


> Especially bindings to subsystems and toolkits that are available in a variety fo platforms.

 

 

Yes.

E.g. Qt, FLTK, Tk, etc.

I think Qt is the best, based on highly non-scientific data.

 

 

- Jay
 
> Date: Sat, 23 Jan 2010 17:15:03 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sat, Jan 23, 2010 at 11:02:22PM +0100, Chris wrote:
> > On Sat, 23 Jan 2010 12:17:07 +0100
> > Daniel Solaz <m3 at sol42.com> wrote:
> > 
> > > I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets. Where there is no single native toolkit, choose the best or most used. Portability, full interoperability and looking/feeling native are the key points here.
> > > 
> > > Developing a new toolkit in pure Modula-3 is a waste of effort. Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on. Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect. SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> > > 
> > > Making Trestle look good will only get us so far. I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts. Text handling comes to mind, and scrollbars too.
> > > 
> > > Regards.
> > > -Daniel
> > 
> > Good points.
> > 
> > I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)
> > 
> > Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.
> > 
> > So, bindings are the way to start at least. Alright then. Time to get hacking.
> 
> Especially bindings to subsystems and toolkits that are available in a 
> variety fo platforms.
> 
> -- hendrik
> 
> > -- 
> > Chris <Highjinks at gmx.com>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/9217803c/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 24 01:45:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 00:45:34 +0000
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>,
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>,
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <COL101-W78609AC77B82C715B3289E6600@phx.gbl>


What I meant was..like..hypothetically..if we had a one's complement

target, would we error for -FIRST(INTEGER), since it would

overflow on other systems. Nevermind.

 

 

 - Jay 

 

> Date: Sat, 23 Jan 2010 17:13:35 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> CC: hendrik at topoi.pooq.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
> > 
> > Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> > 
> > As well, should we go the extra bit and disallow it even if it doesn't overflow?
> > ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow. But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
> > I already disallow it in some code -- depending on which code gets
> > 
> > hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

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

From darko at darko.org  Sun Jan 24 02:59:26 2010
From: darko at darko.org (Darko)
Date: Sun, 24 Jan 2010 12:59:26 +1100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com>
	<6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <3E4F467C-0634-4566-9248-CC1D1F79EC64@darko.org>

Here is the Cairo API done in M3 and I have a few others. I'd like to promote this style of naming, where prefixes matching the interface name are removed, so CairoSave in C becomes Cairo.Save in M3.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cairo.i3
Type: application/octet-stream
Size: 21401 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/51166a02/attachment-0002.obj>
-------------- next part --------------



On 24/01/2010, at 9:02 AM, Chris wrote:

On Sat, 23 Jan 2010 12:17:07 +0100
Daniel Solaz <m3 at sol42.com> wrote:

> I think the only way to go is a single Modula-3 API that wraps the native toolkit on each platform, sort of like wxwidgets.  Where there is no single native toolkit, choose the best or most used.  Portability, full interoperability and looking/feeling native are the key points here.
> 
> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has spent years and billions in Swing, and it still sucks in a different way every platform it works on.  Worst of all (for me at least) is how it incorrectly and incompletely mimics the native look and feel, mainly Motif and GTK, but Mac OS X too; on Windows it looks way better but is still far from perfect.  SWT is a bit more difficult to use, and not available (yet?) on every platform, but to me it is the right way to go.
> 
> Making Trestle look good will only get us so far.  I haven't looked at it for years, but unless it has changed quite a bit it would require rewriting significant parts.  Text handling comes to mind, and scrollbars too.
> 
> Regards.
> -Daniel

Good points.

I think your correct that creating bindings to some toolkits are the way to go, for now. Of course the lower level X and OpenGL bindings will still need to be upgraded, just so that thier available for those who want to use them.(I know I will.)

Right now, as far as toolkits go, I'm looking at bindings to Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are good. Maybe bindings to Clutter(http://clutter-project.org/) and Amanith(http://www.amanith.org/) would be useful.

So, bindings are the way to start at least. Alright then. Time to get hacking.
-- 
Chris <Highjinks at gmx.com>


From hosking at cs.purdue.edu  Sun Jan 24 10:23:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:23:29 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
References: <COL101-W62B9D3B6552D47B48BBA22E6640@phx.gbl>, ,
	<49542.12.46.67.162.1264190197.squirrel@admintool.trueband.net>,
	<COL101-W45AEB8AFCE53C37A9A2C04E6620@phx.gbl>,
	<F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
Message-ID: <6F19D0A2-AAE4-4268-AACE-7F24E348A122@cs.purdue.edu>

I still don't understand what is broken here...

On 23 Jan 2010, at 14:30, Jay K wrote:

> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>   ie: on one's complement?
>  
>  
> I already disallow it in some code -- depending on which code gets
> hit in the backend. But this disallowing is new.
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Subject: RE: [M3devel] the meaning of -FIRST(INTEGER)?
> Date: Sat, 23 Jan 2010 05:00:34 +0000
> 
> Sorry, not literals.
>  
> How do I write correct portable code to test if a Word is greater than -FIRST(INTEGER)?
>  
> How do I express -FIRST(INTEGER)? Without incurring signed overflow
> while evaluating the constant expression?
>  
> For a one's complement system, nothing wrong with -FIRST(INTEGER).
>   It equals LAST(INTEGER).
>  
> But for a two's complement system, evaluating -FIRST(INTEGER)
>  incurs overflow.
>  
> Maybe:
>  Word.Add(-(FIRST(INTEGER) + 1)), 1)
>  
> ?
>  
> Probably. I'll try that.
>  
> You know, C has the same dilemna and similar solution.
> not a great idea to write
> unsigned u = (unsigned)-INT_MIN;
>  
> nor
>  
> unsigned u = -(unsigned)INT_MIN;
>  
> though the second is maybe ok.
> The first incurs signed overflow in C as well.
> Which isn't defined. The first also gets a warning
> with some compilers: "negating unsigned is still unsigned".
>  
> An idiom is
> unsigned u = ((unsigned)-(INT_MIN + 1)) + 1;
>  
> derivation:
> INT_MIN + 1 yields a negative number that can be safely negated.
> Which yields a positive number one less than the desired value.
>  
>  
>  - Jay
> 
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 18:52:05 -0500
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.
> 
> Literals:
> 
> If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.
> 
> Constant expressions:
> 
> CONST x = Word.Plus(16_FFFF, 1)
> 
> 
> On 22 Jan 2010, at 17:51, Jay K wrote:
> 
> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation of signed integers.
> 
> 
> Can we maybe add Word.AbsoluteValueOfInteger?
> The implementation would, roughly:
>   IF i < 0 THEN 
>     i := -i;
>   END;
>   RETURN i;
>   END;
> 
> with the extra qualification that overflow is silent
> 
> 
>  > But surely, we could agree that compile time
>  > arithmetic should do the same thing as runtime would, for a given
>  > implementation.
> 
> Uh huh. This is why you need *different types* (or interfaces)
> for the variety of integer overflow behavior and not a runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would be omitted. If using "integer-with-overflow"
> the code would be included.
> 
> 
> I introduce the error. It used to be silent.
> I changed it to a warning, for the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, will still error.
> 
>  - Jay
> 
> 
> > Date: Fri, 22 Jan 2010 19:56:37 +0000
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> > 
> > >
> > > So..I have m3back using Target.Int a bunch.
> > >
> > > And converting back and forth some between Target.Int and
> > >
> > > INTEGER and doing match with Target.Int.
> > >
> > > And various operations can fail.
> > >
> > >
> > >
> > >
> > >
> > > And my current diff results in:
> > >
> > >
> > >
> > >
> > >
> > > new source -> compiling Lex.m3
> > > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> > > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> > > 2 errors encountered
> > > new source -> compiling Scan.i3
> > >
> > >
> > >
> > >
> > >
> > > which is nice to see, it means my code is actually running.
> > >
> > >
> > >
> > >
> > >
> > > So I look at the code in question:
> > >
> > >
> > >
> > >
> > >
> > > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > > Word.T
> > > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > > ...
> > >
> > > IF signed AND
> > > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> > > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> > > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > > ....
> > >
> > >
> > >
> > >
> > >
> > > -FIRST(INTEGER).
> > >
> > >
> > >
> > >
> > >
> > > What is that supposed to do?
> > >
> > >
> > >
> > >
> > >
> > > I mean, I kind of know, I'm slightly playing stupid, partly not.
> > >
> > > Does the compiler know what is an INTEGER vs. what is a "Word"?
> > ---------------------------------------------------------Word.T?
> > 
> > No, they are the same type.
> > 
> > > Or it is just obligated to assume everything is a Word?
> > 
> > It is obligated to do the builtin operators (unary - being one
> > of these) using signed interpretation of the value and functions
> > in Word using unsigned interpretation.
> > 
> > The signed operators don't assume anything about the machine
> > representation. The functions in Word do assume two-s complement
> > binary, in order to be defined. This is a low-level facility.
> > 
> > > To do the negation at compile time and ignore the overflow?
> > 
> > This may be poorly specified. The code sample you cite clearly assumes
> > this is what it does. The compile errors indicate the assumption
> > has become wrong.
> > 
> > > Does the language need work here?
> > 
> > Overflow detection wars! But surely, we could agree that compile time
> > arithmetic should do the same thing as runtime would, for a given
> > implementation.
> > 
> > > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> > 
> > Yes, it's a statically unconditional overflow, and the language doesn't
> > specify what happens.
> > 
> > As long as we are assuming two-s complement binary, I would just remove
> > the - in front of FIRST(INTEGER). If the compiler does not consider it
> > and overflow error and wraps around, in this particular case, the - is
> > an identity operation on the bits. Maybe the writer intended the -
> > to hint to a human reader that unsigned interpretation is about to be
> > applied to this value.
> > 
> > >
> > >
> > >
> > >
> > > - Jay
> > >
> > >
> > >
> > 
> > 
> 
> 

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

From hosking at cs.purdue.edu  Sun Jan 24 10:24:05 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:24:05 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100123221335.GC6033@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
Message-ID: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>

Agreed.  If we allow overflow at run-time we should at compile-time.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 17:13, hendrik at topoi.pooq.com wrote:

> On Sat, Jan 23, 2010 at 07:30:33PM +0000, Jay K wrote:
>> 
>> Once I fix Lex.m3, should we continue to allow -FIRST(INTEGER) or not?
>> 
>> As well, should we go the extra bit and disallow it even if it doesn't overflow?
>>  ie: on one's complement?
> 
> The only reason for disallowing it is overflow, and then only for an 
> implementation that checks overflow.  But if it doesn't overflow, 
> it doesn't overflow, and it's valid.
> 
> -- hendrik
> 
>> I already disallow it in some code -- depending on which code gets
>> 
>> hit in the backend. But this disallowing is new.
> 
> It might warrant a portability warning, if we issue such.
> 
> -- hendrik

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

From hosking at cs.purdue.edu  Sun Jan 24 10:25:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 04:25:07 -0500
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
	<COL101-W31C3A76F33CC36D056A27FE6610@phx.gbl>
Message-ID: <283D5C6F-607F-47E1-A53A-BFE01EA3018D@cs.purdue.edu>

Yes, I meant the machine stack for LONGINT values.  Regs only for INTEGER.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 23 Jan 2010, at 10:31, Jay K wrote:

>  > You might easily just push/pop operands and return values on the stack
> 
> I don't think I understood you.
> My "worst case" was to store everything in temporaries.
> But I think I see now.
> Some sort of stack is required.
> There is the "virtual stack" already in use. (I assume "v" = "virtual").
>    It should already handle constant folding, but its register manipulation isn't right for 64bit values.
> I think what I see now -- just use the machine stack.
> Even to push immediate values.
> And, to be really lame, most/all operations can be function calls.
>  And not even in the "normal" way, but like:
> 
> 
> #ifdef _WIN32
> 
> 
> void __stdcall m3_add64(__int64 a)
> {
>     (&a)[1] += a;
> }
> 
> 
> void __cdecl m3_neg64(__int64 a)
> {
>     a = -a;
> }
> 
> 
> where we convince the C compiler to do the right stack maintenance.
> We'd just generate parameter-less calls.
> For actually passing longint parameters to real Modula-3 functions,
> I'd have to look, but, like, pop_param would do nothing.
> 
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] thoughts on NT386/LONGINT?
> Date: Fri, 22 Jan 2010 22:53:41 +0000
> 
> I'll see what I can figure out.
> 
> 
> I considered pushings pairs of operands in m3x86.m3 but I think
> that won't work.
> 
> 
> Noticing how integer vs. floating point is handled
> is perhaps useful, as this is another way in which m3cg
> is "homogenous" but backends have to act differently
> based on type.
> 
> 
>  - Jay
> 
> 
> 
> From: hosking at cs.purdue.edu
> Date: Fri, 22 Jan 2010 09:49:28 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] thoughts on NT386/LONGINT?
> 
> That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.
> 
> On 22 Jan 2010, at 07:39, Jay K wrote:
> 
> Anyone have any thoughts on how to implement LONGINT on NT386?
>  
> 
> The code is setup to do pretty good constant folding and enregistration.
>  
> 
> I did the work so that constant folding should work for LONGINT.
>  
> 
> However I think doing good enregistration is maybe still
> too much work. In particular, I think every LONGINT
> operation will do a load, operation, store.
> Typical of unoptimized code, but not typical
> of the Modula-3/NT386 quality.
> 
>  
> In particular, there is still this notion of an "operand"
> that might be held in one register.
> 
>  
> I'd have to make it a register pair, or array of registers,
> or invent "psuedo registers" that are register pairs.
> An array of registers is the obvious best choice, but
> none of these are a small change.
>  
> 
> 96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
> would probably all have to change.
> 63 in Codex86.m3 unsure.
>  It is the lowest level and might need to only deal with single
>   registers.
> 
>  
> Returning LONGINT from a function also needs separate attention.
> Maybe I really should go ahead and use an array of registers?
>  
> 
>  - Jay
> 
> 
> 

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

From dmuysers at hotmail.com  Sun Jan 24 10:32:13 2010
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Sun, 24 Jan 2010 10:32:13 +0100
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>
	<20100123180535.9ee26d0e.Highjinks@gmx.com>
Message-ID: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>

What about IUP ?
It's the one with the narrowest interface...

--------------------------------------------------
From: "Chris" <Highjinks at gmx.com>
Sent: Saturday, January 23, 2010 11:02 PM
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] On Trestle, OpenGL, etc...

> On Sat, 23 Jan 2010 12:17:07 +0100
> Daniel Solaz <m3 at sol42.com> wrote:
>
>> I think the only way to go is a single Modula-3 API that wraps the native 
>> toolkit on each platform, sort of like wxwidgets.  Where there is no 
>> single native toolkit, choose the best or most used.  Portability, full 
>> interoperability and looking/feeling native are the key points here.
>>
>> Developing a new toolkit in pure Modula-3 is a waste of effort.  Sun has 
>> spent years and billions in Swing, and it still sucks in a different way 
>> every platform it works on.  Worst of all (for me at least) is how it 
>> incorrectly and incompletely mimics the native look and feel, mainly 
>> Motif and GTK, but Mac OS X too; on Windows it looks way better but is 
>> still far from perfect.  SWT is a bit more difficult to use, and not 
>> available (yet?) on every platform, but to me it is the right way to go.
>>
>> Making Trestle look good will only get us so far.  I haven't looked at it 
>> for years, but unless it has changed quite a bit it would require 
>> rewriting significant parts.  Text handling comes to mind, and scrollbars 
>> too.
>>
>> Regards.
>> -Daniel
>
> Good points.
>
> I think your correct that creating bindings to some toolkits are the way 
> to go, for now. Of course the lower level X and OpenGL bindings will still 
> need to be upgraded, just so that thier available for those who want to 
> use them.(I know I will.)
>
> Right now, as far as toolkits go, I'm looking at bindings to 
> Cairo/Pango/Glitz. Maybe an SDL binding. Full GTK and QT bindings are 
> good. Maybe bindings to Clutter(http://clutter-project.org/) and 
> Amanith(http://www.amanith.org/) would be useful.
>
> So, bindings are the way to start at least. Alright then. Time to get 
> hacking.
> -- 
> Chris <Highjinks at gmx.com>
> 


From jay.krell at cornell.edu  Sun Jan 24 12:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 11:13:07 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100122171259.f8cdc16c.Highjinks@gmx.com><6769F5FF-8DFC-4CC2-B212-A0FB55DEB6B8@sol42.com>,
	<20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <COL101-W19EFB4F971A68D816BA2D9E6600@phx.gbl>


I had never heard of it. Looks good.

 

 - Jay
 
> From: dmuysers@
> To: Highjinks@; m3devel@
> Date: Sun, 24 Jan 2010 10:32:13 +0100
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> What about IUP ?
> It's the one with the narrowest interface...
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/f570b384/attachment-0002.html>

From hendrik at topoi.pooq.com  Sun Jan 24 14:00:33 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:00:33 -0500
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>
Message-ID: <20100124130032.GA27093@topoi.pooq.com>

On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> What about IUP ?
> It's the one with the narrowest interface...

Does it run on OS X?  With or without X?

-- hendrik


From hendrik at topoi.pooq.com  Sun Jan 24 14:16:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 24 Jan 2010 08:16:51 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
Message-ID: <20100124131650.GB16928@topoi.pooq.com>

On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> Agreed.  If we allow overflow at run-time we should at compile-time.

But perhaps a compile-time warning is in order for overflow -- in cases 
where we do the arithmetic at compile-time, anyway.  We may avoid 
run-time checks for speed reasons, but there's no such constraint 
on compile-time checks.

-- hendrik


From jay.krell at cornell.edu  Sun Jan 24 14:50:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Jan 2010 13:50:17 +0000
Subject: [M3devel] On Trestle, OpenGL, etc...
In-Reply-To: <20100124130032.GA27093@topoi.pooq.com>
References: <20100123180535.9ee26d0e.Highjinks@gmx.com>,
	<SNT109-DS571D84D68C9F396C73D00DD600@phx.gbl>,
	<20100124130032.GA27093@topoi.pooq.com>
Message-ID: <COL101-W14D28108FC156C65A1F4BDE6600@phx.gbl>


Mac support unclear.

That's maybe a reason to favor e.g. Qt, Tk, wxWidgets.

 

http://www.tecgraf.puc-rio.br/iup/

http://www.tecgraf.puc-rio.br/iup/en/to_do.html

 

They don't clearly list that they have any currently, but they

do list that they want to..even using Carbon (not sure

Carbon is viable going forward, to AMD64_DARWIN).

 

 - Jay

 
> Date: Sun, 24 Jan 2010 08:00:33 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] On Trestle, OpenGL, etc...
> 
> On Sun, Jan 24, 2010 at 10:32:13AM +0100, Dirk Muysers wrote:
> > What about IUP ?
> > It's the one with the narrowest interface...
> 
> Does it run on OS X? With or without X?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100124/b40de143/attachment-0002.html>

From hosking at cs.purdue.edu  Sun Jan 24 23:38:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 24 Jan 2010 17:38:30 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <20100124131650.GB16928@topoi.pooq.com>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
Message-ID: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>

But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:

> On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
>> Agreed.  If we allow overflow at run-time we should at compile-time.
> 
> But perhaps a compile-time warning is in order for overflow -- in cases 
> where we do the arithmetic at compile-time, anyway.  We may avoid 
> run-time checks for speed reasons, but there's no such constraint 
> on compile-time checks.
> 
> -- hendrik

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

From jay.krell at cornell.edu  Mon Jan 25 12:14:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Jan 2010 11:14:57 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W41670ACD92514D9933EF99E65F0@phx.gbl>


 >> I think what I see now -- just use the machine stack.


I'm not sure this works so easily if you consider function calls.

  Taking a mix of LONGINT and non-LONGINT parameters.

 

There'd be a series of load_integer and pop_param calls.

Normally all the machine stack pushes are in pop_param.

Now they'd be in a mix of load_integer and pop_param.

If pop_param is called as each parameter is computed, ok.

If they are all computed and then all popped, not ok.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out.




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From jay.krell at cornell.edu  Tue Jan 26 13:15:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 12:15:21 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W25B5537DA495533A5E563EE65E0@phx.gbl>


I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.

 

In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.

And also double (LONGFLOAT, whatever).

 

This would help with atomic compare exchange on 64 bit values on x86.

It would probably let us drop the m3cg x86 -mno-align-double switch.

  That would have saved me quite some debugging time a while ago....

Not sure about -munaligned-doubles though on Linux/sparc.

 

I'd have to check what the language allows, but if there is "adequate" and

"ideal" alignment, then users should maybe be able to ask for "adequate"

if they have large arrays and want to optimize for memory.

 

Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.

Though max_align doesn't appear to be applied to jmpbufs.

 

Notice that the language doesn't let you declare such high alignment.

 

- Jay

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

From jay.krell at cornell.edu  Tue Jan 26 14:04:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:04:38 +0000
Subject: [M3devel] doextract_mn, doextract_n, insert_mn, insert_n
Message-ID: <COL101-W350F45564A26EDD4ADECADE65E0@phx.gbl>


doextract_mn, doextract_n, insert_mn, insert_n

 


We don't *really* need any of these in M3CG.i3.
They make it easier for the backend to optimize,
but the integrated backend *always* optimizes
as well as these allow for.

 


I noticed in the frontend that its helper function Insert_mn (capital I)
is never used, because GenInsert.mg fails to do the
optimizations that GenExtract.mg does.

 


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

From jay.krell at cornell.edu  Tue Jan 26 14:21:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 26 Jan 2010 13:21:44 +0000
Subject: [M3devel] max_align
Message-ID: <COL101-W344C1DE585165E3C53E644E65E0@phx.gbl>


Visual C++/x86:

 

 

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(__int64));
 return 0;
}

gcc/Linux/x86:

#include <stdio.h>

int main()
{
 printf("%u %u\n", __alignof(double), __alignof(long long));
 return 0;
}

 

 

both print "8 8".

 

 

Fixing this would break some pickles that contain LONGINT and/or LONGREAL, depending on if they needed padding to align.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: max_align
Date: Tue, 26 Jan 2010 12:15:21 +0000



I kind of think max_align ought to left up at 64 for all platforms, or better yet, just removed.
 
In particular, this align LONGINT on 64bit boundaries on 32bit x86 systems.
And also double (LONGFLOAT, whatever).
 
This would help with atomic compare exchange on 64 bit values on x86.
It would probably let us drop the m3cg x86 -mno-align-double switch.
  That would have saved me quite some debugging time a while ago....
Not sure about -munaligned-doubles though on Linux/sparc.
 
I'd have to check what the language allows, but if there is "adequate" and
"ideal" alignment, then users should maybe be able to ask for "adequate"
if they have large arrays and want to optimize for memory.
 
Note that some platforms (PA64_HPUX, PPC_LINUX) have 128bit-aligned jmpbuf.
Though max_align doesn't appear to be applied to jmpbufs.
 
Notice that the language doesn't let you declare such high alignment.
 
- Jay

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

From jay.krell at cornell.edu  Wed Jan 27 15:01:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 14:01:04 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
Message-ID: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>


MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.

 

 

 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked


 

 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.



 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100127/383d90a1/attachment-0002.html>

From hosking at cs.purdue.edu  Wed Jan 27 16:57:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 10:57:09 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
Message-ID: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>

If we declare it as a 32-bit subrange it should just work, right?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 27 Jan 2010, at 09:01, Jay K wrote:

> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>   the closure marker being a 4 byte -1 instead of an INTEGER.
>  
>  
>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
> 
>  
>  That is, we should probably make their be a per-target variable "closure marker size"
>   that is 4 for all current targets (IA64 should probably be 16 though),
>   though one would have to look into the various instruction encodings.
> 
> 
>  - Jay

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

From jay.krell at cornell.edu  Wed Jan 27 17:17:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Jan 2010 16:17:50 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>


yes, but I think it is target-specific. IA64 would use 16 bytes.

It isn't even in library code, but generated code.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 27 Jan 2010 10:57:09 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"

If we declare it as a 32-bit subrange it should just work, right?




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 27 Jan 2010, at 09:01, Jay K wrote:

MIPS64, SPARC64 and maybe others could probably all benefit slightly from
  the closure marker being a 4 byte -1 instead of an INTEGER.
 
 
 That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked

 
 That is, we should probably make their be a per-target variable "closure marker size"
  that is 4 for all current targets (IA64 should probably be 16 though),
  though one would have to look into the various instruction encodings.


 - Jay

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

From hosking at cs.purdue.edu  Wed Jan 27 17:19:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 27 Jan 2010 11:19:54 -0500
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
Message-ID: <EE6487AA-9BA1-4D9A-BFCA-053FC6B8487C@cs.purdue.edu>

Sorry.  Just realised this is deeply embedded in the Target files.


On 27 Jan 2010, at 10:57, Tony Hosking wrote:

> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly from
>>   the closure marker being a 4 byte -1 instead of an INTEGER.
>>  
>>  
>>  That is: 64bit architectures with a fixed size 4 byte instruction where alignment is checked
>> 
>>  
>>  That is, we should probably make their be a per-target variable "closure marker size"
>>   that is 4 for all current targets (IA64 should probably be 16 though),
>>   though one would have to look into the various instruction encodings.
>> 
>> 
>>  - Jay
> 

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

From rodney_bates at lcwb.coop  Wed Jan 27 23:19:21 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 27 Jan 2010 16:19:21 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
Message-ID: <4B60BBE9.7020401@lcwb.coop>

Before anybody fiddles with closure markers, *please* do *both* the following:

1)  Let me know.  M3gdb needs to both recognize and construct closures
     (and it currently does.)  Changing them will break it, unless it is
     modified accordingly.

2)  Make sure there is some reasonable way m3gdb can tell by looking at
     the object code being debugged, whether it was generated by a
     compiler version that uses the old or the new closure marker
     representation.

I have worked hard to make m3gdb able to adapt to the various compilers
and versions, but periodically I get undermined on 1) and/or 2) above
by some quiet change somebody makes without thinking about m3gdb.

Also, think about the implications on linking together code produced
by different compiler versions.  I am quite sure changing the closure
representation would mean *all* linked-in libraries would have to be
recompiled, along with the main program, by the same compiler version.

Right now, closure markers are always the same size as pointers, and I think
there are multiple places in the compiler and runtime, in addition to m3gdb,
that rely on this.  They would all have to be located and fixed.  And I
don't think they all key off any single declaration, e.g. closure_marker_size.

Jay K wrote:
> yes, but I think it is target-specific. IA64 would use 16 bytes.
> It isn't even in library code, but generated code.
>  
>  - Jay
> 
>  
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 27 Jan 2010 10:57:09 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
> 
> If we declare it as a 32-bit subrange it should just work, right?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 27 Jan 2010, at 09:01, Jay K wrote:
> 
>     MIPS64, SPARC64 and maybe others could probably all benefit slightly
>     from
>       the closure marker being a 4 byte -1 instead of an INTEGER.
>      
>      
>      That is: 64bit architectures with a fixed size 4 byte instruction
>     where alignment is checked
> 
>      
>      That is, we should probably make their be a per-target variable
>     "closure marker size"
>       that is 4 for all current targets (IA64 should probably be 16 though),
>       though one would have to look into the various instruction encodings.
> 
> 
>      - Jay
> 
> 


From jay.krell at cornell.edu  Thu Jan 28 02:30:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 28 Jan 2010 01:30:21 +0000
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>, ,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>,
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>,
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <COL101-W28BF8C4DD648F3633CB288E65C0@phx.gbl>


Thanks, understood.
No "mainstream" target would be affected -- no x86 target (32bit or 64bit), probably not any 32bit target.
 
 
For IA64 either we we probably want a 128 bit marker, since that is the instruction size, sort of (multiple instructions packed into 128 bit chunks).
 
 
Basically any architecture that has a fixed size 4 byte instruction, 4 byte aligned instructions, where alignment is checked, where pointer is 8 bytes, would be a little more efficient with a 4 byte marker instead of an 8 byte marker. Like, probably any MIPS64 or SPARC64 platform, and maybe some others (HPPA, Alpha, PPC64). Not any x86 or AMD64 though.
 
 
The closure would be smaller and the alignment would naturally be ok. Currently such architectures have to fiddle around with the pointer since it might not be 8 byte aligned. Any call through a function pointer would save a few instructions.
 
 
Really what bugs me most about this area is the time I have wasted in the past learning about it bringing up new platforms!
 
 
It bugs me otherwise -- the assumption that -1 is invalid code. The lack of a good solution here in general -- gcc has nested functions, but it doesn't do it in a good way either -- they generate code on the stack, on some platforms use mprotect to make the page executable, and on some platforms just fail completely (I think iPhone for example).
 
 
I suppose another improvement would be to make the value (-1) configurable per target. I haven't gone to the trouble of disasm'ing -1 on various platforms yet. Probably it is ok. It doesn't even have to be invalid, it just has to not to be the first instruction of a function.
 
 
 - Jay


----------------------------------------
> Date: Wed, 27 Jan 2010 16:19:21 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>
> Before anybody fiddles with closure markers, *please* do *both* the following:
>
> 1) Let me know. M3gdb needs to both recognize and construct closures
> (and it currently does.) Changing them will break it, unless it is
> modified accordingly.
>
> 2) Make sure there is some reasonable way m3gdb can tell by looking at
> the object code being debugged, whether it was generated by a
> compiler version that uses the old or the new closure marker
> representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions. I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this. They would all have to be located and fixed. And I
> don't think they all key off any single declaration, e.g. closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>
>> - Jay
>>
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly
>> from
>> the closure marker being a 4 byte -1 instead of an INTEGER.
>>
>>
>> That is: 64bit architectures with a fixed size 4 byte instruction
>> where alignment is checked
>>
>>
>> That is, we should probably make their be a per-target variable
>> "closure marker size"
>> that is 4 for all current targets (IA64 should probably be 16 though),
>> though one would have to look into the various instruction encodings.
>>
>>
>> - Jay
>>
>> 		 	   		  

From wagner at elegosoft.com  Thu Jan 28 11:31:56 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 28 Jan 2010 11:31:56 +0100
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <4B60BBE9.7020401@lcwb.coop>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>
	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>
	<4B60BBE9.7020401@lcwb.coop>
Message-ID: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>

Shouldn't we insert a short version of this warning into the source
code? Or is there no central location where it could be placed and
will be noticed?

This is a non-obvious dependency, and though Jay and Tony will remember
now, there may be others in a few years who don't.

Olaf

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Before anybody fiddles with closure markers, *please* do *both* the   
> following:
>
> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>     (and it currently does.)  Changing them will break it, unless it is
>     modified accordingly.
>
> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>     the object code being debugged, whether it was generated by a
>     compiler version that uses the old or the new closure marker
>     representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions.  I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this.  They would all have to be located and fixed.  And I
> don't think they all key off any single declaration, e.g.   
> closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>  - Jay
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>    from
>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>               That is: 64bit architectures with a fixed size 4 byte  
>>  instruction
>>    where alignment is checked
>>
>>          That is, we should probably make their be a per-target variable
>>    "closure marker size"
>>      that is 4 for all current targets (IA64 should probably be 16 though),
>>      though one would have to look into the various instruction encodings.
>>
>>
>>     - Jay
>>
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Jan 28 17:55:53 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 28 Jan 2010 10:55:53 -0600
Subject: [M3devel] aligned_procedures: suggest "closure_marker_size"
In-Reply-To: <20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
References: <COL101-W6529A479E12E435F2A849E65D0@phx.gbl>,
	<674433D5-0B04-41D2-988A-8BE8A7804F78@cs.purdue.edu>	<COL101-W971CB87ABFCEDA258E6A2E65D0@phx.gbl>	<4B60BBE9.7020401@lcwb.coop>
	<20100128113156.odjzzu17okkgoo88@mail.elegosoft.com>
Message-ID: <4B61C199.2040000@lcwb.coop>

Well, there are many aspects of the runtime organization that affect
m3gdb, and I am afraid they are scattered far and wide in the source
code, so it might be hard to do this systematically.  I have, on
one or two occasions in the past, put a comment in the compiler
or runtime source code, regarding some specific matter that affects
m3gdb.

Maybe I'll look for a good place to note about closure markers.

Olaf Wagner wrote:
> Shouldn't we insert a short version of this warning into the source
> code? Or is there no central location where it could be placed and
> will be noticed?
> 
> This is a non-obvious dependency, and though Jay and Tony will remember
> now, there may be others in a few years who don't.
> 
> Olaf
> 
> Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:
> 
>> Before anybody fiddles with closure markers, *please* do *both* the  
>> following:
>>
>> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>>     (and it currently does.)  Changing them will break it, unless it is
>>     modified accordingly.
>>
>> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>>     the object code being debugged, whether it was generated by a
>>     compiler version that uses the old or the new closure marker
>>     representation.
>>
>> I have worked hard to make m3gdb able to adapt to the various compilers
>> and versions, but periodically I get undermined on 1) and/or 2) above
>> by some quiet change somebody makes without thinking about m3gdb.
>>
>> Also, think about the implications on linking together code produced
>> by different compiler versions.  I am quite sure changing the closure
>> representation would mean *all* linked-in libraries would have to be
>> recompiled, along with the main program, by the same compiler version.
>>
>> Right now, closure markers are always the same size as pointers, and I 
>> think
>> there are multiple places in the compiler and runtime, in addition to 
>> m3gdb,
>> that rely on this.  They would all have to be located and fixed.  And I
>> don't think they all key off any single declaration, e.g.  
>> closure_marker_size.
>>
>> Jay K wrote:
>>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>>> It isn't even in library code, but generated code.
>>>  - Jay
>>>
>>> ------------------------------------------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>>
>>> If we declare it as a 32-bit subrange it should just work, right?
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>>
>>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>>    from
>>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>>               That is: 64bit architectures with a fixed size 4 byte 
>>>  instruction
>>>    where alignment is checked
>>>
>>>          That is, we should probably make their be a per-target variable
>>>    "closure marker size"
>>>      that is 4 for all current targets (IA64 should probably be 16 
>>> though),
>>>      though one would have to look into the various instruction 
>>> encodings.
>>>
>>>
>>>     - Jay
>>>
>>>
> 
> 
> 


From Highjinks at gmx.com  Fri Jan 29 00:23:55 2010
From: Highjinks at gmx.com (Chris)
Date: Fri, 29 Jan 2010 00:23:55 +0100 (CET)
Subject: [M3devel] Which libraries to use?
Message-ID: <20100128192638.03b7590e.Highjinks@gmx.com>

Or better yet, should I just write my own.

Getting started writing bindings from the header files in ../include/X11/extensions

However, some of those depend on ../include/X11/Xmd.h and ../include/X11/Xfuncproto.h

Writing bindings for these probably shouldn't be necessary. However, I just want to make sure.

Does anyone forsee a problem if I just stick the values defined in the CM3 libs?
 
It's also looking fairly certain that I'm going to break off Xlib and XUtil into thier own .i3 files.

-- 
Chris <Highjinks at gmx.com>


From jay.krell at cornell.edu  Fri Jan 29 11:09:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 10:09:46 +0000
Subject: [M3devel] thoughts on NT386/LONGINT?
In-Reply-To: <52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
References: <COL101-W5787E3ECA5805F30FA5650E6620@phx.gbl>,
	<52F6DF97-DC72-42A5-984E-9F7807E8669E@cs.purdue.edu>
Message-ID: <COL101-W35838671ED7CF50D3D70D5E65B0@phx.gbl>


So I looked again -- how is floating point dealt with?
Well, it has its own stack. That helps here (even if it is otherwise lame).

 

 

The "easy" way would be to have M3x86.m3 

do stuff "directly", but each function would have

a little local array of __int64 that push/pop/add/sub/mult

used. It would be very inefficient but would work.

Passing parameters would pop from the local array

and push onto the machine stack. 

 

 

You can see this approach if you watch the

talk on the "XMLVM" where they implement Java for iPhone.

They disassemble .class files into a direct xml representation,

then use XSL style sheets to translate to Objective-C,

or JavaScript, or almost anything.

They give each function a little array to model the Java VM stack.

 

 

I'm still spinning on an efficient approach.

I can actually generate a *little* bit of correct reasonable

code, but not much yet.

Just 64bit moves of constants into variables.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Mon, 25 Jan 2010 11:14:57 +0000



 >> I think what I see now -- just use the machine stack.

I'm not sure this works so easily if you consider function calls.
  Taking a mix of LONGINT and non-LONGINT parameters.
 
There'd be a series of load_integer and pop_param calls.
Normally all the machine stack pushes are in pop_param.
Now they'd be in a mix of load_integer and pop_param.
If pop_param is called as each parameter is computed, ok.
If they are all computed and then all popped, not ok.
 
 
 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Sat, 23 Jan 2010 15:31:38 +0000



 > You might easily just push/pop operands and return values on the stack

I don't think I understood you.
My "worst case" was to store everything in temporaries.
But I think I see now.
Some sort of stack is required.
There is the "virtual stack" already in use. (I assume "v" = "virtual").
   It should already handle constant folding, but its register manipulation isn't right for 64bit values.
I think what I see now -- just use the machine stack.
Even to push immediate values.
And, to be really lame, most/all operations can be function calls.
 And not even in the "normal" way, but like:


#ifdef _WIN32


void __stdcall m3_add64(__int64 a)
{
    (&a)[1] += a;
}


void __cdecl m3_neg64(__int64 a)
{
    a = -a;
}


where we convince the C compiler to do the right stack maintenance.
We'd just generate parameter-less calls.
For actually passing longint parameters to real Modula-3 functions,
I'd have to look, but, like, pop_param would do nothing.


 - Jay




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] thoughts on NT386/LONGINT?
Date: Fri, 22 Jan 2010 22:53:41 +0000



I'll see what I can figure out. 




I considered pushings pairs of operands in m3x86.m3 but I think
that won't work.




Noticing how integer vs. floating point is handled
is perhaps useful, as this is another way in which m3cg
is "homogenous" but backends have to act differently
based on type.




 - Jay





From: hosking at cs.purdue.edu
Date: Fri, 22 Jan 2010 09:49:28 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thoughts on NT386/LONGINT?


That's a very good question.  I suspect allocating register pairs as needed would make for a fairly difficult implementation.  I would err on the side of simplicity for LONGINT code generation rather than complexity.  You might easily just push/pop operands and return values on the stack, on the grounds that modern x86 hardware will do a good job renaming stack locations to registers.  i.e., worry about correctness first and performance later.



On 22 Jan 2010, at 07:39, Jay K wrote:

Anyone have any thoughts on how to implement LONGINT on NT386?
 

The code is setup to do pretty good constant folding and enregistration.
 

I did the work so that constant folding should work for LONGINT.
 

However I think doing good enregistration is maybe still
too much work. In particular, I think every LONGINT
operation will do a load, operation, store.
Typical of unoptimized code, but not typical
of the Modula-3/NT386 quality.


 
In particular, there is still this notion of an "operand"
that might be held in one register.

 
I'd have to make it a register pair, or array of registers,
or invent "psuedo registers" that are register pairs.
An array of registers is the obvious best choice, but
none of these are a small change.
 

96 occurences of "reg" in Stackx86.m3, 58 in M3x86.m3,
would probably all have to change.
63 in Codex86.m3 unsure.
 It is the lowest level and might need to only deal with single
  registers.

 
Returning LONGINT from a function also needs separate attention.
Maybe I really should go ahead and use an array of registers?
 

 - Jay


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

From hendrik at topoi.pooq.com  Fri Jan 29 15:32:50 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 29 Jan 2010 09:32:50 -0500
Subject: [M3devel] the meaning of -FIRST(INTEGER)?
In-Reply-To: <2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
References: <F5FE5A77-C7C1-411E-8059-0F0D2A433609@cs.purdue.edu>
	<COL101-W15160A52C22CCAA5071C1AE6610@phx.gbl>
	<20100123221335.GC6033@topoi.pooq.com>
	<DFC3C653-211A-4646-B1C4-82259BCC079A@cs.purdue.edu>
	<20100124131650.GB16928@topoi.pooq.com>
	<2C6C78C0-6A40-4603-926D-0BE252B79A26@cs.purdue.edu>
Message-ID: <20100129143250.GA9515@topoi.pooq.com>

On Sun, Jan 24, 2010 at 05:38:30PM -0500, Tony Hosking wrote:
> But a given implementation (as in all of the implementations we currently support) can assume integer overflow is OK and also a 2-s complement representation.  What's the problem?

If the compiler can determine statically that an overflow will happen, 
and the overflow cause incorrect behaviour of the program, it just 
might be helpful to inform him.

But I wouldn't go so far as to say it's a problem.  It would be a 
problem for him to be unable to get overflow checking even if he's 
willing to pay the run-time cost.  But that wasn't what I was talking 
about.

-- hendrik

> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 24 Jan 2010, at 08:16, hendrik at topoi.pooq.com wrote:
> 
> > On Sun, Jan 24, 2010 at 04:24:05AM -0500, Tony Hosking wrote:
> >> Agreed.  If we allow overflow at run-time we should at compile-time.
> > 
> > But perhaps a compile-time warning is in order for overflow -- in cases 
> > where we do the arithmetic at compile-time, anyway.  We may avoid 
> > run-time checks for speed reasons, but there's no such constraint 
> > on compile-time checks.
> > 
> > -- hendrik
> 


From hosking at cs.purdue.edu  Fri Jan 29 18:40:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 29 Jan 2010 12:40:51 -0500
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
Message-ID: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>

Note that the front-end refuses to do any constant folding that results in overflow.  Instead, it generates code that will execute at run-time.  If that causes a run-time error then fine.  Similarly, the back-end should never do constant folding for things that overflow.


On 29 Jan 2010, at 11:48, Jay K wrote:

> For now I'm treating the error as a warning and continuing on.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 29 Jan 2010 10:31:35 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Why do you need that?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/01/29 09:57:33
> 
> Modified files:
> cm3/m3-sys/m3middle/src/: Target.m3 
> 
> Log message:
> in ToInt and IntI, do the conversion even if there is overflow (still returning FALSE for overflow)
> 
> 

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

From rodney_bates at lcwb.coop  Fri Jan 29 19:11:39 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 29 Jan 2010 12:11:39 -0600
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
References: <20100129085733.63129CC308@birch.elegosoft.com>,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>
Message-ID: <4B6324DB.7040809@lcwb.coop>



Tony Hosking wrote:
> Note that the front-end refuses to do any constant folding that results 
> in overflow.  Instead, it generates code that will execute at run-time. 
>  If that causes a run-time error then fine.  Similarly, the back-end 
> should never do constant folding for things that overflow.

Hmm, I didn't know that.  I think that is a very good idea.  It really
preserves language semantics, while gaining efficiency where possible.


> 
> On 29 Jan 2010, at 11:48, Jay K wrote:
> 
>> For now I'm treating the error as a warning and continuing on.
>>  
>>  - Jay
>>
>>  
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>> Date: Fri, 29 Jan 2010 10:31:35 -0500
>> To: jkrell at elego.de <mailto:jkrell at elego.de>
>> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> Why do you need that?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>> University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 29 Jan 2010, at 09:57, Jay Krell wrote:
>>
>>     CVSROOT: /usr/cvs
>>     Changes by: jkrell at birch. 10/01/29 09:57:33
>>
>>     Modified files:
>>     cm3/m3-sys/m3middle/src/: Target.m3 
>>
>>     Log message:
>>     in ToInt and IntI, do the conversion even if there is overflow
>>     (still returning FALSE for overflow)
>>
>>
>>
> 


From jay.krell at cornell.edu  Fri Jan 29 22:02:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Jan 2010 21:02:01 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <4B6324DB.7040809@lcwb.coop>
References: <20100129085733.63129CC308@birch.elegosoft.com>, ,
	<06B64727-043A-47EC-BFF1-2680AA899A89@cs.purdue.edu>
	<COL101-W61524C05C802B25496C99EE65B0@phx.gbl>,
	<A3573EF3-6CC5-49EB-9895-B4210299D2C5@cs.purdue.edu>,
	<4B6324DB.7040809@lcwb.coop>
Message-ID: <COL101-W63294B6BEEF06B0124FA1E65B0@phx.gbl>


There isn't really overflow here, just having trouble implementing longint.

For example 

  ToInt(FIRST(INTEGER) & MAXU32)) overflows, though it shouldn't matter.

 

 - Jay
 
> Date: Fri, 29 Jan 2010 12:11:39 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> 
> 
> Tony Hosking wrote:
> > Note that the front-end refuses to do any constant folding that results 
> > in overflow. Instead, it generates code that will execute at run-time. 
> > If that causes a run-time error then fine. Similarly, the back-end 
> > should never do constant folding for things that overflow.
> 
> Hmm, I didn't know that. I think that is a very good idea. It really
> preserves language semantics, while gaining efficiency where possible.
> 
> 
> > 
> > On 29 Jan 2010, at 11:48, Jay K wrote:
> > 
> >> For now I'm treating the error as a warning and continuing on.
> >> 
> >> - Jay
> >>
> >> 
> >> ------------------------------------------------------------------------
> >> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >> Date: Fri, 29 Jan 2010 10:31:35 -0500
> >> To: jkrell at elego.de <mailto:jkrell at elego.de>
> >> CC: m3commit at elegosoft.com <mailto:m3commit at elegosoft.com>
> >> Subject: Re: [M3commit] CVS Update: cm3
> >>
> >> Why do you need that?
> >>
> >> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >> University
> >> 305 N. University Street | West Lafayette | IN 47907 | USA
> >> Office +1 765 494 6001 | Mobile +1 765 427 5484
> >>
> >>
> >>
> >>
> >> On 29 Jan 2010, at 09:57, Jay Krell wrote:
> >>
> >> CVSROOT: /usr/cvs
> >> Changes by: jkrell at birch. 10/01/29 09:57:33
> >>
> >> Modified files:
> >> cm3/m3-sys/m3middle/src/: Target.m3 
> >>
> >> Log message:
> >> in ToInt and IntI, do the conversion even if there is overflow
> >> (still returning FALSE for overflow)
> >>
> >>
> >>
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100129/6cdd7e37/attachment-0002.html>

From mbishop at esoteriq.org  Sun Jan 31 01:19:20 2010
From: mbishop at esoteriq.org (Martin Bishop)
Date: Sat, 30 Jan 2010 18:19:20 -0600
Subject: [M3devel] 5.8 Release?
Message-ID: <4B64CC88.6070409@esoteriq.org>

I don't want to be a buzz kill, but it's almost February 2010, and 5.8 
stable is still not out.  Are there still any issues left?  Anything 
that can be ignored until after release?




From hosking at cs.purdue.edu  Sun Jan 31 04:31:18 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 30 Jan 2010 22:31:18 -0500
Subject: [M3devel] 5.8 Release?
In-Reply-To: <4B64CC88.6070409@esoteriq.org>
References: <4B64CC88.6070409@esoteriq.org>
Message-ID: <E67ECCE2-26D3-4496-9417-3BD4494A8904@cs.purdue.edu>

Surely we are close.  What stability issues are there on the release branch?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 30 Jan 2010, at 19:19, Martin Bishop wrote:

> I don't want to be a buzz kill, but it's almost February 2010, and 5.8 stable is still not out.  Are there still any issues left?  Anything that can be ignored until after release?
> 

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

From jay.krell at cornell.edu  Sun Jan 31 13:21:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:21:19 +0000
Subject: [M3devel] platform-independent packing/alignment?
Message-ID: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>


These are more potential ABI breaking changes.

Not sure if they'd break pickles or not.

 

 

I suggest we can probably get by with platform-independent packing/alignment settings.

Align everything by its size, up to 8. ?

That is increased alignment for LONGINT and LONGFLOAT on some systems.

  Which they probably should have been in the first place.

It would also increase alignment for obsolete M68K platforms.

 

 

I also suggest we need pragmas to declare something is packed/aligned

differently. But that might be avoided via C layers.

 

 

See, in mklib we have:

 

 

TYPE
  PIMAGE_SYMBOL = <* UNALIGNED *> UNTRACED REF IMAGE_SYMBOL;
  IMAGE_SYMBOL = RECORD
    N: ARRAY [0 .. 7] OF UINT8;
    Value              : UINT32;
    SectionNumber      : INT16;
    Type               : UINT16;
    StorageClass       : UINT8;
    NumberOfAuxSymbols : UINT8;
  END;

 

CONST
    IMAGE_SIZEOF_SYMBOL = 18;


 

But BYTESIZE(IMAGE_SYMBOL) is probably 20 on all platforms (except maybe M68K ones).

 

 

Then Target.Int8, etc. could be constants.

Maybe not worth anything.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100131/6b8cddf1/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jan 31 13:28:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?
Message-ID: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>


I'm seeing:

Just me?

I'll keep digging.

 

== package C:\dev2\cm3.2\m3-libs\m3core ==

 +++ 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

 

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

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

From jay.krell at cornell.edu  Sun Jan 31 13:37:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Jan 2010 12:37:23 +0000
Subject: [M3devel] errors compiling?
In-Reply-To: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
References: <COL101-W176F6CE0BB9739A500A253E6590@phx.gbl>
Message-ID: <COL101-W53FB7810A7679FB145A8E5E6590@phx.gbl>


nevermind, I fixed it

 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 31 Jan 2010 12:28:07 +0000
Subject: [M3devel] errors compiling?



I'm seeing:
Just me?
I'll keep digging.
 
== package C:\dev2\cm3.2\m3-libs\m3core ==
 +++ 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
 
***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\values\Module.m3", line 175
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f768   0x4bb3b4  NewDefn + 0x61 in ..\src\values\Module.m3
 0x12f7d8   0x4c3126  Initialize + 0x66 in ..\NT386\AtomicBoolModule.m3 => ..\sr
c\builtinAtomic\AtomicModule.mg
 0x12f7f8   0x4a8eef  Initialize + 0x182 in ..\src\misc\M3Front.m3
 0x12f828   0x4a89ed  ParseImports + 0x18d in ..\src\misc\M3Front.m3
 0x12f854   0x40ab07  Pass0_CheckImports + 0xc2 in ..\src\Builder.m3
 0x12f8a0   0x40a256  RunM3 + 0x260 in ..\src\Builder.m3
 0x12f8d8   0x408b44  PushOneM3 + 0xf1 in ..\src\Builder.m3
 0x12f908   0x408a2a  CompileM3 + 0x268 in ..\src\Builder.m3
 0x12f944   0x407520  CompileOne + 0x155 in ..\src\Builder.m3
 0x12f97c   0x4071cb  CompileEverything + 0x11e in ..\src\Builder.m3
.........  .........  ... more frames ...
 *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi
pFunction at 0x00CA79F0>] failed ***

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

From dragisha at m3w.org  Sun Jan 31 17:29:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 17:29:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
Message-ID: <1264955387.4240.2.camel@faramir.m3w.org>

I've asked this before, but didn't catch answer:

On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> I suggest we can probably get by with platform-independent
> packing/alignment settings.

Some time ago I've used pickles (CM3) to save some data... My program
does not read that pickle anymore.... 

Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Sun Jan 31 19:59:53 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Jan 2010 13:59:53 -0500
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <C987DE66-5EF6-4581-817C-FBFA9986ACC0@cs.purdue.edu>

That should not be the case.  Any changes should have made for more capability rather than less.  Any chance you know what data type is not being read properly? 



On 31 Jan 2010, at 11:29, Dragi?a Duri? wrote:

> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 
> 
> Someone remembers moment when this incompatible changes were made? 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From rodney_bates at lcwb.coop  Sun Jan 31 21:00:08 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 31 Jan 2010 14:00:08 -0600
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <1264955387.4240.2.camel@faramir.m3w.org>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org>
Message-ID: <4B65E148.4090105@lcwb.coop>



Dragi?a Duri? wrote:
> I've asked this before, but didn't catch answer:
> 
> On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
>> I suggest we can probably get by with platform-independent
>> packing/alignment settings.
> 
> Some time ago I've used pickles (CM3) to save some data... My program
> does not read that pickle anymore.... 

And you are certain your program that tries to read still contains
exact structurally equivalent types to all the types in the pickle?

> 
> Someone remembers moment when this incompatible changes were made? 


From dragisha at m3w.org  Sun Jan 31 22:14:47 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 31 Jan 2010 22:14:47 +0100
Subject: [M3devel] platform-independent packing/alignment?
In-Reply-To: <4B65E148.4090105@lcwb.coop>
References: <COL101-W212BAC9C71C68C28C11FE0E6590@phx.gbl>
	<1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>
Message-ID: <1264972487.4240.4.camel@faramir.m3w.org>

I've not changed my code, that is for sure.... But now I am not sure
some parent type (esp MUTEX here an there) was not changed... I'll take
a look on this again sometime soon and report my findings.

Thanks for clues.

On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> 
> Dragi?a Duri? wrote:
> > I've asked this before, but didn't catch answer:
> > 
> > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote:
> >> I suggest we can probably get by with platform-independent
> >> packing/alignment settings.
> > 
> > Some time ago I've used pickles (CM3) to save some data... My program
> > does not read that pickle anymore.... 
> 
> And you are certain your program that tries to read still contains
> exact structurally equivalent types to all the types in the pickle?
> 
> > 
> > Someone remembers moment when this incompatible changes were made? 
-- 
Dragi?a Duri? <dragisha at m3w.org>