From jay.krell at cornell.edu Mon Nov 1 09:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Nov 2010 08:20:16 +0000 Subject: [M3devel] m3cg_set_runtime_proc vs. m3cg_set_runtime_hook Message-ID: m3cg_set_runtime_proc vs. m3cg_set_runtime_hook appear to serve almost the same purpose. m3cg_set_runtime_hook is never used. Go ahead and remove it? ?- Jay From jay.krell at cornell.edu Fri Nov 5 17:02:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 16:02:33 +0000 Subject: [M3devel] llvm Message-ID: http://llvm.org/releases/2.8/docs/ReleaseNotes.html wow, lots of progress! From dragisha at m3w.org Fri Nov 5 17:13:04 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 5 Nov 2010 17:13:04 +0100 Subject: [M3devel] llvm In-Reply-To: References: Message-ID: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> And to put Modula-3 in this neighborhood.... JIT, LLDB... On Nov 5, 2010, at 5:02 PM, Jay K wrote: > http://llvm.org/releases/2.8/docs/ReleaseNotes.html > > wow, lots of progress! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 5 22:29:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 21:29:34 +0000 Subject: [M3devel] Hudson: illegal type: 0x17, at m3cg_lineno 4 Message-ID: Fyi, I fixed these on Linux/amd64: ? illegal type: 0x17, at m3cg_lineno 4 by replacing all the installs with a release and the rebuilding. So maybe something off in the upgrade process. Maybe. But there wasn't an IL/IR/m3cg change. Not understood. I can try this on Solaris/PPC_DARWIN. (PPC_DARWIN has another problem still last I knew.) Later, - Jay From jay.krell at cornell.edu Sat Nov 6 00:17:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:17:13 +0000 Subject: [M3devel] hudson/ppc_darwin Message-ID: PPC_DARWIN in Hudson will be broken a very short while. I know the problem. It has an older g++. Other platforms should be ok, or at least several were. Definitely a few succeeded. The opencsw machines need human intervention, which I can do, later. ? At least somewhat. If they say "no cm3 installed", I'm not sure. ? If they say "invalid type: 0x17", I'll reinstall cm3. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:52:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:52:03 +0000 Subject: [M3devel] opencsw/cvs Message-ID: I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. Specifically, here, 10x: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console it is using old source. But this one, 9s: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ is working. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:56:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:56:07 +0000 Subject: [M3devel] quake rm_rec/instrumentation? Message-ID: Is rm_rec known to work/fail? You can see it is still instrumented and seems to be working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console Refresher: ? the main problem was likely to do with symlinks and stat ? the fix is hacky, deep in m3core/libm3, I changed stat to first stat and if that fails, lstat ??? (maybe should only lstat upon particular erors) ?Otherwise deleting a symlink to a nonexistant file/directory failed. ?I also changed it to not delete while enumerating, but that probably was ok either way. ?I also changed it to stat much less (caveat that the "real fix" involves more calls sometimes). ?- Jay From wagner at elegosoft.com Sat Nov 6 10:41:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:41:34 +0100 Subject: [M3devel] quake rm_rec/instrumentation? In-Reply-To: References: Message-ID: <20101106104134.yjwh4qw28cw8gck0@mail.elegosoft.com> Quoting Jay K : > Is rm_rec known to work/fail? > > You can see it is still instrumented and seems to be working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console I haven't noticed any problems with rmrec recently, but then I haven't monitored the cm3 regression very carefully. I seem to remember that problems faced in m3tests and we introduced a workaround there. Perhaps we could disable that and see what happens. > Refresher: > ? the main problem was likely to do with symlinks and stat > ? the fix is hacky, deep in m3core/libm3, I changed stat to first > stat and if that fails, lstat > ??? (maybe should only lstat upon particular erors) > ?Otherwise deleting a symlink to a nonexistant file/directory failed. > > ?I also changed it to not delete while enumerating, but that > probably was ok either way. > ?I also changed it to stat much less (caveat that the "real fix" > involves more calls sometimes). That all sounds OK. You could simply make the debug code depend on the -trace or -debug option of cm3 to be prepared for the next failure ;-) 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 Sat Nov 6 10:44:25 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:44:25 +0100 Subject: [M3devel] hudson/ppc_darwin In-Reply-To: References: Message-ID: <20101106104425.y2ezk1i9gys0ws4w@mail.elegosoft.com> Quoting Jay K : > > PPC_DARWIN in Hudson will be broken a very short while. > I know the problem. It has an older g++. No problem. > Other platforms should be ok, or at least several were. > Definitely a few succeeded. > > The opencsw machines need human intervention, which I can do, later. That would be great. > ? At least somewhat. If they say "no cm3 installed", I'm not sure. > ? If they say "invalid type: 0x17", I'll reinstall cm3. -- 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 Sat Nov 6 13:29:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Nov 2010 12:29:04 +0000 Subject: [M3devel] small note for Solaris 2.9 Message-ID: fyi, to convert a SOLsun bootstrap to Solaris 2.9: for a in *s; do perl -pi.bak -e "s/^\s+\.hidden\s+.+$//" $a; done There are other ways. Native builds using autoconf and discover if .hidden works or not. Cross builds have to make an assumption and we err toward Solaris 2.10. We could err toward 2.9. We could adapt automatically at the "end" of "bootstrap". If we don't get a C/C++ backend, distributing as assembly-source and improving how that is built will be in order. e.g. err toward 2.9 and ship assembly source for "everything" e.g. err toward 2.9 but do this replacement if the probed assembler supports .hidden e.g. err toward 2.9 but only ship assembly for cm3, build everything else native from there. or just ignore it and nobody will notice. ?- Jay From jay.krell at cornell.edu Sun Nov 7 04:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 03:48:49 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw Message-ID: Gets as far as: --- building in SOLsun --- ignoring ../src/m3overrides /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB stubgen: Processing RemoteView.T *** *** runtime error: ***??? Thread client error: -1 ***??? file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 *** Abort - core dumped "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB I'll try 2.10 instead.. ?- Jay From jay.krell at cornell.edu Sun Nov 7 13:35:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 12:35:22 +0000 Subject: [M3devel] init_offset? Message-ID: m3cg.i3: init_offset (o: ByteOffset;? var: Var); (* initializes the static variable at 'ADR(v)+o' with the integer ?? frame offset of the local variable 'var' relative to the frame ?? pointers returned at runtime in RTStack.Frames *) The implications of this make me nervous. ? Must locals be at the indicated location when the garbage collector runs? Should we maybe make all traced pointers volatile? ?Or at least stores to them? ? I know we have a compacting garbage collector. ? If it moves a pointer.. it updates any instance of that value seen on the stack? ? (and I know, we endeavor to "flush" registers when paused for gc, so that ? stack suffices and no need to worry further about registers, except on NT386 ? where it is a little different, we can get/set the registers of the paused thread) If the stack is scanned and updated beyond this information, what is this information for? Maybe an optimization? Granted, I haven't looked at what the frontend does here. There's lots of stuff I could figure out by reading the code.. ?- Jay From dragisha at m3w.org Sun Nov 7 13:41:40 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 13:41:40 +0100 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> We don't'. Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). So, no need to "volatilize" anything explicitly. IMO :) On Nov 7, 2010, at 1:35 PM, Jay K wrote: > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) From hosking at cs.purdue.edu Sun Nov 7 14:24:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:24:09 -0500 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: This is used for exception handling. Sent from my iPad On 07/11/2010, at 7:35 AM, Jay K wrote: > > m3cg.i3: > > init_offset (o: ByteOffset; var: Var); > (* initializes the static variable at 'ADR(v)+o' with the integer > frame offset of the local variable 'var' relative to the frame > pointers returned at runtime in RTStack.Frames *) > > > The implications of this make me nervous. > Must locals be at the indicated location when the garbage collector runs? > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) > > If the stack is scanned and updated beyond this information, what is this information for? > Maybe an optimization? > > Granted, I haven't looked at what the frontend does here. > There's lots of stuff I could figure out by reading the code.. > > - Jay > From hosking at cs.purdue.edu Sun Nov 7 14:22:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:22:50 -0500 Subject: [M3devel] init_offset? In-Reply-To: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> References: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> Message-ID: Even if we did move stack-referenced objects we still would not need to volatilise. The assumption should always be that registers (as captured when a thread is stopped) will also be available for scanning. That's why on some targets we explicitly capture the thread registers. But it is true that we don't move stack-referenced objects. Sent from my iPad On 07/11/2010, at 7:41 AM, Dragi?a Duri? wrote: > We don't'. > > Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). > > So, no need to "volatilize" anything explicitly. > > IMO :) > > On Nov 7, 2010, at 1:35 PM, Jay K wrote: > >> Should we maybe make all traced pointers volatile? >> Or at least stores to them? >> I know we have a compacting garbage collector. >> If it moves a pointer.. it updates any instance of that value seen on the stack? >> (and I know, we endeavor to "flush" registers when paused for gc, so that >> stack suffices and no need to worry further about registers, except on NT386 >> where it is a little different, we can get/set the registers of the paused thread) > From lemming at henning-thielemann.de Sun Nov 7 17:33:04 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 17:33:04 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > And to put Modula-3 in this neighborhood.... JIT, LLDB... I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. From dragisha at m3w.org Sun Nov 7 20:15:57 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:15:57 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> I mentioned JIT just so, LLVM is not just JIT. And yes, you are right. GCC is a pillar of stability. Especially when you run after them trying to catch their undocumented changes to IR. NOT :) On Nov 7, 2010, at 5:33 PM, Henning Thielemann wrote: > > On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > >> And to put Modula-3 in this neighborhood.... JIT, LLDB... > > I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. > From lemming at henning-thielemann.de Sun Nov 7 20:38:31 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 20:38:31 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > I mentioned JIT just so, LLVM is not just JIT. Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. From dragisha at m3w.org Sun Nov 7 20:45:27 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:45:27 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: <7FDAA6E8-7503-4105-AED4-9DE27A17D526@m3w.org> http://llvm.org/Users.html On Nov 7, 2010, at 8:38 PM, Henning Thielemann wrote: > > On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > >> I mentioned JIT just so, LLVM is not just JIT. > > Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. > From jay.krell at cornell.edu Sun Nov 7 22:40:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:40:02 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: Message-ID: It works on 2.10 (opencsw current10s). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLsun/Solaris 2.9/opencsw > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > Gets as far as: > --- building in SOLsun --- > > ignoring ../src/m3overrides > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > stubgen: Processing RemoteView.T > > > *** > *** runtime error: > *** Thread client error: -1 > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > *** > > Abort - core dumped > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > I'll try 2.10 instead.. > > - Jay > > > > > From jay.krell at cornell.edu Sun Nov 7 22:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:35:32 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? Message-ID: == package /home/jkrell/dev2/cm3/m3-ui/opengl == ?+++ /home/jkrell/cm3.sparc32-5.10/bin/cm3??? -build -DROOT=/home/jkrell/dev2/cm3 +++ --- building in SOLsun --- ignoring ../src/m3overrides new source -> compiling GL.i3 new source -> compiling GLu.i3 new source -> compiling GLX.i3 ?-> archiving libopengl.a ld: fatal: library -lGLU: not found ld: fatal: library -lGL: not found ?- Jay From jay.krell at cornell.edu Sun Nov 7 22:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:53:25 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? In-Reply-To: References: Message-ID: (I can workaround this reasonably.) ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de; m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:35:32 +0000 > Subject: [M3devel] Solaris 2.10/x86/OpenGL? > > > == package /home/jkrell/dev2/cm3/m3-ui/opengl == > > +++ /home/jkrell/cm3.sparc32-5.10/bin/cm3 -build -DROOT=/home/jkrell/dev2/cm3 +++ > --- building in SOLsun --- > > ignoring ../src/m3overrides > > new source -> compiling GL.i3 > new source -> compiling GLu.i3 > new source -> compiling GLX.i3 > -> archiving libopengl.a > ld: fatal: library -lGLU: not found > ld: fatal: library -lGL: not found > > > - Jay > > > > > From jay.krell at cornell.edu Mon Nov 8 00:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:28:36 +0000 Subject: [M3devel] slight hudson/opencsw oddity Message-ID: I saw this on current10s also. Notice how last-ok.3799 is in the subdirectories. I'll delete them and we'll see if they come back. Maybe I'll check others. m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls *??????????????? current: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg current--all-pkgs: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg last-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg prev-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg rel-d5.8.2: bin????? lib????? license? pkg ?- Jay From jay.krell at cornell.edu Mon Nov 8 00:42:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:42:35 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> Message-ID: Some quoting problem on the date? Notice also checkout vs. update. So far the Hudson configurations look the same. I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop building the old source and fail if cvs fails, at least initially. I'll maybe do that on current10s also, though maybe I should leave it working/updating. working: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 Building remotely on opencsw_current10s [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC not working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs? -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 ?- Jay ---------------------------------------- > Subject: Re: opencsw/cvs > From: dam at baltic-online.de > Date: Sun, 7 Nov 2010 14:00:50 +0100 > CC: m3devel at elegosoft.com; wagner at elegosoft.com > To: jay.krell at cornell.edu > > Hi Jay, > > Am 06.11.2010 um 00:52 schrieb Jay K: > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > Specifically, here, 10x: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > it is using old source. > > > > But this one, 9s: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > is working. > > This is strange as both seem to use cvs-feature which is ok. However, > the build is quite old and was done with current build system. How does > the proxy-setup look like as both build machines are on internal > network only? > > > Best regards > > -- Dago > From jay.krell at cornell.edu Mon Nov 8 00:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:50:47 +0000 Subject: [M3devel] maximum size bits vs. bytes Message-ID: It appears we might limit data structures to LAST(INTEGER) bits instead of LAST(INTEGER) bytes. Judging from m3core/TextLiteral.i3. I see that measuring in bits instead of bytes is surprisingly convenient, but this seems not great. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:37:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:37:11 +0000 Subject: [M3devel] Hudson/status Message-ID: Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a matter of CVS now I think. Ditto Darwin/AMD64. So I'll "reset" Hudson's state. I'm trying Solaris 2.9 again. I don't remember about Solaris/x86. I'll try again. Later. I *think* everything else is ok -- Linux/x86/amd64, FreeBSD/x86/amd64, Darwin/x86/ppc. ? I'll double check these but later. ? Not sure about OpenBSD/NetBSD. ? Network to OpenBSD seems to not work any longer in Hudson. ? - Jay From jay.krell at cornell.edu Mon Nov 8 01:34:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:34:24 +0000 Subject: [M3devel] field references in m3cg Message-ID: I was slow to realize this. Slow to realize how procs/labels/vars work. Fields need to be small integers that index into a global array of trees, just like procs/labels/vars. Types also should work this way -- that I do binary search for type id is not great. I'll get to this pretty soon as part of making the gcc IR typeful. After I get Hudson into better shape. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:39:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:39:37 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de>, Message-ID: ?>> Notice also checkout vs. update. I think that's it. I think I did the checkout manually. And then here is update succeeding: ?? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/105/console ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de > CC: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: opencsw/cvs > Date: Sun, 7 Nov 2010 23:42:35 +0000 > > > Some quoting problem on the date? > Notice also checkout vs. update. > So far the Hudson configurations look the same. > I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop > building the old source and fail if cvs fails, at least initially. > I'll maybe do that on current10s also, though maybe I should leave it working/updating. > > working: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" > /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC > > > not working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > > > - Jay > > ---------------------------------------- > > Subject: Re: opencsw/cvs > > From: dam at baltic-online.de > > Date: Sun, 7 Nov 2010 14:00:50 +0100 > > CC: m3devel at elegosoft.com; wagner at elegosoft.com > > To: jay.krell at cornell.edu > > > > Hi Jay, > > > > Am 06.11.2010 um 00:52 schrieb Jay K: > > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > > > Specifically, here, 10x: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > > > it is using old source. > > > > > > But this one, 9s: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > > > is working. > > > > This is strange as both seem to use cvs-feature which is ok. However, > > the build is quite old and was done with current build system. How does > > the proxy-setup look like as both build machines are on internal > > network only? > > > > > > Best regards > > > > -- Dago > > > From wagner at elegosoft.com Mon Nov 8 09:40:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 09:40:26 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: Message-ID: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Quoting Jay K : > I saw this on current10s also. > Notice how last-ok.3799 is in the subdirectories. If you see such a name (for longer than a few seconds), then something has crashed during the final exchange of m3 package pools. I don't really know why exactly this happens. It would be great if we could make it as atomic as possible. > I'll delete them and we'll see if they come back. If you see a pattern there, let mw know. Olaf > Maybe I'll check others. > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > *??????????????? > current: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > current--all-pkgs: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > last-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > prev-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > rel-d5.8.2: > bin????? lib????? license? pkg > > > ?- 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 jay.krell at cornell.edu Mon Nov 8 09:50:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 08:50:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: Presumably it's mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* ? I've definitely saw a bunch of these directories, just not with the wrong layout. I've been going to all the nodes and cleaning up/recovering. There is something bad I don't understand that hit many of them. This: ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 The "best" and very not good explanation is an m3cg intermediate format change and incorrect upgrade process. I did make a change in the past week, the removal of set_runtime_hook or such. I made sure my upgrade.py works, which I know isn't what Hudson uses. But I suspect(ed) Hudson does things right. I also added a field to a call within the past few months and it worked ok. So I don't know. - Jay > Date: Mon, 8 Nov 2010 09:40:26 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] slight hudson/opencsw oddity > > Quoting Jay K : > > > I saw this on current10s also. > > Notice how last-ok.3799 is in the subdirectories. > > If you see such a name (for longer than a few seconds), then something > has crashed during the final exchange of m3 package pools. I don't really > know why exactly this happens. It would be great if we could make it > as atomic as possible. > > > I'll delete them and we'll see if they come back. > > If you see a pattern there, let mw know. > > Olaf > > > Maybe I'll check others. > > > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > > * > > current: > > bin lib man www > > last-ok.3799 license pkg > > > > current--all-pkgs: > > bin lib man www > > last-ok.3799 license pkg > > > > last-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > prev-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > rel-d5.8.2: > > bin lib license pkg > > > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:05:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:05:50 +0100 Subject: [M3devel] Hudson/status In-Reply-To: References: Message-ID: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Quoting Jay K : > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > matter of CVS now I think. > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > I'm trying Solaris 2.9 again. > I don't remember about Solaris/x86. I'll try again. Later. > I *think* everything else is ok -- Linux/x86/amd64, > FreeBSD/x86/amd64, Darwin/x86/ppc. FreeBSD/x84 seems to be broken since 17 days: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ PPC_DARWIN has been broken for 7 days: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ Solaris 2.9 hasn't succeeded for more than a month: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ Same for AMD64_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ We should try to get all of these working again and then keep them in that state :-) Currently everything seems to be very unstable, but I haven't said much because (a) I haven't had much time to care and (b) I thought you were doing same major changes on the backend again. Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson display. > ? I'll double check these but later. > ? Not sure about OpenBSD/NetBSD. > ? Network to OpenBSD seems to not work any longer in Hudson. If we should exclude some platforms from the view due to non-available build machines, let me know. You can do that yourself, too at http://hudson.modula3.com:8080/view/cm3-current/configure. 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 Nov 8 10:16:03 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:16:03 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Quoting Jay K : > Presumably it's > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > ? Why/how should that fail unless the machine actually goes down, which didn't really happen, did it? > I've definitely saw a bunch of these directories, just not with the > wrong layout. > I've been going to all the nodes and cleaning up/recovering. > There is something bad I don't understand that hit many of them. > This: > ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal > type: 0x17, at m3cg_lineno 4 > > The "best" and very not good explanation is an m3cg intermediate > format change and incorrect upgrade process. > I did make a change in the past week, the removal of > set_runtime_hook or such. > I made sure my upgrade.py works, which I know isn't what Hudson uses. > But I suspect(ed) Hudson does things right. The Hudson jobs uses the upgrade.sh script, but that should work, too. Actually nothing that didn't compile the core should ever get installed in the cm3-inst/last-ok package pool, but sometimes this doesn't seem to work :-/ > I also added a field to a call within the past few months and it worked ok. > > So I don't know. -- 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 Nov 8 10:18:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:18:45 +0000 Subject: [M3devel] Hudson/status In-Reply-To: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> References: , <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Message-ID: Yes, I'm working on fixing all the Hudson breakage. I have more changes coming. None of them are particularly major, but in proportion to my ability to execute.... :( Everything did work on my machine (*). Hm, It could therefore be the m3cg/ir/interface change, which was an ok change, it just has to be scripted/danced properly. I believe I'll have more m3cg changes soon -- representing fields and types as "ordinals". We do have to be able to make such changes. I would be willing to have the version number actually ever change (I never ever has I believe) and use it to indicate the form and have one cm3cg that handles multiple forms. At least temporarily until they all get updated. But I know many folks dislike that kind of thing. It gets ugly as many versions are supported. I didn't anticipate C++ being such a problem, but I'm still willing to go with it. It is supposed to work, and it does "just work" with g++ 4.x. It just didn't work with g++ 3.x and Sun CC. (*) -- however a) I forgot to checkin m3makefile a few times and b) due to incrementality, it wasn't always using current files. Yep... 2010-11-01 09:59 jkrell * scripts/python/upgrade.py, m3-sys/m3cggen/src/Main.m3, m3-sys/m3middle/src/M3CG_BinRd.m3, m3-sys/m3middle/src/M3CG_Binary.i3, m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h, m3-sys/m3cc/gcc/gcc/m3cg/parse.c: remove the rest of set_runtime_hook 2010-11-01 09:37 jkrell * m3-sys/: m3cggen/src/Main.m3, m3middle/src/M3CG.m3, m3middle/src/M3CG_BinRd.m3, m3middle/src/M3CG_BinWr.m3, m3middle/src/M3CG_Binary.i3, m3middle/src/M3CG_Check.m3, m3middle/src/M3CG_Ops.i3, m3middle/src/M3CG_Rd.m3, m3middle/src/M3CG_Wr.m3, m3back/src/M3C.m3, m3back/src/M3x86.m3, m3cc/gcc/gcc/m3cg/parse.c: remove get_runtime_hook, set_runtime_hook small part remains, until I work m3cggen into upgrade.py so that m3cg.h can be more easily updated - Jay > Date: Mon, 8 Nov 2010 10:05:50 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson/status > > Quoting Jay K : > > > > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > > matter of CVS now I think. > > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > > I'm trying Solaris 2.9 again. > > I don't remember about Solaris/x86. I'll try again. Later. > > I *think* everything else is ok -- Linux/x86/amd64, > > FreeBSD/x86/amd64, Darwin/x86/ppc. > > FreeBSD/x84 seems to be broken since 17 days: > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ > PPC_DARWIN has been broken for 7 days: > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ > Solaris 2.9 hasn't succeeded for more than a month: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ > Same for AMD64_DARWIN: > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ > > We should try to get all of these working again and then keep them > in that state :-) Currently everything seems to be very unstable, > but I haven't said much because (a) I haven't had much time to care and > (b) I thought you were doing same major changes on the backend again. > > Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson > display. > > > I'll double check these but later. > > Not sure about OpenBSD/NetBSD. > > Network to OpenBSD seems to not work any longer in Hudson. > > If we should exclude some platforms from the view due to non-available > build machines, let me know. You can do that yourself, too at > http://hudson.modula3.com:8080/view/cm3-current/configure. > > 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: From jay.krell at cornell.edu Mon Nov 8 10:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:20:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > > > ? > Why/how should that fail unless the machine actually goes down, which > didn't really happen, did it? Indeed, that is rare. Sometimes I have to reboot for some updates. xdarwin/xnbsd often "sleep". But uptime is high all around. I do wish Hudson could manage the power of the systems...leave them mostly off... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:47:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:47:10 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: , Message-ID: This is wierd. It is pthread_create returning -1. I have seen it a number of times, but I also have seen it work ok. I'm going to punt for now and move on to other Hudson breaks. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:40:02 +0000 > Subject: Re: [M3devel] SOLsun/Solaris 2.9/opencsw > > > It works on 2.10 (opencsw current10s). > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: SOLsun/Solaris 2.9/opencsw > > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > > > > Gets as far as: > > --- building in SOLsun --- > > > > ignoring ../src/m3overrides > > > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > stubgen: Processing RemoteView.T > > > > > > *** > > *** runtime error: > > *** Thread client error: -1 > > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > > *** > > > > Abort - core dumped > > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > > > > I'll try 2.10 instead.. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:50:37 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > The Hudson jobs uses the upgrade.sh script, but that should work, too. > Actually nothing that didn't compile the core should ever get installed > in the cm3-inst/last-ok package pool, but sometimes this doesn't seem The important thing is that cm3 and cm3cg need to be updated together. They must always be taken as a matched pair. You may never mix and match. Well, max/match *usually* works. But the way to allow interface changes is to not do that. But those changes are rare... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:59:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:59:42 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Quoting Jay K : >> The Hudson jobs uses the upgrade.sh script, but that should work, too. >> Actually nothing that didn't compile the core should ever get installed >> in the cm3-inst/last-ok package pool, but sometimes this doesn't seem > > The important thing is that cm3 and cm3cg need to be updated together. > They must always be taken as a matched pair. > You may never mix and match. > Well, max/match *usually* works. But the way to allow interface changes > is to not do that. But those changes are rare... Our current separation of Hudson jobs for m3cc and cm3 will only work if we start with m3cc _and_ the new cm3cg can be used by the _old_ cm3 front-end. If we expect more incompatible changes related to the cm3-gcc interface, we should indeed consider a version mechanism there at least to detect mismatches. 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 Nov 8 11:11:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 10:11:38 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com>, , <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Message-ID: > > The important thing is that cm3 and cm3cg need to be updated together. > > They must always be taken as a matched pair. > > You may never mix and match. > > Well, max/match *usually* works. But the way to allow interface changes > > is to not do that. But those changes are rare... > > Our current separation of Hudson jobs for m3cc and cm3 will only work > if we start with m3cc _and_ the new cm3cg can be used by the _old_ > cm3 front-end. If we expect more incompatible changes related to the Hm. Well, it was good to discover this, eventually. It is fine to split the tasks. You can build stuff in whatever order. But the updated files should only be used/copied at the right times/combinations. It shouldn't be difficult. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 9 11:49:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 10:49:10 +0000 Subject: [M3devel] still recovering Hudson.. Message-ID: The incorrect updating of cm3cg in Hudson is expensive to recover from. What I'm doing is for each platform, is the usual... ./boot1.py copy the result to the target machine build it there -- giving an up to date cm3 copy cm3 to a new install make a new CVS checkout boot2.sh overkill, but also a good test originally I was doing this on opencsw where I'm not sure how much succeed we've had, so doing the full boot2 was more valid. and then subset the boot2.sh output and copy it all around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. The FreeBSD4 machine is really slow! I think the CVS checkout took hours! We really need to fix this very soon -- update cm3/cm3cg correctly. I could have sworn a similar update went ok within the past few months. - Jay From wagner at elegosoft.com Tue Nov 9 12:38:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 12:38:21 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: Message-ID: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Quoting Jay K : > The incorrect updating of cm3cg in Hudson is expensive > to recover from. Sorry to hear that. > What I'm doing is for each platform, is the usual... > ./boot1.py > copy the result to the target machine > build it there -- giving an up to date cm3 > > copy cm3 to a new install > make a new CVS checkout > boot2.sh > overkill, but also a good test > originally I was doing this on opencsw where I'm not > sure how much succeed we've had, so doing the full > boot2 was more valid. > > and then subset the boot2.sh output and copy it all > around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. Wouldn't it have been possible to backup all the package pools from from prev-ok and then perform the upgrade in the correct order? > The FreeBSD4 machine is really slow! > I think the CVS checkout took hours! This should not be; but then, something else may run during the daytime either on the server or load the network. > We really need to fix this very soon -- update cm3/cm3cg correctly. > I could have sworn a similar update went ok within the past few months. Have tou got a concrete plan? 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 Nov 9 13:02:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:02:27 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 9 Nov 2010 12:38:21 +0100 > From: wagner > Wouldn't it have been possible to backup all the package pools > from from prev-ok and then perform the upgrade in the correct order? I'm sure there's a better way but I'm doing what I know for now. Slowing me down will probably please some people anyway. :) > > The FreeBSD4 machine is really slow! > > I think the CVS checkout took hours! > > This should not be; but then, something else may run during the daytime > either on the server or load the network. I assumed maybe it is a virtual machine, and lacks "para viritualization"? > Have tou got a concrete plan? Read through more of the code and Hudson configuration and fix it. Mostly seriously. The required behavior should be trivial to implement. I just have to know where to put it. I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" are the problem. I *somewhat* suspect cm3cg is copied from one task to the other merely at the wrong time. But I have to look through the code and Hudson tasks. I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, at the same time m3cc would do its normal build. Anyway, I just have to poke around some. - Jay From jay.krell at cornell.edu Tue Nov 9 13:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:05:38 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: ps: current, last-ok, prev-ok, etc. I don't know what all these are. So I just make a valid current install and replace them all. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] still recovering Hudson.. > Date: Tue, 9 Nov 2010 12:02:27 +0000 > > > ---------------------------------------- > > Date: Tue, 9 Nov 2010 12:38:21 +0100 > > From: wagner > > > Wouldn't it have been possible to backup all the package pools > > from from prev-ok and then perform the upgrade in the correct order? > > > I'm sure there's a better way but I'm doing what I know for now. > Slowing me down will probably please some people anyway. :) > > > > > The FreeBSD4 machine is really slow! > > > I think the CVS checkout took hours! > > > > This should not be; but then, something else may run during the daytime > > either on the server or load the network. > > > I assumed maybe it is a virtual machine, and lacks "para viritualization"? > > > Have tou got a concrete plan? > > > Read through more of the code and Hudson configuration and fix it. > Mostly seriously. > The required behavior should be trivial to implement. I just have to know > where to put it. > > > > I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" > are the problem. > I *somewhat* suspect cm3cg is copied from one task to the other merely > at the wrong time. But I have to look through the code and Hudson tasks. > I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, > at the same time m3cc would do its normal build. > Anyway, I just have to poke around some. > > > > - Jay > From jay.krell at cornell.edu Tue Nov 9 13:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:44:19 +0000 Subject: [M3devel] last-ok.1234 Message-ID: just a sample before I clean it up... new.elego.de [~/work/cm3-inst/new] hudson % ls -l total 24 drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current--all-pkgs/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 current--lastok-build/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.23891/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.25217/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.41276/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.49455/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.63073/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.72551/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 prev-ok/ drwxrwx--- 8 hudson Ghudson 8 Feb 12 2010 rel-d5.7.1/ From wagner at elegosoft.com Tue Nov 9 14:20:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 14:20:30 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Quoting Jay K : > ps: current, last-ok, prev-ok, etc. I don't know what all these are. > So I just make a valid current install and replace them all. I thought I had explained that some time ago, but maybe I forgot. So here is the gist: o current, last-ok, prev-ok are all complete package pools + compiler that contain a complete cm3 installation o for builds, current is initialized from last-ok; then packages are built and shipped to current o if a build succeeds: - prev-ok is replaced by last-ok - last-ok is replaced by current Thus we should always have a backup for recovery in case something goes wrong. And last-ok should always be exactly what its name indicates (the last working version) (it seems that this invariant sometimes does not hold :-/) o tests usually just use last-ok Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] still recovering Hudson.. >> Date: Tue, 9 Nov 2010 12:02:27 +0000 >> >> >> ---------------------------------------- >> > Date: Tue, 9 Nov 2010 12:38:21 +0100 >> > From: wagner >> >> > Wouldn't it have been possible to backup all the package pools >> > from from prev-ok and then perform the upgrade in the correct order? >> >> >> I'm sure there's a better way but I'm doing what I know for now. >> Slowing me down will probably please some people anyway. :) >> >> >> > > The FreeBSD4 machine is really slow! >> > > I think the CVS checkout took hours! >> > >> > This should not be; but then, something else may run during the daytime >> > either on the server or load the network. >> >> >> I assumed maybe it is a virtual machine, and lacks "para viritualization"? >> >> > Have tou got a concrete plan? >> >> >> Read through more of the code and Hudson configuration and fix it. >> Mostly seriously. >> The required behavior should be trivial to implement. I just have to know >> where to put it. >> >> >> >> I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" >> are the problem. >> I *somewhat* suspect cm3cg is copied from one task to the other merely >> at the wrong time. But I have to look through the code and Hudson tasks. >> I also suspected it worked right, in that the copy is done in >> m3cc/src/m3makefile, >> at the same time m3cc would do its normal build. >> Anyway, I just have to poke around some. >> >> >> >> - 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 jay.krell at cornell.edu Wed Nov 10 08:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 07:47:57 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: > I thought I had explained that some time ago, but maybe I forgot. So here > is the gist: > > o current, last-ok, prev-ok are all complete package pools + compiler that > contain a complete cm3 installation > o for builds, current is initialized from last-ok; then packages > are built and shipped to current > o if a build succeeds: > - prev-ok is replaced by last-ok > - last-ok is replaced by current > Thus we should always have a backup for recovery in case something > goes wrong. And last-ok should always be exactly what its name > indicates (the last working version) (it seems that this invariant > sometimes does not hold :-/) > o tests usually just use last-ok Do we need all this? I guess it is ok. There should be just two when idle and three during a build. ?But there are more than that currently, more than what you list. But we don't need them to be complete. They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. More generally I thinking of digging into the Hudson stuff. I think I know what to do about cm3cg, at least. There are two kinds of "ships" or installs. There is ship/install on top of the "currently running" install, and there is install to other than it, possibly to a directory that started empty (recently). Shipping of cm3 doesn't do anything. This could be viewed as a limitation -- the comments indicate it is at least partly due to shipping in-use files doesn't work on some operating systems (not just Windows, in fact, it is easy to do on Windows -- rename away first). However it is also a good thing. Shipping of m3cc/cm3g does do something. I assert that shipping either of cm3 or cm3cg on top of the "currently running" install is wrong. Shipping into other, a new empty directory, is perfectly fine. In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. For the "currently running" install, ship should do nothing, and should instead be done "outside the usual system" via sh/python. Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. And the config files (I suspect also already the case). That way they can be updated together.? *** the very important point ** Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? I'd like there to be as few of tasks as possible. "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. Related: we currently keep all snapshots on the build machines. We shouldn't keep so many. ?- Jay From jay.krell at cornell.edu Wed Nov 10 09:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 08:32:01 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: References: , , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , , , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, Message-ID: The fact that upgrade.sh does NOT "ship" m3cc, but installs it in a "special" way/time along with cm3, looks promising I have to look closer..to confirm/deny that things are written correctly or not. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 10 Nov 2010 07:47:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson structure? > > > > I thought I had explained that some time ago, but maybe I forgot. So here > > is the gist: > > > > o current, last-ok, prev-ok are all complete package pools + compiler that > > contain a complete cm3 installation > > o for builds, current is initialized from last-ok; then packages > > are built and shipped to current > > o if a build succeeds: > > - prev-ok is replaced by last-ok > > - last-ok is replaced by current > > Thus we should always have a backup for recovery in case something > > goes wrong. And last-ok should always be exactly what its name > > indicates (the last working version) (it seems that this invariant > > sometimes does not hold :-/) > > o tests usually just use last-ok > > > Do we need all this? > I guess it is ok. There should be just two when idle and three during a build. > But there are more than that currently, more than what you list. > > > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. > > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that started empty (recently). > > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is at least partly > due to shipping in-use files doesn't work on some operating systems (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. > > > I assert that shipping either of cm3 or cm3cg on top of the "currently running" > install is wrong. > > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. > > > For the "currently running" install, ship should do nothing, and should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. > And the config files (I suspect also already the case). > > > That way they can be updated together. *** the very important point ** > > > Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. > Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. > > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. > > > - Jay > > From wagner at elegosoft.com Wed Nov 10 09:48:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 09:48:22 +0100 Subject: [M3devel] Hudson structure? In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Quoting Jay K : > >> I thought I had explained that some time ago, but maybe I forgot. So here >> is the gist: >> >> o current, last-ok, prev-ok are all complete package pools + compiler that >> contain a complete cm3 installation >> o for builds, current is initialized from last-ok; then packages >> are built and shipped to current >> o if a build succeeds: >> - prev-ok is replaced by last-ok >> - last-ok is replaced by current >> Thus we should always have a backup for recovery in case something >> goes wrong. And last-ok should always be exactly what its name >> indicates (the last working version) (it seems that this invariant >> sometimes does not hold :-/) >> o tests usually just use last-ok > > Do we need all this? > I guess it is ok. There should be just two when idle and three > during a build. > ?But there are more than that currently, more than what you list. test and build jobs may run in parallel, I think test-all-pkgs uses its own current. > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), > m3core, libm3. > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that > started empty (recently). > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is > at least partly > due to shipping in-use files doesn't work on some operating systems > (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. Yes. That's not consequent. I seem to remember that there were objections to _not_ ship cm3cg to bin though. > I assert that shipping either of cm3 or cm3cg on top of the > "currently running" > install is wrong. > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as > the destination doesn't yet exist. > > For the "currently running" install, ship should do nothing, and > should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg > is dealt with. > And the config files (I suspect also already the case). > > That way they can be updated together.? *** the very important point ** Yes. > Related question: now that we have far less frequent builds, can we > merge the m3cc and build Hudson tasks? I'd rather avoid that. The m3cc builds takes hours on some systems, and _usually_ (unless someone is working on the backend) this should not need to be built at all. On the other hand: you may be right. We could easily just disable all the m3cc jobs for the time being and always build m3cc together with the other core packages in the -build- jobs. > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations > to test, etc. > Though granularity is also nice -- if some things are broken, still > nice to see some tasks succeeding. > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. Do we? We shouldn't keep any on the build machine. Snapshots are (should be?) copied to birch.elegosoft.com and kept there for some time. 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 Wed Nov 10 10:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 09:08:53 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, , <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Message-ID: ?> I seem to remember that there were objections to _not_ ship cm3cg to bin though I think it actually ship to bin/target or bin/host/target, but that is a different matter. Anyway, the problem is solved, in that upgrade.sh doesn't ship m3cc. As long as we use upgrade.sh and don't just launch into a buildship of everything, ok. ?> stuff running in parallel ? ? ah ? ?> The m3cc builds takes hours on some systems ? ? They should be faster now and better at being incremental. ? (somewhat contradictory: I used to throw -disable-dependency-checking ? as a speed up, now I don't; Cygwin is probably significantly slower ? therefore, far more forks(), but other platforms not) ? ? But that doesn't completely counter your point. ? gmp/mpfr/mpc were a significant portion, almost gone now ??? (I'm tempted to further reduce them -- one of the main ??? existing dependencies is in loop unrolling, but ??? the frontend I think already does loop unrolling; ??? but cm3cg should be able to do better since it does ??? more sophisticated analysis -- and still, cm3cg ??? has available efficient 64bit integers without gmp, ??? the need for gmp is in general therefore, unclear; ??? the need for mpfr is actually sort of "more clear", except ??? that it isn't used where I thought it might be -- it isn't ??? used for floating point constant propagation, but for implementing ??? builtin" functions; besides, floating point is essentially ??? identical across all build hosts, so doesn't need to be "simulated"; ??? and mpc is for complex math, which we never use..mpfr ??? and mpc are completely gone, gmp is much smaller than previously) I'm torn now. I want to test an m3cg.i3 change, but if it fails, I don't want to do the tedious recovery. Maybe if I'm quick, only one or two machines will see it? ?- Jay From jay.krell at cornell.edu Wed Nov 10 12:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 11:37:10 +0000 Subject: [M3devel] rcc_upgradecm3.cmd Message-ID: Randy, code like this: pushd ..\..\.. if exist "bin\cm3.exe" if exist "pkg" set CM3_ROOT=%CD%& popd & goto FoundRoot is almost exactly equivalent to: if exist "..\..\..\bin\cm3.exe" if exist "..\..\..\pkg" set CM3_ROOT=..\..\..& popd & goto FoundRoot the advantage of the second form is fewer intermediate side effects ? i.e. not cd'ing around to the various possible path, just using them more directly the disadvantage of the second form is the ".." survive? and may be unsightly. ? But leaving ".." will work ok with very little exception. The ".." can be removed via e.g.: call :GetFullPath CM3_ROOT %CM3_ROOT% goto :end_GetFullPath :GetFullPath set %1=%~f2 goto :eof :end_GetFullPath I believe that would also work. There are other ways.. such as looping over all the possibilities and taking the first that works. anyway.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 13:48:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 12:48:14 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile Message-ID: == package /Users/jay/dev2/cm3/elego/m3msh == ?+++ /cm3/bin/cm3??? -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling M3MiniShell.m3 ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' ? m3_backend => 1 I've been sprinkling volatile around, no luck yet.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 14:15:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:15:31 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: nevermind, I found a workaround that is probably ok a deoptimization but it shouldn't be common and significant But it also isn't the expected one. I figured volatile somewhere would do the trick, not avoiding inlining. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > From jay.krell at cornell.edu Wed Nov 10 14:39:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:39:08 +0000 Subject: [M3devel] hudson/m3cg ir changes Message-ID: Looking into why the m3cg.i3 changes broke... http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull This log doesn't show the "safe" upgrade that avoids ship and then ships all at once process. But it does show something else that should work: ?it builds all ?and then ships all (including cm3cg) ?and then presumably would handle cm3 specially However when it goes to ship cm3, it compiles stuff. That should already be compiled. And cm3cg had just been updated. Here: === package m3-sys/cm3 === +++ cm3 -build -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' +++ ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 This I don't understand. And can't trivially reproduce. I understand that every time you build cm3, it will recompile Version.i3 and another file. But 1) this tries to recompile more and 2) for me, cm3 -ship never recompiles anything anyway Also notice that LINUXLIBC6 never broke. Hm. Given the break Oct 27 and what I might have done to fix, that's inconclusive. You can see LINUXLIBC6 also compiling during -ship. So, two things now... change the process to use upgrade.sh. and/or find out why -ship is compiling anything. - Jay From hosking at cs.purdue.edu Wed Nov 10 16:14:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Nov 2010 10:14:01 -0500 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: Did you disable inlining on everything? Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 10 Nov 2010 12:48:14 +0000 >> Subject: [M3devel] setjmp/longjmp still missing volatile >> >> >> == package /Users/jay/dev2/cm3/elego/m3msh == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling M3MiniShell.m3 >> ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': >> ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' >> m3_backend => 1 >> >> >> >> I've been sprinkling volatile around, no luck yet.. >> >> - Jay >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Nov 10 16:22:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 16:22:31 +0100 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: References: Message-ID: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Quoting Jay K : > Looking into why the m3cg.i3 changes broke... > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull > > This log doesn't show the "safe" upgrade that avoids ship and then > ships all at once process. > > But it does show something else that should work: > ?it builds all > ?and then ships all (including cm3cg) > ?and then presumably would handle cm3 specially > > However when it goes to ship cm3, it compiles stuff. That should > already be compiled. > And cm3cg had just been updated. > > Here: > > === package m3-sys/cm3 === > +++ cm3 -build > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > $RARGS && cm3 -ship $RARGS > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > +++ > ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at > m3cg_lineno 4 > compilation terminated. > m3_backend => 1 > > This I don't understand. > And can't trivially reproduce. > I understand that every time you build cm3, it will recompile > Version.i3 and another file. > But 1) this tries to recompile more and 2) for me, cm3 -ship never > recompiles anything anyway What you probably see is that a set of packages is first built locally and then with buildship. You cannot just use ship on a locally compiled set (with overrides), because the compiler will refuse to do that as the dependencies have changed. > Also notice that LINUXLIBC6 never broke. > Hm. Given the break Oct 27 and what I might have done to fix, that's > inconclusive. > You can see LINUXLIBC6 also compiling during -ship. This is strange. > So, two things now... change the process to use upgrade.sh. > and/or find out why -ship is compiling anything. If upgrade.sh already works OK, how could the last-ok installations on the Hudson nodes become corrupted? Ideally, the cm3-current-build job should fail and retry everything with upgrade.sh. Probably the new incompatible cm3cg has already been installed then in current, and we would need to restart with last-ok. Could that be the problem? Then it should be easy to fix (in scripts/regression/defs.sh in test_build_system). 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 Wed Nov 10 22:04:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:04:01 +0000 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> References: , <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Message-ID: > What you probably see is that a set of packages is first built locally > and then with buildship. You cannot just use ship on a locally compiled Oops, you are right. I misread the log. > > You can see LINUXLIBC6 also compiling during -ship. > > This is strange. I probably misread the log there too. > If upgrade.sh already works OK, how could the last-ok installations > on the Hudson nodes become corrupted? Ideally, the cm3-current-build > job should fail and retry everything with upgrade.sh. Probably the > new incompatible cm3cg has already been installed then in current, and > we would need to restart with last-ok. Could that be the problem? > Then it should be easy to fix (in scripts/regression/defs.sh in > test_build_system). Thanks, I will look further. Basically, endeavor to use upgrade more and buildship less. ?- Jay From jay.krell at cornell.edu Wed Nov 10 22:00:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:00:34 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , Message-ID: No, and it doesn't. Variables are introduced later. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Wed, 10 Nov 2010 10:14:01 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > Did you disable inlining on everything? > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would > do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > > > From jay.krell at cornell.edu Thu Nov 11 00:29:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 23:29:33 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , , Message-ID: I'll try to run volatization after the variables are introduced. I still like the idea of the frontend unnesting nested functions. It'd probably help here. I'm very willing to selectively suppress inlining to fix this, which I had done, but I'd rather not broadly suppress inlining. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] setjmp/longjmp still missing volatile > Date: Wed, 10 Nov 2010 21:00:34 +0000 > > > No, and it doesn't. > Variables are introduced later. > > - Jay > > ________________________________ > > From: hosking at cs.purdue.edu > > Date: Wed, 10 Nov 2010 10:14:01 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > > > Did you disable inlining on everything? > > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > > > > nevermind, I found a workaround that is probably ok > > a deoptimization but it shouldn't be common and significant > > But it also isn't the expected one. I figured volatile somewhere would > > do the trick, > > not avoiding inlining. > > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Wed, 10 Nov 2010 12:48:14 +0000 > > Subject: [M3devel] setjmp/longjmp still missing volatile > > > > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > > --- building in AMD64_DARWIN --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling M3MiniShell.m3 > > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > > might be clobbered by 'longjmp' or 'vfork' > > m3_backend => 1 > > > > > > > > I've been sprinkling volatile around, no luck yet.. > > > > - Jay > > > > > > > > > > > > > > > From jay.krell at cornell.edu Mon Nov 15 11:18:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Nov 2010 10:18:40 +0000 Subject: [M3devel] configur -enable-checking vs. types Message-ID: jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression struct { } * struct { } D.1466 = &M_RsrcFilter; I don't think this is actually "struct value" vs. "struct pointer". It is actually "struct1 pointer" vs. "struct2 pointer". So, I can probably just cast it away. But it points to a need in compiler to deal differently with types. They should be small integers like procs/labels/vars, I believe. So should fields. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 16 01:00:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 00:00:53 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: Message-ID: I tried various casts, no luck. I'm confused here.. :( - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: configur -enable-checking vs. types > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > struct > { > } * > > struct > { > } > > D.1466 = &M_RsrcFilter; > > > > I don't think this is actually "struct value" vs. "struct pointer". > It is actually "struct1 pointer" vs. "struct2 pointer". > So, I can probably just cast it away. > But it points to a need in compiler to deal differently with types. > They should be small integers like procs/labels/vars, I believe. > So should fields. > > > - Jay From jay.krell at cornell.edu Tue Nov 16 22:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 21:10:58 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: , Message-ID: The problem seems to be that we set the type for the segment, use that, and then change it. M3CG_HANDLER (BIND_SEGMENT) { gcc_assert (align >= !!size); current_segment = var; TREE_TYPE (var) = m3_build_type (type, size, align); M3CG_HANDLER (DECLARE_SEGMENT) { TREE_TYPE (var) = m3_build_type_id (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT, type_id); layout_decl (var, BIGGEST_ALIGNMENT); however, when I fix lots of configure -enable-checking problems, I get crashes. I suspect this one needs to be this way -- need the correct segment size. Making more passes will enable getting it right up front. Later. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: configur -enable-checking vs. types > Date: Tue, 16 Nov 2010 00:00:53 +0000 > > > I tried various casts, no luck. I'm confused here.. :( > > - Jay > > > ________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: configur -enable-checking vs. types > > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > > struct > > { > > } * > > > > struct > > { > > } > > > > D.1466 = &M_RsrcFilter; > > > > > > > > I don't think this is actually "struct value" vs. "struct pointer". > > It is actually "struct1 pointer" vs. "struct2 pointer". > > So, I can probably just cast it away. > > But it points to a need in compiler to deal differently with types. > > They should be small integers like procs/labels/vars, I believe. > > So should fields. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 17 22:55:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Nov 2010 21:55:24 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 Archiving artifacts Recording fingerprints Finished: FAILURE Can we format the time in a way that doesn't have any spaces? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Nov 18 09:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 09:16:39 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: Message-ID: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Quoting Jay K : > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > Archiving artifacts > Recording fingerprints > Finished: FAILURE > > Can we format the time in a way that doesn't have any spaces? I'm sure I already fixed that one months ago, though I don't remember the details. Has somehow an old script been installed in bin/cvs? 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 Nov 18 12:15:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:15:20 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:36:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:36:48 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Quoting Jay K : > Hm. Yes and no. I hadn't looked enough, but I think it is still broken. > There is $HOME/bin/cvs. I didn't know. > I guess it is mainly to avoid -z3. > Which rings a bell. We had some problem with that. Yes. I know that the first version didn't work, but I fixed that. And I think it _did_ run well some time. > Build #103 is not current. It is from Nov 8. > Before it, a bunch of success. Since it, a bunch of failure. > I had failed to look if the failures were all the same. > They are not. In fact the CVS failures seem to be all/mainly Nov 8. > > HOWEVER the later failures have been fixed in CVS. > Even though cvs upd isn't erroring, it also isn't working. > > I'm manually updating now, so the evidence will be lost. > But I'm sure it will either come back or is easily deliberately brought back. I'll have a look at the weekend, 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 Nov 18 12:38:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:38:12 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: scripts/regression/cvs.sh was in CVS It doesn't seem to work -- quotes are lost. cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, I put in place, we'll see. Would be nice to only quote if there are spaces though. Can we make Hudson use a date form without spaces? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:15:20 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:43:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:43:15 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Quoting Jay K : > scripts/regression/cvs.sh was in CVS > It doesn't seem to work -- quotes are lost. > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. Strange. > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > I put in place, we'll see. Would be nice to only quote if there are > spaces though. > > Can we make Hudson use a date form without spaces? I don't think so. Not without changing the CVS plugin source at least. 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 Nov 18 12:48:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:48:03 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Message-ID: > And I think it _did_ run well some time. It ran without error, I can see that. But across a few days/builds, no changed. #97 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/97/console no changes detected Deleting old artifacts from #95 #96 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/96/console $ no changes detected L?sche alte Artefakte von #94 Maybe I logged in around that time, and that caused something to change from German to English? But the date format is the same either way. - We'll see if my updated cvs helps? - Maybe if you merely login it'll change back and that's it?? (Great example of touching something and it breaks/fixes..but we don't know if that was it. It appears to pickup no changes for a while, even in German, and there is another language change if you keep going back... I went all the way back to the oldest retained build, it doesn't seem to have ever picked up any changes. We'll see with my updated cvs..I'd rather write these wrappers in Python, of course. Or Modula-3. Or quake if possible. :) ) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 18 12:53:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:53:43 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> References: , , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Message-ID: Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Thu Nov 18 13:26:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 12:26:32 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: ,,, , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com>, Message-ID: Looking good. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/120/console - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:53:43 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Fri Nov 19 10:12:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 09:12:16 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining Message-ID: parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 11:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 10:01:44 +0000 Subject: [M3devel] bind_segment vs. declare_segment? Message-ID: I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:39:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:39:00 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: Message-ID: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> This is a shame. 1. gcc supports nested functions. 2. gcc supports inlining. 3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong. Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote: > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:43:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:43:03 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: Message-ID: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled. Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote: > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 19 16:36:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Nov 2010 16:36:05 +0100 Subject: [M3devel] m3cc compilation errors Message-ID: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Currently I cannot compile m3cc on AMD64-FREEBSD: ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token gmake: *** [m3cg/parse.o] Error 1 "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg 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 Nov 19 17:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:20:00 +0000 Subject: [M3devel] m3cc compilation errors In-Reply-To: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> References: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Message-ID: book2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c Connection closed by 88.198.39.217 [ I fell asleep] cvs [commit aborted]: end of file from server (consult above messages if any) [ I woke up[ jbook2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v <-- parse.c new revision: 1.458; previous revision: 1.457 - Jay > Date: Fri, 19 Nov 2010 16:36:05 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc compilation errors > > Currently I cannot compile m3cc on AMD64-FREEBSD: > > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token > gmake: *** [m3cg/parse.o] Error 1 > "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake > runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg > > 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: From jay.krell at cornell.edu Fri Nov 19 17:21:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:21:02 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: Good question. I can look into that. But notice that it will *definitely* be different. But maybe not in a critical way -- they use trampolines. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:39:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining This is a shame.1. gcc supports nested functions.2. gcc supports inlining.3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong.Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote:parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:24:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:24:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:41:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:41:24 +0000 Subject: [M3devel] incorrect copying in Hudson? Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_DARWIN/61/console t/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post /rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/ rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/last-ok/ pkg/m3core/src/text: name too long (not copied) I had caused this before manually installing. But I'm not sure I did this time. I'll clean it up. We'll see if it comes bcak. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 18:08:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 17:08:14 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, Message-ID: Another option would be that every time we get an offset load against it, see if it is beyond the current size, in which case grow the size and relayout. That could end up relayout many times. Besides accessing beyond its size, the problem, for configure -enable-checking, is that we later completely replace the type, so returning its address from the module initializer ends up a different type than the actual data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 16:24:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 19:51:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 13:51:49 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: <3586ABC8-1EE1-4E1D-8B81-67450C7E51BA@cs.purdue.edu> The trampoline is purely a method for constructing a closure that can be passed. So long as we are using the same mechanism to grab the static chain we should be working similarly. We just need to emulate the effect of the trampoline on the rest of gcc. On Nov 19, 2010, at 11:21 AM, Jay K wrote: > Good question. I can look into that. But notice that it will *definitely* be different. But maybe not > in a critical way -- they use trampolines. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:39:00 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining > > This is a shame. > 1. gcc supports nested functions. > 2. gcc supports inlining. > 3. gcc should work with both nested functions and inlining. > > If gcc can handle all of this for C but not M3 then we must be doing something wrong. > Can we see how similar code fragments behave when expressed in C? > > On Nov 19, 2010, at 4:12 AM, Jay K wrote: > > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 09:43:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 08:43:56 +0000 Subject: [M3devel] LONGINT in frontend? Message-ID: How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 13:47:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 12:47:41 +0000 Subject: [M3devel] gmp dependency? Message-ID: I already eliminated the mpc and mpfr dependency. They are only used for "builtins", which we never use. And drastically reduced gmp use. These were a big part of building m3cc. The remaining use of gmp appears to only be in tree-ssa-loop-niter.c which determines/estimates the number of times a loop runs, I believe in order to possibly unroll it, or other loop optimizations. Considering removing this, in order to cut the gmp dependency? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 14:02:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 13:02:29 +0000 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? Message-ID: Olaf, I'm not sure Hudson works right in terms of using/copying the right prebuilt cm3cg at the right time. I see evidence of using out of date cm3cg. Given that we don't ever by default clean m3cc. And given that I adjusted stuff to use upgrade.sh and I believe install cm3cg and cm3 together at the right time. But given that I didn't look into or adjust how the pairs of tasks (m3cc and build) interace. Given that I think build works on its own. I request that we stop all the m3cc tasks and remove or at least disable the PREBUILD_CM3CG stuff. i.e. asking agreement/permission. I'm willing to do it. Alternately stated: I understand and can fix if needed upgrade.sh. Though I do use upgrade.py myself, all the time. We should consider it..but they are about the same. Anyway, my point is, I understand, like, "a single workspace" setup. Maybe Hudson should work that way? Now, I understand there is granularity. You want to see some Hudson tasks finish, before others run. So, in the interest of that, I'm very willing to leave m3cc first, and if that succeeds, have build build its own cm3cg. That is wasteful, but can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 15:11:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 14:11:26 +0000 Subject: [M3devel] enable-checking vs. static link Message-ID: So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Nov 20 17:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 20 Nov 2010 11:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: Message-ID: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Target.Int is appropriate here, not LONGINT. Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote: > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 21:55:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 20:55:10 +0000 Subject: [M3devel] enable-checking vs. static link In-Reply-To: References: Message-ID: Alas.. == package /Users/jay/dev2/cm3/m3-tools/m3tk == new source -> compiling StdFormat.m3 ../src/astdisplay/StdFormat.m3: In function 'StdFormat__Enumeration_type': ../src/astdisplay/StdFormat.m3:193:0: internal compiler error: Bus error Please submit a full bug report, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: enable-checking vs. static link Date: Sat, 20 Nov 2010 14:11:26 +0000 So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 22:35:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 21:35:40 +0000 Subject: [M3devel] Hudson vs. ..? Message-ID: Hudson is great. and by ".." I don't mean Tinderbox or any alternative. I mean vs. my own ongoing development. Things are working for me. I build AMD64_DARWIN repeatly, using the built cm3, with -O3. It all works. Sometimes I boot1.py to other platforms, which exercises a fair amount. Yet Hudson is getting various internal compiler errors, on some platforms. e.g. Darwin, Solaris. But not all, I think e.g. FreeBSD, Linux. And it isn't using optimization realize. Possible but unlikely that -O3 is covering up problems. Usually optimization only ever hurts, doesn't help, in terms of getting a successful compilation. I strongly suspect this is due to cm3 vs. cm3cg mismatch. I believe upgrade.sh works. I believe the regression scripts work now, by using upgrade.sh. Except if you run "build" w/o "m3cc" and it picks up old cm3cg. Can we somehow easily "reset" everything? I have tried somewhat, but it was tedious and didn't clearly work. Going back to rel 5.8.6 and then upgrade.sh should work. I don't want to have to visit every node or do my own boot1.py + boot2.sh again. I did that fairly recently, when Hudson was definitely not upgrading cm3/cm3cg properly. I *think* it does now, but I think it got mixed up in some cases. e.g. maybe by building "build" w/o building "m3cc"? Maybe that guarantees it picks up an old mismatched cm3cg? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 01:02:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 01:02:20 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: Message-ID: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Quoting Jay K : > > Hudson is great. > and by ".." I don't mean Tinderbox or any alternative. > I mean vs. my own ongoing development. > > Things are working for me. > I build AMD64_DARWIN repeatly, using the built cm3, with -O3. > > It all works. > > Sometimes I boot1.py to other platforms, which exercises a fair amount. > > Yet Hudson is getting various internal compiler errors, on some platforms. > e.g. Darwin, Solaris. Yes, those are broken currently. > But not all, I think e.g. FreeBSD, Linux. > And it isn't using optimization realize. > Possible but unlikely that -O3 is covering up problems. Usually > optimization > only ever hurts, doesn't help, in terms of getting a successful > compilation. > > I strongly suspect this is due to cm3 vs. cm3cg mismatch. > I believe upgrade.sh works. > I believe the regression scripts work now, by using upgrade.sh. > Except if you run "build" w/o "m3cc" and it picks up old cm3cg. > > Can we somehow easily "reset" everything? > I have tried somewhat, but it was tedious and didn't clearly work. > > Going back to rel 5.8.6 and then upgrade.sh should work. I think we can insert that as a last fallback: build from the last-rel version (which should be 5.8.6). I'll have a look at it tomorrow. > I don't want to have to visit every node or do my own boot1.py + > boot2.sh again. > I did that fairly recently, when Hudson was definitely not upgrading > cm3/cm3cg properly. > I *think* it does now, but I think it got mixed up in some cases. > e.g. maybe by building "build" w/o building "m3cc"? Maybe that > guarantees it picks > up an old mismatched cm3cg? On your own systems (xdarwin) you could easily inject a working pair of cm3/cm3cg into the last-ok pool, that should fix mismatches. 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 Nov 21 01:15:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:15:37 +0000 Subject: [M3devel] Hudson vs. ..? In-Reply-To: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: > On your own systems (xdarwin) you could easily inject a working pair > of cm3/cm3cg into the last-ok pool, that should fix mismatches. Yeah, I thought so, and tried, no luck. I can try again. Later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 01:26:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:26:49 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 13:24:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 13:24:38 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: <20101121132438.dlvido2jgggw8go8@mail.elegosoft.com> Quoting Jay K : > > > On your own systems (xdarwin) you could easily inject a working pair > > of cm3/cm3cg into the last-ok pool, that should fix mismatches. > > Yeah, I thought so, and tried, no luck. > I can try again. Later. I think I've found the reason for that. Let's see if it suffices to get everything into working condition again. 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 Nov 21 14:16:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 14:16:26 +0100 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? In-Reply-To: References: Message-ID: <20101121141626.tmgwxxzaos4ckso0@mail.elegosoft.com> Quoting Jay K : I didn't notice this mail before... see below > Olaf, I'm not sure Hudson works right in terms of using/copying the right > prebuilt cm3cg at the right time. > > I see evidence of using out of date cm3cg. > > Given that we don't ever by default clean m3cc. > And given that I adjusted stuff to use upgrade.sh and I believe > install cm3cg and cm3 together at the right time. > > But given that I didn't look into or adjust how the pairs of tasks > (m3cc and build) interace. > > Given that I think build works on its own. > > I request that we stop all the m3cc tasks and remove or at least > disable the PREBUILD_CM3CG stuff. > i.e. asking agreement/permission. I'm willing to do it. I'm not against disabling all the m3cc tasks and just build m3cc in the usual way in the build jobs. That was just a performance optimization making sense we built release candiate after release candidate again and again on many more platforms than now. I suggest something like this: % cvs diff -u scripts/regression/ Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. cvs diff: Diffing scripts/regression Index: scripts/regression/hudson_build_system.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/regression/hudson_build_system.sh,v retrieving revision 1.21 diff -u -u -r1.21 hudson_build_system.sh --- scripts/regression/hudson_build_system.sh 21 Nov 2010 13:00:38 -0000 1.21 +++ scripts/regression/hudson_build_system.sh 21 Nov 2010 13:14:07 -0000 @@ -37,7 +37,7 @@ ;; esac fi -if [ "$CLEAN" = "false" ]; then +if [ "$CLEAN" = "false" && "$USE_PREBUILT_CM3CG" = "true" ]; then if [ -x "${CM3CG}" ]; then echo "checking for working pre-built cm3cg in ${CM3CG}" cp -p "${CM3CG}" ${WS}/cm3cg > Alternately stated: > I understand and can fix if needed upgrade.sh. > Though I do use upgrade.py myself, all the time. We should > consider it..but they are about the same. > Anyway, my point is, I understand, like, "a single workspace" setup. > Maybe Hudson should work that way? > Now, I understand there is granularity. You want to see some > Hudson tasks finish, > before others run. So, in the interest of that, I'm very willing > to leave m3cc first, > and if that succeeds, have build build its own cm3cg. That is wasteful, but > can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Single build workspace setup should be OK now. Shall I disable all the m3cc jobs? We'll keep all the test jobs though... Olaf PS: The lastok and release installations on your Darwin machine are all empty, see http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/63/console. -- 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 Nov 21 16:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:44:40 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 16:48:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:48:00 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:03:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:03:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> Message-ID: > In general, it is OK for a cross-host to impose smaller restrictions than the target. I don't think I agree. To some extent it is unavoidable: e.g. compiling really really large files However, I ought to be able to do this? typedef struct { int a[1UL << 40]; } foo; foo* a; I can in C, from a 32host to a 64bit target. The way to allow it is reasonably easy, just tedious in Modula- w/o LONGINT or operator overloading. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:48:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:08:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:10:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:10:59 +0000 Subject: [M3devel] operator overloading? Message-ID: Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:33:31 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:33:31 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Some of us find operator overloading anathema because it obscures the actual underlying code. It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain situations. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote: > Isn't it at least better than current situation of using INTEGER? > I understand in the future LONGINT might not suffice and Target.Int might be desired. > But today LONGINT suffices and lets more things work. > > > Granted you can no longer compile with older compilers. > > > Surely what we could at that time is introduce INTEGER128. > Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, > and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? > > > And perhaps by then have switched LONGINT to Target.Int? > Perhaps by then we'll have operator overloading in Modula-3? > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 10:44:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. > > On Nov 20, 2010, at 7:26 PM, Jay K wrote: > > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:50:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:50:22 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , , , , , Message-ID: I disagree there also. 32bit addresses/size_t and 64bit quantities can be mixed reasonably, and have been for a very long time in a *lot* of code. There are plenty of files and volumes over 2GB in size manipulated by 32 bit code. The 32-bit world will continue for a while -- phones, iPad, etc. But yet iPad is available with 64GB storage. Are the 53bits of precision in double for migration to a 53bit world? I agree the *name* LONGINT is a hack though, in the poor tradition of C's "long long". Again again again, 32bit host C compilers have been targeting 64bit targets for a very long time and continue to do so. And I would hope they don't have the same problem we have. I know gcc has this "HOST_WIDE_INT" for this reason -- long long for 32bit hosts targeting 64bit. Obviously a bit inefficient, but probably really ok and worth it. Also, again, I believe our limit is in number of bits, not bytes. So it is even too small for native builds. But I agree, maybe not easy to fix, if the problem is real (I think it is). Bit counts are convenient. I guess maybe this is a good reason to extend Target.Int another byte? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote:Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:53:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:53:55 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: "Obscures the underlying code" is true of so many things. Exceptions. Garbage collection. Objects. Nested functions. Function calls! Default parameters. Generics. Pickles. RPC. It is a matter of degree, cost, value though, granted. The runtime cost of operating overloading is zero, at least. And the unobscured code is horrible to read and write actually (which is the reason for many features). This is case where "obscure" is clearly good, and not obscure. But it is a matter of degree. I should probably try implementing it before I ask for it too strongly. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:33:31 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? Some of us find operator overloading anathema because it obscures the actual underlying code.It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote:Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:08:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking Message-ID: gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:24:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:24:53 +0000 Subject: [M3devel] configure -enable-checking In-Reply-To: References: Message-ID: (ps: we should also be using -O1/-O2/-O3 in some Hudson tasks; or maybe just one -- cm3 accepts -O and then passes down to cm3cg whatever is in the config file..I don't find this model adequate though and I always edit the config; probably better approach is a) environment variable + b) different build_dir; many systems work that way, you don't want too many variants/build_dirs, but 2 isn't unusual ("debug" and "retail" for example)) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Nov 21 20:27:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 21 Nov 2010 11:27:34 -0800 Subject: [M3devel] operator overloading? In-Reply-To: References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: <20101121192734.DB4761A208C@async.async.caltech.edu> I don't like changes in Modula-3, on principle. I have a lot of code that is over ten years old and that I never look at, and I never want to look at, despite the fact that things that I do depend on computers that execute probably billions of instructions in this code every day. Now I depend on such code that depends on being able to parse Modula-3 itself, so the language, I feel should stay both forward- and backward-compatible. (I really don't like LONGINT for that reason.) But that being said, operator overloading seems relatively harmless. It changes the meaning only of executable code, not interfaces, and unless you are writing a compiler, there isn't much reason to be processing the executable code. This is all assuming you do it right. And there must be some way of calling the overloaded operators using functional notation so that generated code can get at them. What has always bugged me about operator overloading in C++ is just what an unabashed hack it is. You can use the operators from C, but no others? And they have to have the same associativity and commutativity rules as in C? And they can be only unary or binary? Does anyone do this better? Is it even possible? I suppose the main thing is to specify a rule for converting a OP b to OP(a,b)... What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And then the associativity rules... is addition left- or right-associative? Who remembers that..? now *that* is obscure. And it won't work on RECORDs or ARRAYs or SETs, which don't have methods... Would it be possible to write a pre-processor using m3tk that would implement the entirety of operator overloading? I think that would be an elegant solution, but I've never used m3tk on implementations... The reason I am saying this is that judging from the syntax equations in the Green Book, it is possible that m3tk might accept a program using overloaded operators, and only semantic analysis on the parsed structure would uncover the overloaded operators and flag them as semantic errors (in standard Modula-3). But I might be wrong. And m3tk might have broken code in it. When we were designing async. hardware with Modula-3 we had a thing called "m3texthack" that would let you do special kinds of macros in Modula-3 code. Your source file would be Module.c3, which would be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 of course). In any case, an m3tk solution rather than a Modula-3 solution would easily allow you to specify different rules for different types, or even for different source files, rather than being tied to something nailed down in the language spec. Mika Jay K writes: >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >"Obscures the underlying code" is true of so many things. >Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >Default parameters. Generics. Pickles. RPC. >It is a matter of degree=2C cost=2C value though=2C granted. > The runtime cost of operating overloading is zero=2C at least. > And the unobscured code is horrible to read and write actually (which is = >the reason for many features). > This is case where "obscure" is clearly good=2C and not obscure. > But it is a matter of degree. I should probably try implementing it befor= >e I ask for it too strongly. > > > - Jay > >From: hosking at cs.purdue.edu >Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] operator overloading? > > > >Some of us find operator overloading anathema because it obscures the actua= >l underlying code.It certainly does not fit well with the design philosophy= > of Modula-3. > >On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > add operator overloading to the language? > >>From a user's point of view=2C I know it is very useful in certain situatio= >ns. > > > - Jay > > > > > > = > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >"Obscures the underlying code" is true of so many things.
Exceptions. Ga= >rbage collection. Objects. Nested functions. Function calls! Default parame= >ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >though=2C granted.
 =3B The runtime cost of operating overloading is= > zero=2C at least.
 =3B And the unobscured code is horrible to read = >and write actually (which is the reason for many features).
 =3B Thi= >s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >ut it is a matter of degree. I should probably try implementing it before I= > ask for it too strongly.


 =3B - Jay

elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >e: [M3devel] operator overloading?

>"> >Some of us find ope= >rator overloading anathema because it obscures the actual underlying code.<= >div>It certainly does not fit well with the design philosophy of Modula-3.<= >br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >
ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >a=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 font-size: med= >ium=3B">
: Tahoma=3B">Is it really so difficult to add operator overloading to the l= >anguage?

From a user's point of view=2C I know it is very useful in = >certain situations.


 =3B- Jay




n>

>= > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From hosking at cs.purdue.edu Sun Nov 21 21:04:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:04:09 -0500 Subject: [M3devel] operator overloading? In-Reply-To: <20101121192734.DB4761A208C@async.async.caltech.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> <20101121192734.DB4761A208C@async.async.caltech.edu> Message-ID: I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > I don't like changes in Modula-3, on principle. I have a lot of code > that is over ten years old and that I never look at, and I never want > to look at, despite the fact that things that I do depend on computers > that execute probably billions of instructions in this code every day. > > Now I depend on such code that depends on being able to parse > Modula-3 itself, so the language, I feel should stay both forward- > and backward-compatible. (I really don't like LONGINT for that > reason.) > > But that being said, operator overloading seems relatively harmless. > It changes the meaning only of executable code, not interfaces, and unless > you are writing a compiler, there isn't much reason to be processing > the executable code. This is all assuming you do it right. And there > must be some way of calling the overloaded operators using functional > notation so that generated code can get at them. > > What has always bugged me about operator overloading in C++ is just > what an unabashed hack it is. You can use the operators from C, > but no others? And they have to have the same associativity and > commutativity rules as in C? And they can be only unary or binary? > Does anyone do this better? Is it even possible? I suppose the main > thing is to specify a rule for converting > > a OP b > > to > > OP(a,b)... > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > then the associativity rules... is addition left- or right-associative? > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > or ARRAYs or SETs, which don't have methods... > > Would it be possible to write a pre-processor using m3tk that would > implement the entirety of operator overloading? I think that would > be an elegant solution, but I've never used m3tk on implementations... > The reason I am saying this is that judging from the syntax equations > in the Green Book, it is possible that m3tk might accept a program using > overloaded operators, and only semantic analysis on the parsed structure > would uncover the overloaded operators and flag them as semantic errors > (in standard Modula-3). But I might be wrong. And m3tk might have > broken code in it. > > When we were designing async. hardware with Modula-3 we had a thing > called "m3texthack" that would let you do special kinds of macros in > Modula-3 code. Your source file would be Module.c3, which would > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > of course). > > In any case, an m3tk solution rather than a Modula-3 solution would easily > allow you to specify different rules for different types, or even for > different source files, rather than being tied to something nailed down > in the language spec. > > Mika > > > > Jay K writes: >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> "Obscures the underlying code" is true of so many things. >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >> Default parameters. Generics. Pickles. RPC. >> It is a matter of degree=2C cost=2C value though=2C granted. >> The runtime cost of operating overloading is zero=2C at least. >> And the unobscured code is horrible to read and write actually (which is = >> the reason for many features). >> This is case where "obscure" is clearly good=2C and not obscure. >> But it is a matter of degree. I should probably try implementing it befor= >> e I ask for it too strongly. >> >> >> - Jay >> >> From: hosking at cs.purdue.edu >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] operator overloading? >> >> >> >> Some of us find operator overloading anathema because it obscures the actua= >> l underlying code.It certainly does not fit well with the design philosophy= >> of Modula-3. >> >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= >> add operator overloading to the language? >> >>> From a user's point of view=2C I know it is very useful in certain situatio= >> ns. >> >> >> - Jay >> >> >> >> >> >> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= >> rbage collection. Objects. Nested functions. Function calls! Default parame= >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >> though=2C granted.
 =3B The runtime cost of operating overloading is= >> zero=2C at least.
 =3B And the unobscured code is horrible to read = >> and write actually (which is the reason for many features).
 =3B Thi= >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >> ut it is a matter of degree. I should probably try implementing it before I= >> ask for it too strongly.


 =3B - Jay

> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >> e: [M3devel] operator overloading?

>> > "> >> Some of us find ope= >> rator overloading anathema because it obscures the actual underlying code.<= >> div>It certainly does not fit well with the design philosophy of Modula-3.<= >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >>
> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >> a=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 font-size: med= >> ium=3B">
> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= >> anguage?

From a user's point of view=2C I know it is very useful in = >> certain situations.


 =3B- Jay




> n>

>> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From rodney_bates at lcwb.coop Sun Nov 21 20:52:08 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 13:52:08 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <4CE97868.3050804@lcwb.coop> I've been around that block too many times with Ada and C++. Programmer- defined overloading (either operator and/or function name) is a semantic disaster. It interacts with stuff all over the language, and the complexity just explodes. I have spent several years of my life having to learn every in and out and dark corner of overloading and all its fallout in Ada, both to implement it and to try to help working programmers cope with it. I can say with complete confidence that Ada would be half the size/complexity it is, without it. Moreover, hard as it is for a compiler writer or language lawyer to understand it, it is even worse for the everyday programmer. Again, I can testify that almost nobody (the above types excepted) comes anywhere close to understanding the rules. They don't even want to try. Their eyes glaze over, and they just want you to tell them how to code such-and-such so it will compile and call the function they want it to. For the future, all they want is restrictive but simple programming guidelines on things to avoid unconditionally, so they won't keep getting burned again and again. C++'s take on overloading is simpler in some respects, more complicated in others, but overall, quite a bit worse and, I dare say, much poorer-understood by working programmers. The upshot is that the (mis)feature of programmer-defined overloading is mostly used only in degenerate and trivial ways. This, of course, raises the question what good is it when: 1) it makes programming more difficult, 2) programmers avoid most of it anyway, and 3) even so, it results in lots of code that programmers just barely hope they understand the meaning of what they wrote. The latter is a *very* big deal in quality of released code. And I didn't even mention the added difficulty in implementing the language. I do realize that function call notation can be a lot harder to read (and write) than operator notation in a few situations. I've also been around that block more times than one, in fact quite recently. I have many times mused over whether it would be possible to add something that would give the most important benefits and not be a complete semantic train wreck. Sometimes I think it could be done a lot better than we have seen, but at best, it would be a significant semantic complication, even if restricted to operators only. In Modula-3, we have a language whose most distinctive characteristic is an exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other language that comes close by this criterion. We need to preserve that. Rodney Bates Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain > situations. > > > - Jay > > > > From jay.krell at cornell.edu Sun Nov 21 21:11:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:11:46 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: > I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 21:14:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:14:08 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: On Nov 21, 2010, at 3:11 PM, Jay K wrote: > > I'm now starting to wish that we had left LONGINT out, > > > Just now? :) > (This is another reason I'm somewhat open to tediously using Target.Int in frontend, > in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > > ARRAY [1..2] OF INTEGER .. same representation as C "long long" > > > These are potentially much different, e.g. when being returned from a function by value. > NT/x86 returns them in the register pair edx:eax. > Granted, it *might* also store small structs that way, but I'm not sure. > (you could bury the array in a struct then as well) > But I guess a small special case would do. > > > Why are sets in the language, with infix operators? > Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. > > > If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. > Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. > > > I have done a *little* bit of Scheme programming, so I at least was at some point > sympathetic to the view of having no infix operators whatsoever. > > > The story of the Dylan programming language is also interesting. > It was originally prefix only but caved and went infix for the sake of > programmer convenience. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 21 Nov 2010 15:04:09 -0500 > > To: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] operator overloading? > > > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > > that is over ten years old and that I never look at, and I never want > > > to look at, despite the fact that things that I do depend on computers > > > that execute probably billions of instructions in this code every day. > > > > > > Now I depend on such code that depends on being able to parse > > > Modula-3 itself, so the language, I feel should stay both forward- > > > and backward-compatible. (I really don't like LONGINT for that > > > reason.) > > > > > > But that being said, operator overloading seems relatively harmless. > > > It changes the meaning only of executable code, not interfaces, and unless > > > you are writing a compiler, there isn't much reason to be processing > > > the executable code. This is all assuming you do it right. And there > > > must be some way of calling the overloaded operators using functional > > > notation so that generated code can get at them. > > > > > > What has always bugged me about operator overloading in C++ is just > > > what an unabashed hack it is. You can use the operators from C, > > > but no others? And they have to have the same associativity and > > > commutativity rules as in C? And they can be only unary or binary? > > > Does anyone do this better? Is it even possible? I suppose the main > > > thing is to specify a rule for converting > > > > > > a OP b > > > > > > to > > > > > > OP(a,b)... > > > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > > then the associativity rules... is addition left- or right-associative? > > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > > or ARRAYs or SETs, which don't have methods... > > > > > > Would it be possible to write a pre-processor using m3tk that would > > > implement the entirety of operator overloading? I think that would > > > be an elegant solution, but I've never used m3tk on implementations... > > > The reason I am saying this is that judging from the syntax equations > > > in the Green Book, it is possible that m3tk might accept a program using > > > overloaded operators, and only semantic analysis on the parsed structure > > > would uncover the overloaded operators and flag them as semantic errors > > > (in standard Modula-3). But I might be wrong. And m3tk might have > > > broken code in it. > > > > > > When we were designing async. hardware with Modula-3 we had a thing > > > called "m3texthack" that would let you do special kinds of macros in > > > Modula-3 code. Your source file would be Module.c3, which would > > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > > of course). > > > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > > allow you to specify different rules for different types, or even for > > > different source files, rather than being tied to something nailed down > > > in the language spec. > > > > > > Mika > > > > > > > > > > > > Jay K writes: > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/plain; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> "Obscures the underlying code" is true of so many things. > > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > > >> Default parameters. Generics. Pickles. RPC. > > >> It is a matter of degree=2C cost=2C value though=2C granted. > > >> The runtime cost of operating overloading is zero=2C at least. > > >> And the unobscured code is horrible to read and write actually (which is = > > >> the reason for many features). > > >> This is case where "obscure" is clearly good=2C and not obscure. > > >> But it is a matter of degree. I should probably try implementing it befor= > > >> e I ask for it too strongly. > > >> > > >> > > >> - Jay > > >> > > >> From: hosking at cs.purdue.edu > > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] operator overloading? > > >> > > >> > > >> > > >> Some of us find operator overloading anathema because it obscures the actua= > > >> l underlying code.It certainly does not fit well with the design philosophy= > > >> of Modula-3. > > >> > > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > > >> add operator overloading to the language? > > >> > > >>> From a user's point of view=2C I know it is very useful in certain situatio= > > >> ns. > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> > > >> > > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/html; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> > > >> > > >> > > >> > > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > > >> and write actually (which is the reason for many features).
 =3B Thi= > > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > > >> ut it is a matter of degree. I should probably try implementing it before I= > > >> ask for it too strongly.


 =3B - Jay

> >> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > > >> e: [M3devel] operator overloading?

> > >> > >> "> > > >> Some of us find ope= > > >> rator overloading anathema because it obscures the actual underlying code.<= > > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > > >>
> >> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > > >> a=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 font-size: med= > > >> ium=3B">
> >> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > > >> anguage?

From a user's point of view=2C I know it is very useful in = > > >> certain situations.


 =3B- Jay




> >> n>

> > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:16:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:16:28 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <4CE97868.3050804@lcwb.coop> References: , <4CE97868.3050804@lcwb.coop> Message-ID: Rodney, what if the signatures of overloaded operators is "fixed". That is + can only take two T's and return one T. < can only take two T's and return one boolean. No implicit conversions. (I do think some conversions are ok, integers to wider integers, but nobody else agrees.) Isn't that much simpler than any other language does it? Are the rules still hard to understand? (And I believe this is still fairly valuable.) Furthermore, something like, maybe, the operators may only be defined in the interface that declares T? Or maybe, the operators are always available on all types, but you get a link error if they weren't defined? And of course, you can't define them for builtin types. They are already defined. And, I realize, there is a question of errors. + can fail. The interface would have to that they raise exceptions. You could have something like FPU.i3 custom per type to control it. The compiler wouldn't know about this (except maybe for builtin LONGINT). - Jay > Date: Sun, 21 Nov 2010 13:52:08 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] operator overloading? > > I've been around that block too many times with Ada and C++. Programmer- > defined overloading (either operator and/or function name) is a semantic > disaster. It interacts with stuff all over the language, and the complexity > just explodes. I have spent several years of my life having to learn every > in and out and dark corner of overloading and all its fallout in Ada, both > to implement it and to try to help working programmers cope with it. I can > say with complete confidence that Ada would be half the size/complexity > it is, without it. > > Moreover, hard as it is for a compiler writer or language lawyer to understand > it, it is even worse for the everyday programmer. Again, I can testify that > almost nobody (the above types excepted) comes anywhere close to understanding > the rules. They don't even want to try. Their eyes glaze over, and they just > want you to tell them how to code such-and-such so it will compile and call > the function they want it to. For the future, all they want is restrictive > but simple programming guidelines on things to avoid unconditionally, so they > won't keep getting burned again and again. > > C++'s take on overloading is simpler in some respects, more complicated in > others, but overall, quite a bit worse and, I dare say, much poorer-understood > by working programmers. > > The upshot is that the (mis)feature of programmer-defined overloading is mostly > used only in degenerate and trivial ways. This, of course, raises the question > what good is it when: 1) it makes programming more difficult, 2) programmers > avoid most of it anyway, and 3) even so, it results in lots of code that > programmers just barely hope they understand the meaning of what they wrote. > The latter is a *very* big deal in quality of released code. And I didn't even > mention the added difficulty in implementing the language. > > I do realize that function call notation can be a lot harder to read (and write) > than operator notation in a few situations. I've also been around that block more > times than one, in fact quite recently. > > I have many times mused over whether it would be possible to add something that > would give the most important benefits and not be a complete semantic train wreck. > Sometimes I think it could be done a lot better than we have seen, but at best, > it would be a significant semantic complication, even if restricted to operators > only. > > In Modula-3, we have a language whose most distinctive characteristic is an > exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other > language that comes close by this criterion. We need to preserve that. > > Rodney Bates > > > Jay K wrote: > > Is it really so difficult to add operator overloading to the language? > > > > From a user's point of view, I know it is very useful in certain > > situations. > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:25:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:25:41 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , , , <20101121192734.DB4761A208C@async.async.caltech.edu>, , , , Message-ID: > What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? I believe m3-libs/arithmetic/src/basictypes/biginteger. Though this arithmetic library is very large and I understand little of it. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 15:14:08 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? On Nov 21, 2010, at 3:11 PM, Jay K wrote:> I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Nov 21 21:56:56 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 14:56:56 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: , <4CE97868.3050804@lcwb.coop> Message-ID: <4CE98798.7060006@lcwb.coop> Jay K wrote: > Rodney, what if the signatures of overloaded operators is "fixed". > That is + can only take two T's and return one T. > < can only take two T's and return one boolean. > That is one of the ways that would greatly simplify the semantics. It would also make it more difficult for programmers to define operator meanings with no resemblance to traditional mathematical meanings of the operators, which I regard as really bad practice, but is encouraged by the overloading systems I know about. > > No implicit conversions. > (I do think some conversions are ok, integers to wider integers, but > nobody else agrees.) We already have something far better than implied conversions. We have assignability, which, simplified, says that in a lot of assignment-like contexts, what is needed is that the RHS _value_ must be a member of the LHS's _type_. The types are not necessarily disjoint, so there are lots of cases where this accomplishes something. Enforcing this requires a mix of static and runtime rules. Obviously, if the RHS type is disjoint with the LHS type, that is statically know to be illegal. When it's legally assignable, Modula-3 doesn't call it a type conversion. This is higher-level and more abstract. There may well be an implied _representation_ conversion, for example, different sizes of integers. Most (all?) other languages require that every different machine-level representation be a different type, and this creates a need for programmer-awareness of lots more type conversions, implicit or explicit, than the Modula-3 approach We didn't get assignability between INTEGER and LONGINT, but we have it between a base ordinal type and all its subranges and all their packed types (subject to value inclusion.) as well as several other cases. > Isn't that much simpler than any other language does it? I think it can be a lot simpler than any other language. There is still a _lot_ of unanticipated detail. > Are the rules still hard to understand? > (And I believe this is still fairly valuable.) > > > Furthermore, something like, maybe, the operators may only be defined in > the interface that declares T? > Or maybe, the operators are always available on all types, but you get a > link error if they weren't defined? > I can think of another visibility rule, but it derives from other things I would have to describe first. > > And of course, you can't define them for builtin types. They are already > defined. > Yes, I would strongly support that rule. (Did you know Ada does not?) > > And, I realize, there is a question of errors. > + can fail. > The interface would have to that they raise exceptions. > You could have something like FPU.i3 custom per type to control it. The > compiler > wouldn't know about this (except maybe for builtin LONGINT). > I think exception raising can be kept orthogonal to operator overloading by defining an operator expression (once resolved to a single function) as equivalent to an ordinary call. In fact, everything except determining what function is to be called can be defined by an equivalence to an ordinary call of that function. > > - Jay > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] operator overloading? > > > > I've been around that block too many times with Ada and C++. Programmer- > > defined overloading (either operator and/or function name) is a semantic > > disaster. It interacts with stuff all over the language, and the > complexity > > just explodes. I have spent several years of my life having to learn > every > > in and out and dark corner of overloading and all its fallout in Ada, > both > > to implement it and to try to help working programmers cope with it. > I can > > say with complete confidence that Ada would be half the size/complexity > > it is, without it. > > > > Moreover, hard as it is for a compiler writer or language lawyer to > understand > > it, it is even worse for the everyday programmer. Again, I can > testify that > > almost nobody (the above types excepted) comes anywhere close to > understanding > > the rules. They don't even want to try. Their eyes glaze over, and > they just > > want you to tell them how to code such-and-such so it will compile > and call > > the function they want it to. For the future, all they want is > restrictive > > but simple programming guidelines on things to avoid unconditionally, > so they > > won't keep getting burned again and again. > > > > C++'s take on overloading is simpler in some respects, more > complicated in > > others, but overall, quite a bit worse and, I dare say, much > poorer-understood > > by working programmers. > > > > The upshot is that the (mis)feature of programmer-defined overloading > is mostly > > used only in degenerate and trivial ways. This, of course, raises the > question > > what good is it when: 1) it makes programming more difficult, 2) > programmers > > avoid most of it anyway, and 3) even so, it results in lots of code that > > programmers just barely hope they understand the meaning of what they > wrote. > > The latter is a *very* big deal in quality of released code. And I > didn't even > > mention the added difficulty in implementing the language. > > > > I do realize that function call notation can be a lot harder to read > (and write) > > than operator notation in a few situations. I've also been around > that block more > > times than one, in fact quite recently. > > > > I have many times mused over whether it would be possible to add > something that > > would give the most important benefits and not be a complete semantic > train wreck. > > Sometimes I think it could be done a lot better than we have seen, > but at best, > > it would be a significant semantic complication, even if restricted > to operators > > only. > > > > In Modula-3, we have a language whose most distinctive characteristic > is an > > exceptionally high ratio of useful stuff to complexity. AFAIK, there > is no other > > language that comes close by this criterion. We need to preserve that. > > > > Rodney Bates > > > > > > Jay K wrote: > > > Is it really so difficult to add operator overloading to the language? > > > > > > From a user's point of view, I know it is very useful in certain > > > situations. > > > > > > > > > - Jay > > > > > > > > > > > > From dabenavidesd at yahoo.es Mon Nov 22 04:04:23 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 22 Nov 2010 03:04:23 +0000 (GMT) Subject: [M3devel] operator overloading? In-Reply-To: <4CE98798.7060006@lcwb.coop> Message-ID: <16723.97158.qm@web29716.mail.ird.yahoo.com> Hi all: perhaps in behalf of this issue, one remembers the rules for the type inference algorithms are of variable complexity depending on the semantics or what one calls meaning but also syntaic aids, not like syntatic sugared language constructs but syntax directed checking, and if you want to look an example please look at javascript type inference vs Obliq Modula-3 runtime type inference (which uses m3tk lib by the way), it tourns out that the semantics (object oriented dynamically typed based languages) are quite different in terms of type checking, i.e given Obliq algorithm may checks up to in O[n^5] order but could be less according to certain conditions but in terms of the javascript kernel considered in an research work is not that quick by now, but remains in general as an open issue, perhaps waiting for someone who gets a Turing Award for it ( see http://jiangxi.cs.uwm.edu/publication/js.pdf ) Please consider no just simplicity of our thoughts but of our algorithms, specially when someone has code that already dependends on parsing Modula-3 statements all the day long by many millions of instruction per second. Thanks in advance --- El dom, 21/11/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] operator overloading? > Para: "m3devel" > Fecha: domingo, 21 de noviembre, 2010 15:56 > > > Jay K wrote: > > Rodney, what if the signatures of overloaded operators > is "fixed". > > That is + can only take two T's and return one T. > > < can only take two T's and return one boolean. > > > > That is one of the ways that would greatly simplify the > semantics. > It would also make it more difficult for programmers to > define > operator meanings with no resemblance to traditional > mathematical > meanings of the operators, which I regard as really bad > practice, > but is encouraged by the overloading systems I know about. > > > > > No implicit conversions. > > (I do think some conversions are ok, > integers to wider integers, but nobody else agrees.) > > We already have something far better than implied > conversions. We have > assignability, which, simplified, says that in a lot of > assignment-like > contexts, what is needed is that the RHS _value_ must be a > member of the > LHS's _type_. The types are not necessarily disjoint, > so there are lots > of cases where this accomplishes something. Enforcing > this requires a > mix of static and runtime rules. Obviously, if the > RHS type is disjoint > with the LHS type, that is statically know to be illegal. > > When it's legally assignable, Modula-3 doesn't call it a > type conversion. > This is higher-level and more abstract. There may > well be an implied > _representation_ conversion, for example, different sizes > of integers. > Most (all?) other languages require that every different > machine-level > representation be a different type, and this creates a need > for > programmer-awareness of lots more type conversions, > implicit or explicit, > than the Modula-3 approach > > We didn't get assignability between INTEGER and LONGINT, > but we have > it between a base ordinal type and all its subranges and > all their > packed types (subject to value inclusion.) as well as > several other > cases. > > > Isn't that much simpler than any other language does > it? > > I think it can be a lot simpler than any other > language. There is > still a _lot_ of unanticipated detail. > > > Are the rules still hard to understand? > > (And I believe this is still fairly > valuable.) > > > > > > Furthermore, something like, maybe, the operators may > only be defined in the interface that declares T? > > Or maybe, the operators are always available on all > types, but you get a link error if they weren't defined? > > > > I can think of another visibility rule, but it derives from > other things > I would have to describe first. > > > > > And of course, you can't define them for builtin > types. They are already defined. > > > > Yes, I would strongly support that rule. (Did you > know Ada does not?) > > > > > And, I realize, there is a question of errors. > > + can fail. > > The interface would have to that they raise > exceptions. > > You could have something like FPU.i3 custom per type > to control it. The compiler > > wouldn't know about this (except maybe for builtin > LONGINT). > > > > I think exception raising can be kept orthogonal to > operator overloading by > defining an operator expression (once resolved to a single > function) as > equivalent to an ordinary call. In fact, everything > except determining > what function is to be called can be defined by an > equivalence to an > ordinary call of that function. > > > > > - Jay > > > > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] operator > overloading? > > > > > > I've been around that block too many times > with Ada and C++. Programmer- > > > defined overloading (either operator and/or > function name) is a semantic > > > disaster. It interacts with stuff all over > the language, and the complexity > > > just explodes. I have spent several years > of my life having to learn every > > > in and out and dark corner of overloading > and all its fallout in Ada, both > > > to implement it and to try to help working > programmers cope with it. I can > > > say with complete confidence that Ada would > be half the size/complexity > > > it is, without it. > > > > > > Moreover, hard as it is for a compiler > writer or language lawyer to understand > > > it, it is even worse for the everyday > programmer. Again, I can testify that > > > almost nobody (the above types excepted) > comes anywhere close to understanding > > > the rules. They don't even want to try. > Their eyes glaze over, and they just > > > want you to tell them how to code > such-and-such so it will compile and call > > > the function they want it to. For the > future, all they want is restrictive > > > but simple programming guidelines on things > to avoid unconditionally, so they > > > won't keep getting burned again and again. > > > > > > C++'s take on overloading is simpler in > some respects, more complicated in > > > others, but overall, quite a bit worse and, > I dare say, much poorer-understood > > > by working programmers. > > > > > > The upshot is that the (mis)feature of > programmer-defined overloading is mostly > > > used only in degenerate and trivial ways. > This, of course, raises the question > > > what good is it when: 1) it makes > programming more difficult, 2) programmers > > > avoid most of it anyway, and 3) even so, it > results in lots of code that > > > programmers just barely hope they > understand the meaning of what they wrote. > > > The latter is a *very* big deal in quality > of released code. And I didn't even > > > mention the added difficulty in > implementing the language. > > > > > > I do realize that function call notation > can be a lot harder to read (and write) > > > than operator notation in a few situations. > I've also been around that block more > > > times than one, in fact quite recently. > > > > > > I have many times mused over whether it > would be possible to add something that > > > would give the most important benefits and > not be a complete semantic train wreck. > > > Sometimes I think it could be done a lot > better than we have seen, but at best, > > > it would be a significant semantic > complication, even if restricted to operators > > > only. > > > > > > In Modula-3, we have a language whose most > distinctive characteristic is an > > > exceptionally high ratio of useful stuff to > complexity. AFAIK, there is no other > > > language that comes close by this > criterion. We need to preserve that. > > > > > > Rodney Bates > > > > > > > > > Jay K wrote: > > > > Is it really so difficult to add > operator overloading to the language? > > > > > > > > From a user's point of view, I know it > is very useful in certain > > > > situations. > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > From wagner at elegosoft.com Mon Nov 22 07:56:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Nov 2010 07:56:31 +0100 Subject: [M3devel] latest regressions Message-ID: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> out of memory on FreeBSD4: cc1plus: out of memory allocating 235058936 bytes gmake: *** [insn-recog.o] Error 1 "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console m3cc compilation failure on PPC_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console 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 Nov 22 08:20:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: [M3devel] latest regressions In-Reply-To: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> Message-ID: Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 08:28:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:28:16 +0000 Subject: [M3devel] latest regressions In-Reply-To: References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com>, Message-ID: I'll see if PPC_DARWIN error can be reproduced building a cross compiler. It should be. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: Re: [M3devel] latest regressions Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 21:25:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 20:25:54 +0000 Subject: [M3devel] I386_DARWIN Message-ID: I386_DARWIN is still broken http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/84/console but probably just needs to restart with a known good cm3cg, I'll get to that later. (I'm hoping that the update of cm3/cm3cg in the "middle" of upgrade.sh doesn't go into last-ok/current until the end of the task, in case of a mistake.) - Jay From jay.krell at cornell.edu Tue Nov 23 01:23:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 00:23:03 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. I think. Right? So here it could do that just as well. Right? - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:43:03 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > declare_segment doesn't have the size because it is unknown at the time > of the declaration, which comes before the module is compiled. > Only as the module is compiled does the size become known, with > Bind_segment emitted at the end. > > > On Nov 19, 2010, at 5:01 AM, Jay K wrote: > > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > > From hosking at cs.purdue.edu Tue Nov 23 02:17:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 20:17:54 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > I think. Right? > So here it could do that just as well. Right? > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 19 Nov 2010 09:43:03 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> declare_segment doesn't have the size because it is unknown at the time >> of the declaration, which comes before the module is compiled. >> Only as the module is compiled does the size become known, with >> Bind_segment emitted at the end. >> >> >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >> >> I'm not looking at m3front. I should. >> >> Why does declare_segment not have the size? >> >> I'm going to just live with whatever the frontend does for now. >> Make an extra pass to find the bind_segments, so that when >> I do things "for real", declare_segment can set the size correctly. >> >> Later I'll do better -- making the segment contain fields. >> So that globals become debuggable, in stock gdb (as big records). >> >> But first I want configure enable-checking to work. >> (with one exception, the static link stuff..) >> >> - Jay >> >> >> >> >> From jay.krell at cornell.edu Tue Nov 23 02:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 01:51:11 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. And, it could be "fixed" by adding an additional pass? And, you didn't say this, we very well could/should, if all the backends needed it? Or if it was cheap enough? You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. Or at least in the backend that could easily benefit from it. But actually there's probably another way. I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 20:17:54 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > > Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > > > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > > I think. Right? > > So here it could do that just as well. Right? > > > > - Jay > > > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> declare_segment doesn't have the size because it is unknown at the time > >> of the declaration, which comes before the module is compiled. > >> Only as the module is compiled does the size become known, with > >> Bind_segment emitted at the end. > >> > >> > >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >> > >> I'm not looking at m3front. I should. > >> > >> Why does declare_segment not have the size? > >> > >> I'm going to just live with whatever the frontend does for now. > >> Make an extra pass to find the bind_segments, so that when > >> I do things "for real", declare_segment can set the size correctly. > >> > >> Later I'll do better -- making the segment contain fields. > >> So that globals become debuggable, in stock gdb (as big records). > >> > >> But first I want configure enable-checking to work. > >> (with one exception, the static link stuff..) > >> > >> - Jay > >> > >> > >> > >> > >> > From hosking at cs.purdue.edu Tue Nov 23 03:59:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 21:59:29 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > And, it could be "fixed" by adding an additional pass? No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > And, you didn't say this, we very well could/should, if all the backends needed it? > Or if it was cheap enough? > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > Or at least in the backend that could easily benefit from it. > But actually there's probably another way. > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). Yes, I think that would be better. > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 20:17:54 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >> >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >> >>> >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>> I think. Right? >>> So here it could do that just as well. Right? >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> declare_segment doesn't have the size because it is unknown at the time >>>> of the declaration, which comes before the module is compiled. >>>> Only as the module is compiled does the size become known, with >>>> Bind_segment emitted at the end. >>>> >>>> >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>> >>>> I'm not looking at m3front. I should. >>>> >>>> Why does declare_segment not have the size? >>>> >>>> I'm going to just live with whatever the frontend does for now. >>>> Make an extra pass to find the bind_segments, so that when >>>> I do things "for real", declare_segment can set the size correctly. >>>> >>>> Later I'll do better -- making the segment contain fields. >>>> So that globals become debuggable, in stock gdb (as big records). >>>> >>>> But first I want configure enable-checking to work. >>>> (with one exception, the static link stuff..) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >> From jay.krell at cornell.edu Tue Nov 23 04:59:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 03:59:23 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: > It's inevitable that we have types referenced before defined because of recursion in the type definitions. "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. Er, but you said reference before defined, not referenced before forward declared. Is it inevitable, say, to have a pointer to a record before declaring that the record exists? Seems unlikely. Is there really recursion, or just..some graph? Again something the frontend maybe could resolve but doesn't? Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) A point here is, really, I'm still trying to get the better-typed trees. Even though I went out on a tangent getting configure -enable-checking to work. -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. - Jay ---------------------------------------- > Subject: Re: [M3devel] bind_segment vs. declare_segment? > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 21:59:29 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > > > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > > And, it could be "fixed" by adding an additional pass? > > No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > > > And, you didn't say this, we very well could/should, if all the backends needed it? > > Or if it was cheap enough? > > > > > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > > Or at least in the backend that could easily benefit from it. > > But actually there's probably another way. > > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). > > Yes, I think that would be better. > > > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 22 Nov 2010 20:17:54 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > >> > >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > >> > >>> > >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > >>> I think. Right? > >>> So here it could do that just as well. Right? > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >>>> > >>>> declare_segment doesn't have the size because it is unknown at the time > >>>> of the declaration, which comes before the module is compiled. > >>>> Only as the module is compiled does the size become known, with > >>>> Bind_segment emitted at the end. > >>>> > >>>> > >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >>>> > >>>> I'm not looking at m3front. I should. > >>>> > >>>> Why does declare_segment not have the size? > >>>> > >>>> I'm going to just live with whatever the frontend does for now. > >>>> Make an extra pass to find the bind_segments, so that when > >>>> I do things "for real", declare_segment can set the size correctly. > >>>> > >>>> Later I'll do better -- making the segment contain fields. > >>>> So that globals become debuggable, in stock gdb (as big records). > >>>> > >>>> But first I want configure enable-checking to work. > >>>> (with one exception, the static link stuff..) > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> > >>>> > >> > From jay.krell at cornell.edu Tue Nov 23 08:26:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:26:30 +0000 Subject: [M3devel] configure -enable-checking Message-ID: The ridiculous cross product tests I put in p240 actually do cover stuff not covered anywhere else in the tree, seemingly. ../AMD64_DARWIN/Divide.m3: In function 'Divide__Divide_var_C_C': ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5567 = D.5565 /[ex] D.5566; ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5573 = D.5571 /[ex] D.5572; ../AMD64_DARWIN/Divide.m3:634:0: internal compiler error: verify_stmts failed jbook2:p240 jay$ wc -l AMD64_DARWIN/*.m3 46913 total :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 08:57:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:57:56 +0000 Subject: [M3devel] cardinal vs. word, divide? Message-ID: So, here are two maybe interesting cases. At least to jog my brain and help make sense of the system. DIV vs. Word.Divide of CARDINAL. u is for unsigned, or word C is for Cardinal. Cardinal is [0..LAST(INTEGER)]. <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 (5582) div type:int_64 (5583) check_lo type:int_64 0 code:1 (5584) exit_proc type:word_64 (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 (5574) div type:word_64 (5575) exit_proc type:int_64 (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C Thoughts? Is it right for the load to convert from word to int? (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) I can see how makes sense. CARDINAL is just a subrange of INTEGER. So it is INTEGER. If/when we are clever, we can represent the subranges in the types in the backend, and the optimizer should notice, and these would generate identical code, if they don't already. But the return types of the divides vary as well. There do exist unsigned types at this level. Does that imply that a,b:CARDINAL Word.Or(a, 0) DIV Word.Or(b, 0) is different than a DIV b? I guess so. Different code at least. Given that cardinal is "half range", the results should always match. That is, really, other than added/missing range checks, CARDINAL will always act the same as INTEGER. So then the unsigned types..don't mean anything? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 09:33:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 08:33:00 +0000 Subject: [M3devel] bit field operations for insert/extract Message-ID: Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 11:44:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 10:44:01 +0000 Subject: [M3devel] optimizer vs. gc? Message-ID: so.."the literate" (actually posts to usenet by people who worked on Modula-3 compilers!) warns about the following sort of thing: void F1(char* a, char* b) { int c; for (c = 10; c < 20; ++c) { a[c] = b[c]; } } getting transformed into something like: void F1(char* a, char* b) { int c; a += 10; b += 10; for (c = 0; c < 10; ++c) { a[c] = a[c]; } } actually it warns about something trickier, but this is the best I can come up with that I understand, off the top of my head. => "interior pointers" => "no gc roots in registers or on stack" Should we be concerned? Does our GC handle this? Should we, like, mark all stores volatile but not all loads? And maybe all parameters??? And maybe copy them into non-volatile locals? The trickier warning is something where the difference of the array bases is what is in registers, not merely an interior pointer. I searched a while but couldn't find it. It is probably by David Chase. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:28:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:28:12 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <8570A188-D9CF-4AF3-AAF1-B6A1459F6495@cs.purdue.edu> I'd have to think a bit more about this. I'm still not sure what the issue is for you in the back end. On Nov 22, 2010, at 10:59 PM, Jay K wrote: > >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From hosking at cs.purdue.edu Tue Nov 23 15:35:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:35:05 -0500 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <72D18BD8-B615-4269-98F2-82CC25A05ECA@cs.purdue.edu> Word.Or(a, 0) always has type Word.T, which is currently defined to be INTEGER. Word.Divide takes two Word.T, treats them as unsigned, and performs unsigned division on them, returning the bits as Word.T. DIV takes two INTEGERs and performs signed division on them. What was the question again? On Nov 23, 2010, at 2:57 AM, Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:37:00 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: Message-ID: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote: > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:46:41 -0500 Subject: [M3devel] optimizer vs. gc? In-Reply-To: References: Message-ID: I assume you are referring to: @article{boeh92, author = "Hans-Juergen Boehm and David R. Chase", title = "A Proposal for Garbage-Collector-Safe {C} Compilation", journal = "Journal of C Language Translation", mon = dec, year = 1992, pages = "126--141", URL = {http://reality.sgi.com/employees/boehm_mti/papers/boecha.ps.gz} } So long as the stacks have a pointer to anywhere on the heap page on which the object lies then it will not get reclaimed by our collector. I'd be surprised if gcc performs optimizations that break our collector. On Nov 23, 2010, at 5:44 AM, Jay K wrote: > so.."the literate" (actually posts to usenet > by people who worked on Modula-3 compilers!) > warns about the following sort of thing: > > void F1(char* a, char* b) > { > int c; > for (c = 10; c < 20; ++c) > { > a[c] = b[c]; > } > } > > getting transformed into something like: > > void F1(char* a, char* b) > { > int c; > a += 10; > b += 10; > for (c = 0; c < 10; ++c) > { > a[c] = a[c]; > } > } > > > actually it warns about something trickier, but this > is the best I can come up with that I understand, > off the top of my head. > > > => "interior pointers" > => "no gc roots in registers or on stack" > > > Should we be concerned? > Does our GC handle this? > > > Should we, like, mark all stores volatile but not all loads? > And maybe all parameters??? > And maybe copy them into non-volatile locals? > > The trickier warning is something where > the difference of the array bases is what is in registers, not merely an interior pointer. > I searched a while but couldn't find it. > It is probably by David Chase. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Nov 23 17:52:37 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 10:52:37 -0600 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <4CEBF155.3050703@lcwb.coop> Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE > uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN > Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE > Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV > b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C > Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C > Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only > conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. Same result value, for all a,b. The code should only differ if the compiler does not optimize away the noop Word.Or operations. At the language semantics level, applying a builtin operator like DIV or Word.Or to a subrange (CARDINAL) is like passing the subrange value to a procedure that takes an INTEGER formal parameter of VALUE mode. The actual must be 'assignable' to the formal, which is the case in all these examples, without runtime checks. There could be a representation change generated by the compiler (this is _not_ an implied type conversion), though that doesn't happen here, since surely CARDINAL will always be represented the same as INTEGER. If a were, say, [-128..127] or smaller, the compiler might well have represented/stored it in a (signed) byte, and would then have to do a representation conversion by expanding and sign-extending into a full word before applying the operator to it. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > I'd say yes, except when attached to the div operator. Most languages have different types for signed and unsigned. Then the same operator, applied to the different types does different things. These are (language-defined) overloaded operators. In the case of signed vs. unsigned, Modula-3 turns it around. There is only one type INTEGER=Word.T. Instead, there are different operators for the signed/unsigned operations: DIV vs. Word.Divide. They just apply different interpretations to the same bits. From these examples and some brief looks at M3x83.m3, it looks like the M3 backend system is designed to reflect the more common source language system of different types, with the front end having propagated a copy of the operand type to the operator too. I don't know how the gcc tree system works, but I'd bet it too uses different types. The way that I would match the Modula-3 semantics to the gcc system would be to keep everything in a signed type, except when an unsigned operator comes along. Then convert to unsigned, apply the unsigned operator, and convert back to signed. The conversions used would have to be LOOPHOLE-like in just reinterpreting the bits without changing them. No sign-check going to unsigned and no sign-extension coming back. So the only reason to need conversions at all is if gcc matches types of operands to types of operators and chokes on mismatch. I can see why the div operator needs separate types word_64 or int_64 attached to distinguish which operation is to be done. I can't see why the operand types need such a distinction at all, why the type is changed in the load, or why the source and destination types are what they are. The distinction might not actually mean much on the operands. > > - Jay > > > > From rodney_bates at lcwb.coop Tue Nov 23 18:21:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 11:21:04 -0600 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <4CEBF800.7050401@lcwb.coop> Jay K wrote: > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > It is inevitable that many programs will need to have types that refer to each other in recursive fashion. Just a simple linked list node needs a link pointer. The pointer's definition refers to the node's and vice-versa. with more than one node type, and links among them, it gets more complicated. Something has to come first, and it has to have a forward reference to something that comes later. There are various systems in various languages to support this. Most languages allow some way of splitting a type definition into two parts. One gives only partial information about the type, not enough to need the reference to the other type in the cycle. This could be the "declaring that the record exists" you mention. The other type can be declared next, referring to the incomplete type in some limited ways. Then the completion of the first type comes last. For example, it is usually possible to define a pointer to an incompletely-defined type. And this works OK for a compiler, which really only needs to know its size at this point, and all pointers are the same size. So we only need to know the referent is a type, but not what type, to define a pointer to it. Modula-3 is unusual in saying that all declarations in a single scope are made simultaneously. This is rather abstract talk for saying one declaration can make a forward reference to another declaration in the same scope. (Note that this changes the way redeclaring an identifier in an inner scope works.) Then there are separate rules limiting what kinds of recursion are legal in declarations. For example, records R1 and R2 can contain pointers to each other, but not imbedded instances of each other. (That would have infinite size.) A compiler can handle this in two passes, one to collect all the identifiers declared in the scope (and probably as much information about them as does not depend on any other referred-to declaration.) The second can then check the recursion rules and complete all attributes of the declared entities. > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> From jay.krell at cornell.edu Tue Nov 23 19:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 18:46:06 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. The change would be to remove those. - Jay Subject: Re: [M3devel] bit field operations for insert/extract From: hosking at cs.purdue.edu Date: Tue, 23 Nov 2010 09:37:00 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote:Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 20:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 19:51:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <4CEBF800.7050401@lcwb.coop> References: , , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , , , , , , <4CEBF800.7050401@lcwb.coop> Message-ID: > > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. As long as it is a pointer, I think that is easy and I understand. But granted, I think it is messed up in m3 today. I think m3front always says: record with n fields immediately followed by n fields And there is no forward declaration mechanism. We could probably use forward declare record That just gives the typeid. I have to look in more detail. I'm just speaking from memory here, and not all of the details have ever been, let alone remain, in my memory. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 22:34:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 16:34:25 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: Are they wrong? Seems strange that they worked previously! On Nov 23, 2010, at 1:46 PM, Jay K wrote: > None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 22:46:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 21:46:02 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: Let me clarify. Remember when you used bit field operations for extract_mn? And they didn't work on any big endian system? And I had to undo it? With your approval. I believe the way to go: the change you did in parse.c; it was correct, highly likely removing those endian checks in m3front, which you didn't do at the time Removing the endian checks will only affect big endian. The code reads something like: if little_endian extract_mn(offset, count) else extract_mn(size - offset, size - count) So just change it to: extract_mn(offset, count) And I strongly suspect it will affect it "in the right way". But I'm going to try diffing assembly before/after to be sure. And then watch the sparc and ppc hudson builds. :) (and fix PPC_DARWIN beforehand as well) This is perhaps an interface change in m3cg, but there are no other big endian backends and there are no other uses of extract_mn in the frontend, I think. i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. Anyway, still speculation at this point. But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; perhaps it is best to just leave everything asis...?) and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) - Jay ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 16:34:25 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Are they wrong? Seems strange that they worked previously! > > On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > None yet. But notice the endian checks around the insert_mn or > extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the > endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, > again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems > suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full > value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > > From hosking at cs.purdue.edu Tue Nov 23 23:46:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 17:46:06 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: If that's the case then I would argue for adjusting the offset accordingly in parse.c. extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > Let me clarify. > Remember when you used bit field operations for extract_mn? > And they didn't work on any big endian system? > And I had to undo it? With your approval. > > > I believe the way to go: > the change you did in parse.c; it was correct, highly likely > removing those endian checks in m3front, which you didn't do at the time > > > Removing the endian checks will only affect big endian. > The code reads something like: > if little_endian extract_mn(offset, count) > else extract_mn(size - offset, size - count) > > > So just change it to: > extract_mn(offset, count) > > > And I strongly suspect it will affect it "in the right way". > But I'm going to try diffing assembly before/after to be sure. > And then watch the sparc and ppc hudson builds. :) > (and fix PPC_DARWIN beforehand as well) > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > and there are no other uses of extract_mn in the frontend, I think. > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > Anyway, still speculation at this point. > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > perhaps it is best to just leave everything asis...?) > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > - Jay > > > ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 16:34:25 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Are they wrong? Seems strange that they worked previously! >> >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: >> >> None yet. But notice the endian checks around the insert_mn or >> extract_mn uses in cg.m3. >> The change would be to remove those. >> >> - Jay >> >> >> ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 09:37:00 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Refresh my memory. What m3front change did you make? >> >> >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: >> >> Tony, I'm going to try again to use bitfield operations for extract_mn. >> And insert_mn. >> I think I know what went wrong before for extract_mn: just remove the >> endian check in m3front. >> But I'm going to be sure test p240 covers it well. >> >> The easy part, duh, your original extract_mn was correct I think, just, >> again, missing the m3front change. >> >> Insert_mn is less obvious. >> I started writing it... bitfield_ref..modify_expr...uh, seems >> suspicious, to be modifying an existing value. >> >> I guess it's more like, that, but with a temp that starts with the full >> value of x: >> create temp >> modify(temp, x) >> modify(bitfield_ref(temp, count, offset), y); >> m3_load(temp) >> >> ? >> >> I'll try something like that. >> It seems unfortunate. >> Maybe we can know if x is already a value and not a variable? >> >> >> - Jay >> >> >> From jay.krell at cornell.edu Tue Nov 23 23:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 22:53:25 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , Message-ID: Fair enough, easy enough. I'd want to double check that the existing use is wanting that interpretation. Obviously for that matter, we can leave the code asis for big endian. And just take your code as it was, but under if (target_is_little_endian). Big endian is the minority anyway. :) (no, I won't do that) It would be cool if the frontend never checked target endianness. It does it very little as it is. But ok either way. (I want to move the Target.m3 stuff to the config files -- endianness, setjmp name, jmpbuf size/align, etc., though that's about all that is left) - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 17:46:06 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bit field operations for insert/extract > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > Let me clarify. > > Remember when you used bit field operations for extract_mn? > > And they didn't work on any big endian system? > > And I had to undo it? With your approval. > > > > > > I believe the way to go: > > the change you did in parse.c; it was correct, highly likely > > removing those endian checks in m3front, which you didn't do at the time > > > > > > Removing the endian checks will only affect big endian. > > The code reads something like: > > if little_endian extract_mn(offset, count) > > else extract_mn(size - offset, size - count) > > > > > > So just change it to: > > extract_mn(offset, count) > > > > > > And I strongly suspect it will affect it "in the right way". > > But I'm going to try diffing assembly before/after to be sure. > > And then watch the sparc and ppc hudson builds. :) > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > and there are no other uses of extract_mn in the frontend, I think. > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > Anyway, still speculation at this point. > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > perhaps it is best to just leave everything asis...?) > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > - Jay > > > > > > ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Are they wrong? Seems strange that they worked previously! > >> > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > >> > >> None yet. But notice the endian checks around the insert_mn or > >> extract_mn uses in cg.m3. > >> The change would be to remove those. > >> > >> - Jay > >> > >> > >> ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Refresh my memory. What m3front change did you make? > >> > >> > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > >> > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > >> And insert_mn. > >> I think I know what went wrong before for extract_mn: just remove the > >> endian check in m3front. > >> But I'm going to be sure test p240 covers it well. > >> > >> The easy part, duh, your original extract_mn was correct I think, just, > >> again, missing the m3front change. > >> > >> Insert_mn is less obvious. > >> I started writing it... bitfield_ref..modify_expr...uh, seems > >> suspicious, to be modifying an existing value. > >> > >> I guess it's more like, that, but with a temp that starts with the full > >> value of x: > >> create temp > >> modify(temp, x) > >> modify(bitfield_ref(temp, count, offset), y); > >> m3_load(temp) > >> > >> ? > >> > >> I'll try something like that. > >> It seems unfortunate. > >> Maybe we can know if x is already a value and not a variable? > >> > >> > >> - Jay > >> > >> > >> > From jay.krell at cornell.edu Thu Nov 25 11:52:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 10:52:56 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: <4CB2D03D.8080608@wickensonline.co.uk> References: , <1286270642.3514.3.camel@boromir.m3w.org>, , <4CB1F4CD.4020101@wickensonline.co.uk>, , <4CB2C557.70704@wickensonline.co.uk> , <4CB2D03D.8080608@wickensonline.co.uk> Message-ID: [again, sorry] Another chance on some items, people here will get big discounts. working SGI Fuel good fast SGI workstation runs Irix and should run OpenBSD http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651922577 AlphaServer 800 5/400, doesn't seem to work http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651918789 HPPA machine that can run Linux and HP-UX; works; loud; no video out, need to use serial console (over which I was able to install both Linux and HP-UX) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651902023 Anyone here can negotiate me way way way down, esp. if you provide me ssh access. AlphaServer would go for just half shipping for example. The rest probably $50-$100 + shipping. Or just half shipping if you give me occasional ssh access. I'm pretty sure the HP machine is worth over $100 and the SGI over $200. More coming, probably next week. Happy Thanksgiving, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 25 12:08:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 11:08:25 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: References: , , <1286270642.3514.3.camel@boromir.m3w.org>, , , , <4CB1F4CD.4020101@wickensonline.co.uk>, , , , , <4CB2C557.70704@wickensonline.co.uk>, , , <4CB2D03D.8080608@wickensonline.co.uk>, Message-ID: another, including the Linux/sparc Hudson node: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651928303 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 27 01:14:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:14:24 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>, , , , , , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, Message-ID: I don't know what the strong/weak casts are, but here is the problem seemingly: gcc-4.5 fold-const.c fold_binary_loc(code = FLOOR_DIV_EXPR, ??????????????? op0, op1, type all int_64 arg0, arg1 become word_64 (not op0, op1, but arg0, arg1) and then we end up here: ????? if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) ??? ? && multiple_of_p (type, arg0, arg1)) ??? return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); and then, configure -enable-checking=fold,...: error: type mismatch in binary expression int_64 word_64 word_64 D.1003 = D.1001 /[ex] D.1002; I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 22:50:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Aha. I had no idea and should investigate further. > Notice though that I've been applying the same sorts of casts > everywhere and they generally help. But perhaps they are > weak, and weak is usually strong enough, or some such. > Almost anything is possible. :) > > > - Jay > > > > ---------------------------------------- > > Subject: Re: [M3commit] CVS Update: cm3 > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > CC: m3commit at elegosoft.com > > To: jay.krell at cornell.edu > > > > There are weak and strong casts in gcc. > > I forget the precise details, but I believe they will make a difference. > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > Presumably fold is removing the cast somewhere. > > > Maybe a gcc bug??? > > > I can dig deeper if you really want. > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > but different in signedness, I want to try *not* taking the address. > > > Probably also for pointer<=>integer of pointer size. > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> That should be handled by placing an appropriate cast in the gcc tree. > > >> > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > >> > > >> Try building m3-sys/m3tests/p2/p240. > > >> There is an error in the configure enable-checking about the types > > >> being mismatched. > > >> > > >> - Jay > > >> > > >> > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> Go with the obvious less heavy handed fix of only avoiding > > >>>> fold for integer division. > > >>> > > >>> I don't understand what the issue is with folding on integer > > >> division. Please explain. > > >>> > > >>>> This is enough for test p240 and the unoptimized code is definitely > > >> better. > > >>>> NOT fully tested, but really probably works. > > >>>> It is probably worth digging into the frontend to see if there is a > > >> difference > > >>>> in the types. It is probably also worth digging in the backend, like, > > >>>> we do put in the casts consistently, why are they only not effective > > >>>> for divide? I realize that a little bit of analysis goes a long way > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > >>>> On the other hand, it isn't worth too much effort. > > >>>> Divide is the slowest least used integer operation. > > >>> > > >> > > From jay.krell at cornell.edu Sat Nov 27 01:38:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:38:40 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>,,, , , ,,, , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, , , Message-ID: The reason it gets there is that multiple_of_p is true, because I'm dividing something by itself, in the test case. The answer would be 1, unless the value is 0. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Nov 2010 00:14:24 +0000 > CC: m3devel at elegosoft.com > Subject: [M3devel] fold_build(divide) vs. build(divide) > > > I don't know what the strong/weak casts are, but here is the problem seemingly: > > gcc-4.5 > fold-const.c > > fold_binary_loc(code = FLOOR_DIV_EXPR, > op0, op1, type all int_64 > > arg0, arg1 become word_64 > (not op0, op1, but arg0, arg1) > > and then we end up here: > > if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) > && multiple_of_p (type, arg0, arg1)) > return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); > > and then, configure -enable-checking=fold,...: > > error: type mismatch in binary expression > int_64 > > word_64 > > word_64 > > D.1003 = D.1001 /[ex] D.1002; > > I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . > > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 22:50:02 +0000 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Aha. I had no idea and should investigate further. > > Notice though that I've been applying the same sorts of casts > > everywhere and they generally help. But perhaps they are > > weak, and weak is usually strong enough, or some such. > > Almost anything is possible. :) > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > Subject: Re: [M3commit] CVS Update: cm3 > > > From: hosking at cs.purdue.edu > > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > > CC: m3commit at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > There are weak and strong casts in gcc. > > > I forget the precise details, but I believe they will make a difference. > > > > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > > Presumably fold is removing the cast somewhere. > > > > Maybe a gcc bug??? > > > > I can dig deeper if you really want. > > > > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > > but different in signedness, I want to try *not* taking the address. > > > > Probably also for pointer<=>integer of pointer size. > > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > > > > - Jay > > > > > > > > > > > > ________________________________ > > > >> From: hosking at cs.purdue.edu > > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3commit at elegosoft.com > > > >> Subject: Re: [M3commit] CVS Update: cm3 > > > >> > > > >> That should be handled by placing an appropriate cast in the gcc tree. > > > >> > > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > > >> > > > >> Try building m3-sys/m3tests/p2/p240. > > > >> There is an error in the configure enable-checking about the types > > > >> being mismatched. > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> > > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> Go with the obvious less heavy handed fix of only avoiding > > > >>>> fold for integer division. > > > >>> > > > >>> I don't understand what the issue is with folding on integer > > > >> division. Please explain. > > > >>> > > > >>>> This is enough for test p240 and the unoptimized code is definitely > > > >> better. > > > >>>> NOT fully tested, but really probably works. > > > >>>> It is probably worth digging into the frontend to see if there is a > > > >> difference > > > >>>> in the types. It is probably also worth digging in the backend, like, > > > >>>> we do put in the casts consistently, why are they only not effective > > > >>>> for divide? I realize that a little bit of analysis goes a long way > > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > > >>>> On the other hand, it isn't worth too much effort. > > > >>>> Divide is the slowest least used integer operation. > > > >>> > > > >> > > > > From rcolebur at SCIRES.COM Mon Nov 29 03:01:51 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 Message-ID: I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 29 08:52:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 07:52:20 +0000 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Good catch. Please try with recent small update, thanks. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Nov 29 16:58:39 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 29 Nov 2010 10:58:39 -0500 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Jay: Your update seems to have fixed the problem. THANKS. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, November 29, 2010 2:52 AM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] build problem on Win2000 Good catch. Please try with recent small update, thanks. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcdurocher at gmail.com Mon Nov 29 18:14:56 2010 From: kcdurocher at gmail.com (Ken Durocher) Date: Mon, 29 Nov 2010 11:14:56 -0600 Subject: [M3devel] Enumeration or subrange value out of range Message-ID: I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I ran into a problem. The code compiles fine, but I get a runtime error. I'm running 5.8.6 RELEASE on AMD64. P.S. Is there already an unsigned int32 type? Is there a better way to create one? Here's the code: INTERFACE Tea; TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); END Tea. *** MODULE Tea; FROM Word IMPORT Xor, LeftShift, RightShift; VAR delta := 16_9e3779b9; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 0; BEGIN FOR i := 0 TO 31 DO sum := sum + delta; v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1))); v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3))); END; v[0] := v0; v[1] := v1; END Encrypt; PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 16_c6ef3720; BEGIN FOR i := 0 TO 32 DO v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3)); v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1)); sum := sum - delta; END; v[0] := v0; v[1] := v0; END Decrypt; BEGIN END Tea. *** MODULE Main; IMPORT IO, Fmt, Tea; VAR v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; BEGIN Tea.Encrypt(v,k); IO.Put(Fmt.Unsigned(v[0])); IO.Put(" - "); IO.Put(Fmt.Unsigned(v[1])); IO.Put("\n"); END Main. And the error: *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../Tea.m3", line 18 *** Aborted -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Nov 29 20:24:22 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 29 Nov 2010 14:24:22 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <20101129192421.GA31379@topoi.pooq.com> On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > ran into a problem. The code compiles fine, but I get a runtime error. I'm > running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? There's a signed int32, and an unsigned int31, which is designed to fit into a signed 32. The closes you can come to unsigned int32 is probably WORD. Look up Word.T. Unless you're using a 64-bit machine, in which case you get int64 and unsigned int63 for free, I suppose. -- hendrik From jay.krell at cornell.edu Mon Nov 29 21:22:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 20:22:17 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101129192421.GA31379@topoi.pooq.com> References: , <20101129192421.GA31379@topoi.pooq.com> Message-ID: Signed int32 probably works for you, for storage. (Cstdint.int32_t or such). For the operations, well, Word will do most of what you want. Just be sure to and with 16_FFFFFFFF before each assignment? We could flesh out /dev2/cm3/m3-libs/m3core/src/types to contain the Word operations. HOWEVER we'd want/need to provide version with exceptions or silence for overflow. - Jay > Date: Mon, 29 Nov 2010 14:24:22 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > > ran into a problem. The code compiles fine, but I get a runtime error. I'm > > running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > There's a signed int32, and an unsigned int31, which is designed to fit > into a signed 32. The closes you can come to unsigned int32 is probably > WORD. Look up Word.T. > > Unless you're using a 64-bit machine, in which case you get int64 and > unsigned int63 for free, I suppose. > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Nov 29 23:36:30 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 29 Nov 2010 16:36:30 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <4CF42AEE.3000807@lcwb.coop> The packed subrange type with an all-positive range doesn't do what I suspect you think it does. The subrange only affects what values can be legally stored in a variable, and the packed size only affects memory allocation when it is used as an element of an array or field of a record or object. None of this changes the semantics of the arithmetic operators +, -, Word.Xor, etc. when applied to values of this type. In Modula-3, all intermediate arithmetic is done in the native word size, in this case 64 bits. And the builtin operators +, etc. apply signed interpretation to the bit values. Only when you assign to a variable (or do any of a number of equivalent things, e.g., pass to a VALUE parameter) is a range check done. There is no trimming of intermediate results to 32 bits, despite the application of your arithmetic operators to variables of your UInt32 subrange type. So, without vetting the algorithm or knowing sample input, I can pretty well guess that things like LeftShift are shifting bits into the upper half of the word. Then when you try to assign to a UInt32 variable, you have a value outside its range. One way to do this would be to always And to 16_FFFFFFFF in your expression, before you store the result. This would ensure values within range, and, I suspect, the values you really want. Note that Modula-3 handles unsigned rather differently than many languages. You can use a subrange type, as you did, but it has to be a true subrange of INTEGER, so you can't get the normally-negative part of the range of INTEGER to be interpreted as positive, above the normal positive half of INTEGER. Should you really need full native-word-sized unsigned arithmetic, you use the type Word.T. But this is actually the same type as INTEGER, so naming it Word.T is just a programmer readability courtesy. The builtin operators +, -, etc. apply signed interpretation to the bits in a word. The operators from Word (Word.Plus, etc.) operate on values of the same type (INTEGER=Word.T), but apply unsigned interpretation to the entire word range. It would no doubt be good to replace your + operators with Word.Plus, to emphasize unsigned arithmetic. For + and -, in the absence of overflow checks, the signed and unsigned arithmetic are the same, of course, but it would be another readability courtesy. And if we ever get a compiler with overflow checking, it would still work right. I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while still And-ing results to 16_FFFFFFFF. I think this would make your code portable between 32-bit and 64-bit machines. All your arithmetic would just be applying unsigned interpretation to the bits, and the signed subrange would work like INTEGER on a 32-bit machine and as you have coded on 64 bits. All bit combinations (with no bits set in the upper half of a 64-bit word) would be in range. Of course, this all interacts with your client code and they type they use. Or maybe you could just dispense with trying to use the type system to enforce your ranges and use Word.T. If you always And your results to 16_FFFFFFFF, it will ensure they are within the desired range. There are some client interface design issues here, which you test program is not involved enough to expose. On another subject, it looks like your algorithms will either crash or won't work meaningfully unless v has exactly two elements and k has exactly 4. So using fixed array types instead of open might be a sensible way to use the type system to help here. P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The compiler is free to represent them in any way that can hold the range, and it may well give them 64 bits on a 64-bit machine. In any case, even if it gave them only 32, it would, by the semantics of the language, have to expand them to 64 before doing any arithmetic on them. HTH. Rodney Bates Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > but I ran into a problem. The code compiles fine, but I get a runtime > error. I'm running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? > > Here's the code: > > INTERFACE Tea; > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > END Tea. > > *** > > MODULE Tea; > > FROM Word IMPORT Xor, LeftShift, RightShift; > > VAR > delta := 16_9e3779b9; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 0; > > BEGIN > FOR i := 0 TO 31 DO > sum := sum + delta; > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1))); > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3))); > END; > v[0] := v0; v[1] := v1; > END Encrypt; > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 16_c6ef3720; > BEGIN > FOR i := 0 TO 32 DO > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3)); > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1)); > sum := sum - delta; > END; > v[0] := v0; v[1] := v0; > END Decrypt; > > BEGIN > END Tea. > > *** > > MODULE Main; > > IMPORT IO, Fmt, Tea; > > VAR > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > BEGIN > Tea.Encrypt(v,k); > IO.Put(Fmt.Unsigned(v[0])); > IO.Put(" - "); > IO.Put(Fmt.Unsigned(v[1])); > IO.Put("\n"); > END Main. > > And the error: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../Tea.m3", line 18 > *** > > Aborted > > From jay.krell at cornell.edu Tue Nov 30 00:01:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 23:01:47 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <4CF42AEE.3000807@lcwb.coop> References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. And *hopefully* a 64bit targeting compiler would "notice" and make some optimizations, such as only doing 32bit load/stores, but I could easily imagine it not doing that. Imho, it really would be nice to have the following types, with operator+, etc.: unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow 2 x 4 x 2 => 16 types C and C++ programmers the world over have 8 of these types (unspecified what signed overflow does, but overwhelmingly it is silent). The underlying backend exposes those 8 as well. - Jay ---------------------------------------- > Date: Mon, 29 Nov 2010 16:36:30 -0600 > From: rodney_bates at lcwb.coop > To: kcdurocher at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > The packed subrange type with an all-positive range doesn't do what > I suspect you think it does. The subrange only affects what values > can be legally stored in a variable, and the packed size only affects > memory allocation when it is used as an element of an array or field > of a record or object. None of this changes the semantics of the > arithmetic operators +, -, Word.Xor, etc. when applied to values > of this type. > > In Modula-3, all intermediate arithmetic is done in the native word > size, in this case 64 bits. And the builtin operators +, etc. apply signed > interpretation to the bit values. Only when you assign to a variable (or do > any of a number of equivalent things, e.g., pass to a VALUE parameter) > is a range check done. There is no trimming of intermediate results > to 32 bits, despite the application of your arithmetic operators to variables > of your UInt32 subrange type. > > So, without vetting the algorithm or knowing sample input, I can pretty > well guess that things like LeftShift are shifting bits into the upper > half of the word. Then when you try to assign to a UInt32 variable, > you have a value outside its range. > > One way to do this would be to always And to 16_FFFFFFFF in your expression, > before you store the result. This would ensure values within range, and, > I suspect, the values you really want. > > Note that Modula-3 handles unsigned rather differently than many languages. > You can use a subrange type, as you did, but it has to be a true subrange > of INTEGER, so you can't get the normally-negative part of the range of > INTEGER to be interpreted as positive, above the normal positive half of > INTEGER. > > Should you really need full native-word-sized unsigned arithmetic, you > use the type Word.T. But this is actually the same type as INTEGER, so > naming it Word.T is just a programmer readability courtesy. The builtin > operators +, -, etc. apply signed interpretation to the bits in a word. > The operators from Word (Word.Plus, etc.) operate on values of the same > type (INTEGER=Word.T), but apply unsigned interpretation to the entire > word range. > > It would no doubt be good to replace your + operators with Word.Plus, > to emphasize unsigned arithmetic. For + and -, in the absence of > overflow checks, the signed and unsigned arithmetic are the same, > of course, but it would be another readability courtesy. And if we > ever get a compiler with overflow checking, it would still work right. > > I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while > still And-ing results to 16_FFFFFFFF. I think this would make your code portable > between 32-bit and 64-bit machines. All your arithmetic would just be > applying unsigned interpretation to the bits, and the signed subrange would > work like INTEGER on a 32-bit machine and as you have coded on 64 bits. > All bit combinations (with no bits set in the upper half of a 64-bit word) > would be in range. Of course, this all interacts with your client code > and they type they use. > > Or maybe you could just dispense with trying to use the type system to > enforce your ranges and use Word.T. If you always And your results to > 16_FFFFFFFF, it will ensure they are within the desired range. There > are some client interface design issues here, which you test program > is not involved enough to expose. > > On another subject, it looks like your algorithms will either crash or > won't work meaningfully unless v has exactly two elements and k has exactly > 4. So using fixed array types instead of open might be a sensible way to > use the type system to help here. > > P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The > compiler is free to represent them in any way that can hold the range, and it > may well give them 64 bits on a 64-bit machine. In any case, even > if it gave them only 32, it would, by the semantics of the language, > have to expand them to 64 before doing any arithmetic on them. > > > HTH. Rodney Bates > > > Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > > but I ran into a problem. The code compiles fine, but I get a runtime > > error. I'm running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > > > Here's the code: > > > > INTERFACE Tea; > > > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > > > END Tea. > > > > *** > > > > MODULE Tea; > > > > FROM Word IMPORT Xor, LeftShift, RightShift; > > > > VAR > > delta := 16_9e3779b9; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 0; > > > > BEGIN > > FOR i := 0 TO 31 DO > > sum := sum + delta; > > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1))); > > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3))); > > END; > > v[0] := v0; v[1] := v1; > > END Encrypt; > > > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 16_c6ef3720; > > BEGIN > > FOR i := 0 TO 32 DO > > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3)); > > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1)); > > sum := sum - delta; > > END; > > v[0] := v0; v[1] := v0; > > END Decrypt; > > > > BEGIN > > END Tea. > > > > *** > > > > MODULE Main; > > > > IMPORT IO, Fmt, Tea; > > > > VAR > > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > > > BEGIN > > Tea.Encrypt(v,k); > > IO.Put(Fmt.Unsigned(v[0])); > > IO.Put(" - "); > > IO.Put(Fmt.Unsigned(v[1])); > > IO.Put("\n"); > > END Main. > > > > And the error: > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../Tea.m3", line 18 > > *** > > > > Aborted > > > > From hosking at cs.purdue.edu Tue Nov 30 04:13:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Nov 2010 22:13:32 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Rodney, Thank-you for your (as-usual) incredibly lucid explanation. Jay, On Nov 29, 2010, at 6:01 PM, Jay K wrote: > > ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. > And *hopefully* a 64bit targeting compiler would "notice" and make some > optimizations, such as only doing 32bit load/stores, but I could easily > imagine it not doing that. > > > Imho, it really would be nice to have the following types, with operator+, etc.: > > > unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow > 2 x 4 x 2 => 16 types This would be a nightmare. (i.e., over many of our dead bodies...) > C and C++ programmers the world over have 8 of these types (unspecified > what signed overflow does, but overwhelmingly it is silent). Let them rot in C hell. > The underlying backend exposes those 8 as well. But only for the purpose of accessing stored values (as Rodney explained). All operations are performed at INTEGER/Word.T granularity. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 29 Nov 2010 16:36:30 -0600 >> From: rodney_bates at lcwb.coop >> To: kcdurocher at gmail.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Enumeration or subrange value out of range >> >> The packed subrange type with an all-positive range doesn't do what >> I suspect you think it does. The subrange only affects what values >> can be legally stored in a variable, and the packed size only affects >> memory allocation when it is used as an element of an array or field >> of a record or object. None of this changes the semantics of the >> arithmetic operators +, -, Word.Xor, etc. when applied to values >> of this type. >> >> In Modula-3, all intermediate arithmetic is done in the native word >> size, in this case 64 bits. And the builtin operators +, etc. apply signed >> interpretation to the bit values. Only when you assign to a variable (or do >> any of a number of equivalent things, e.g., pass to a VALUE parameter) >> is a range check done. There is no trimming of intermediate results >> to 32 bits, despite the application of your arithmetic operators to variables >> of your UInt32 subrange type. >> >> So, without vetting the algorithm or knowing sample input, I can pretty >> well guess that things like LeftShift are shifting bits into the upper >> half of the word. Then when you try to assign to a UInt32 variable, >> you have a value outside its range. >> >> One way to do this would be to always And to 16_FFFFFFFF in your expression, >> before you store the result. This would ensure values within range, and, >> I suspect, the values you really want. >> >> Note that Modula-3 handles unsigned rather differently than many languages. >> You can use a subrange type, as you did, but it has to be a true subrange >> of INTEGER, so you can't get the normally-negative part of the range of >> INTEGER to be interpreted as positive, above the normal positive half of >> INTEGER. >> >> Should you really need full native-word-sized unsigned arithmetic, you >> use the type Word.T. But this is actually the same type as INTEGER, so >> naming it Word.T is just a programmer readability courtesy. The builtin >> operators +, -, etc. apply signed interpretation to the bits in a word. >> The operators from Word (Word.Plus, etc.) operate on values of the same >> type (INTEGER=Word.T), but apply unsigned interpretation to the entire >> word range. >> >> It would no doubt be good to replace your + operators with Word.Plus, >> to emphasize unsigned arithmetic. For + and -, in the absence of >> overflow checks, the signed and unsigned arithmetic are the same, >> of course, but it would be another readability courtesy. And if we >> ever get a compiler with overflow checking, it would still work right. >> >> I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while >> still And-ing results to 16_FFFFFFFF. I think this would make your code portable >> between 32-bit and 64-bit machines. All your arithmetic would just be >> applying unsigned interpretation to the bits, and the signed subrange would >> work like INTEGER on a 32-bit machine and as you have coded on 64 bits. >> All bit combinations (with no bits set in the upper half of a 64-bit word) >> would be in range. Of course, this all interacts with your client code >> and they type they use. >> >> Or maybe you could just dispense with trying to use the type system to >> enforce your ranges and use Word.T. If you always And your results to >> 16_FFFFFFFF, it will ensure they are within the desired range. There >> are some client interface design issues here, which you test program >> is not involved enough to expose. >> >> On another subject, it looks like your algorithms will either crash or >> won't work meaningfully unless v has exactly two elements and k has exactly >> 4. So using fixed array types instead of open might be a sensible way to >> use the type system to help here. >> >> P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The >> compiler is free to represent them in any way that can hold the range, and it >> may well give them 64 bits on a 64-bit machine. In any case, even >> if it gave them only 32, it would, by the semantics of the language, >> have to expand them to 64 before doing any arithmetic on them. >> >> >> HTH. Rodney Bates >> >> >> Ken Durocher wrote: >>> I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, >>> but I ran into a problem. The code compiles fine, but I get a runtime >>> error. I'm running 5.8.6 RELEASE on AMD64. >>> >>> P.S. Is there already an unsigned int32 type? Is there a better way to >>> create one? >>> >>> Here's the code: >>> >>> INTERFACE Tea; >>> >>> TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> >>> END Tea. >>> >>> *** >>> >>> MODULE Tea; >>> >>> FROM Word IMPORT Xor, LeftShift, RightShift; >>> >>> VAR >>> delta := 16_9e3779b9; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 0; >>> >>> BEGIN >>> FOR i := 0 TO 31 DO >>> sum := sum + delta; >>> v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1))); >>> v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3))); >>> END; >>> v[0] := v0; v[1] := v1; >>> END Encrypt; >>> >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 16_c6ef3720; >>> BEGIN >>> FOR i := 0 TO 32 DO >>> v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3)); >>> v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1)); >>> sum := sum - delta; >>> END; >>> v[0] := v0; v[1] := v0; >>> END Decrypt; >>> >>> BEGIN >>> END Tea. >>> >>> *** >>> >>> MODULE Main; >>> >>> IMPORT IO, Fmt, Tea; >>> >>> VAR >>> v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; >>> k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; >>> >>> BEGIN >>> Tea.Encrypt(v,k); >>> IO.Put(Fmt.Unsigned(v[0])); >>> IO.Put(" - "); >>> IO.Put(Fmt.Unsigned(v[1])); >>> IO.Put("\n"); >>> END Main. >>> >>> And the error: >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../Tea.m3", line 18 >>> *** >>> >>> Aborted >>> >>> From jay.krell at cornell.edu Tue Nov 30 04:43:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 03:43:26 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: > Let them rot in C hell. It's really not a bad place. Modula-3 is good: optional safety, optional unsafety ie: optional garbage collection, restrictions on taking address of locals, range checks on arrays better interface/implementation separation, such as to allow much faster compilation single inheritance object-orientation is nice, but I'd prefer for the safety to be optional (untraced objects) and multiple-inheritance generics are good, but not as good as C++ templates sets are kind of nice optionally indexing arrays by enums is kind of nice open arrays are kind of nice (relates to safety) Very small language definition is good, but I'd still like e.g. operator overloading, at least with a "fixed" interface as I described T +(T,T), never T1 +(T2, T3) for example. But I don't see why not providing these types is so good. I can see that maybe it is partly/all library instead of language. As well, as so much code is C, C++, or even Java and C#, it is what the hardware supports well. i.e. 8 bit, 16 bit, 32 bit operations are efficient, and 64 bit are also sometimes - Jay From dragisha at m3w.org Tue Nov 30 08:49:01 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 08:49:01 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? No, it isn't ! :) I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. On Nov 30, 2010, at 4:43 AM, Jay K wrote: > generics are good, but not as good as C++ templates From jay.krell at cornell.edu Tue Nov 30 09:32:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 08:32:12 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? The error messages are better these days. It is true they were terrible for a long time. Don't Modula-3 generics have the same problem? At least in the C++ case: - the errors aren't in generated files - you don't have to explicitly instantiate everything "in the build system" - for function templates, you never have to instantiate anything The automatic deduction of function template parameters is very powerful. You have to try it. I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent feature "auto". It is also true that templates seem to be largely accidental in what they allow. It seems they were designed with two primary applications: std::vector std::min/max The compile-time Turing-completeness seems to have been an accident, and what people use this for is/was perhaps better implemented through special language constructs builtin to the compiler. It is both impressive and depressive. Impressive that it is doable, depressive what it looks like. When people do "meta programming" like "is_pod", "has_copy_constructor", etc. Consider this though, have you heard the ability to do this: matrix a,b,c,d; a = b + c + d; where there are no intermediate matrices? The results are written directly into a. The people do this is that operator+ doesn't return a matrix, but rather a type that represents the result matrix addition, which is assignable to a matrix, and can also be added to matrices or the results of matrix addition. So ultimately what is assigned to a is something representation the addition of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within the rules of matrix multiplication) etc. There is no special casing, no special purpose code to handle certain combinations. I don't believe any other language has this power. Simple string addition can benefit from this same technique. Instead, string concatenation gets very special treatment by compilers, including I believe in Modula-3, Java, and C#. That's not "fair". Why should string get all the power and syntactic sugar, but not any user-defined types? Look for articles by Todd Veldhuzien. Libraries such as Blitz++. http://www.cs.rpi.edu/~musser/design/blitz/meta-art.html http://www.oonumerics.org/blitz/ etc. If C++ is just a bit too gnarly and difficult to understand and implement, I suspect subset exists with about the same level of expressiveness. But I don't know. - Jay > Subject: Re: [M3devel] Enumeration or subrange value out of range > From: dragisha at m3w.org > Date: Tue, 30 Nov 2010 08:49:01 +0100 > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; kcdurocher at gmail.com > To: jay.krell at cornell.edu > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > No, it isn't ! :) > > I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". > > I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. > > On Nov 30, 2010, at 4:43 AM, Jay K wrote: > > > generics are good, but not as good as C++ templates > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Nov 30 10:19:37 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 10:19:37 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > > The error messages are better these days. My experience is as recent as Snow Leopard, with 10.6.5 update. > It is true they were terrible for a long time. > Don't Modula-3 generics have the same problem? > At least in the C++ case: > - the errors aren't in generated files They are generated, but they are exact source you would "generate" for it. Aren't they? And you have them to step through with debugger. At least, I never hit a wall with them, like I did with that .h for vectors. > - you don't have to explicitly instantiate everything "in the build system" That would be a killing experience, to add even more complexity to Makefiles :). > - for function templates, you never have to instantiate anything > The automatic deduction of function template parameters is very powerful. > You have to try it. > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > feature "auto". A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. > It is also true that templates seem to be largely accidental in what they allow. > It seems they were designed with two primary applications: > std::vector > std::min/max There's folk saying here, it goes like: "To kill an ox for a kilo of meat." What you can do with these, and what you need to be done with these... It is mostly scope of some more dynamic environment, scripting comes to mind. To put them in compiled environment is just more of C++'s featurism (we can do it, why don't we...)... Your comparison to ML is right on spot. C++ is just mixed philosophy, mixed styles, mixed everything. Mixed results just follow suite. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Nov 30 15:45:01 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 09:45:01 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <20101130144501.GA11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 08:32:12AM +0000, Jay K wrote: > > > Consider this though, have you heard the ability to do this: > matrix a,b,c,d; > a = b + c + d; Does it work as well for a = b + a + d? > > > where there are no intermediate matrices? > The results are written directly into a. > > > The people do this is that operator+ doesn't return a matrix, but rather > a type that represents the result matrix addition, which is assignable > to a matrix, and can also be added to matrices or the results of matrix addition. > So ultimately what is assigned to a is something representation the addition > of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within > the rules of matrix multiplication) etc. There is no special casing, no special > purpose code to handle certain combinations. I don't believe any other > language has this power. Or a = a * a * a? -- hendrik From hendrik at topoi.pooq.com Tue Nov 30 16:04:18 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 10:04:18 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> Message-ID: <20101130150418.GB11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 10:19:37AM +0100, Dragi?a Duri? wrote: > > On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > > It is true they were terrible for a long time. > > Don't Modula-3 generics have the same problem? > > At least in the C++ case: > > - the errors aren't in generated files > > They are generated, but they are exact source you would "generate" for > it. Aren't they? And you have them to step through with debugger. At > least, I never hit a wall with them, like I did with that .h for > vectors. And you know what files they were gerenated from, and with what parameters. > > > - you don't have to explicitly instantiate everything "in the build system" > > That would be a killing experience, to add even more complexity to > Makefiles :). C++ managed to make linkers the world over vastly more ocmplex. It's the linker that discovers that some templates haven't been compiled yet and calls the compiler to compile them. I really don't think linkers should be all *that* language-dependent. > > > - for function templates, you never have to instantiate anything > > The automatic deduction of function template parameters is very powerful. > > You have to try it. Is finding the right template to instantiate with the right parameters always unambiguous? > > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > > feature "auto". > > A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. I don't mind ML's style, except that programmers tend to leave out too many explicit types for readability. I do mind, in C++, having something "similar to" ML without ML's internal discipline. > > > It is also true that templates seem to be largely accidental in what they allow. > > It seems they were designed with two primary applications: > > std::vector > > std::min/max > > There's folk saying here, it goes like: "To kill an ox for a kilo of meat." That's the standard practice in C++. To introduce complicated mechanisms tso that the programmer, with sufficient effort, can mimic features that should better have been reliably built into the language in the first place. > > What you can do with these, and what you need to be done with these... > It is mostly scope of some more dynamic environment, scripting comes > to mind. To put them in compiled environment is just more of C++'s > featurism (we can do it, why don't we...)... Your comparison to ML is > right on spot. Except that ML is more rationally and consistently typed. >C++ is just mixed philosophy, mixed styles, mixed > everything. Mixed results just follow suite. > -- hendrik From jay.krell at cornell.edu Tue Nov 30 18:18:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 17:18:10 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101130150418.GB11084@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com> Message-ID: > C++ managed to make linkers the world over vastly more ocmplex. It's > the linker that discovers that some templates haven't been compiled yet > and calls the compiler to compile them. I really don't think linkers > should be all *that* language-dependent. This is actually unfortunately false. C++ requires no or almost no linker support. Inline functions often use linker features that C didn't need. Templates do not. What really happens is templatized code is fully in headers. Which does have drawbacks -- large headers, slow compile. There was an implementation where the compiler looked at the linker errors. But I don't think any such implementation is in use today. > Is finding the right template to instantiate with the right > parameters always unambiguous? When it is ambiguous, there is an error. int i; long j; max(i,j); => error > That's the standard practice in C++. To introduce complicated > mechanisms tso that the programmer, with sufficient effort, can mimic > features that should better have been reliably built into the language > in the first place. In the case of templates leading to some meta programming, it was an accident. But in the case of operator overloading it seems just goodness. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 1 09:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Nov 2010 08:20:16 +0000 Subject: [M3devel] m3cg_set_runtime_proc vs. m3cg_set_runtime_hook Message-ID: m3cg_set_runtime_proc vs. m3cg_set_runtime_hook appear to serve almost the same purpose. m3cg_set_runtime_hook is never used. Go ahead and remove it? ?- Jay From jay.krell at cornell.edu Fri Nov 5 17:02:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 16:02:33 +0000 Subject: [M3devel] llvm Message-ID: http://llvm.org/releases/2.8/docs/ReleaseNotes.html wow, lots of progress! From dragisha at m3w.org Fri Nov 5 17:13:04 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 5 Nov 2010 17:13:04 +0100 Subject: [M3devel] llvm In-Reply-To: References: Message-ID: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> And to put Modula-3 in this neighborhood.... JIT, LLDB... On Nov 5, 2010, at 5:02 PM, Jay K wrote: > http://llvm.org/releases/2.8/docs/ReleaseNotes.html > > wow, lots of progress! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 5 22:29:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 21:29:34 +0000 Subject: [M3devel] Hudson: illegal type: 0x17, at m3cg_lineno 4 Message-ID: Fyi, I fixed these on Linux/amd64: ? illegal type: 0x17, at m3cg_lineno 4 by replacing all the installs with a release and the rebuilding. So maybe something off in the upgrade process. Maybe. But there wasn't an IL/IR/m3cg change. Not understood. I can try this on Solaris/PPC_DARWIN. (PPC_DARWIN has another problem still last I knew.) Later, - Jay From jay.krell at cornell.edu Sat Nov 6 00:17:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:17:13 +0000 Subject: [M3devel] hudson/ppc_darwin Message-ID: PPC_DARWIN in Hudson will be broken a very short while. I know the problem. It has an older g++. Other platforms should be ok, or at least several were. Definitely a few succeeded. The opencsw machines need human intervention, which I can do, later. ? At least somewhat. If they say "no cm3 installed", I'm not sure. ? If they say "invalid type: 0x17", I'll reinstall cm3. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:52:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:52:03 +0000 Subject: [M3devel] opencsw/cvs Message-ID: I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. Specifically, here, 10x: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console it is using old source. But this one, 9s: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ is working. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:56:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:56:07 +0000 Subject: [M3devel] quake rm_rec/instrumentation? Message-ID: Is rm_rec known to work/fail? You can see it is still instrumented and seems to be working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console Refresher: ? the main problem was likely to do with symlinks and stat ? the fix is hacky, deep in m3core/libm3, I changed stat to first stat and if that fails, lstat ??? (maybe should only lstat upon particular erors) ?Otherwise deleting a symlink to a nonexistant file/directory failed. ?I also changed it to not delete while enumerating, but that probably was ok either way. ?I also changed it to stat much less (caveat that the "real fix" involves more calls sometimes). ?- Jay From wagner at elegosoft.com Sat Nov 6 10:41:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:41:34 +0100 Subject: [M3devel] quake rm_rec/instrumentation? In-Reply-To: References: Message-ID: <20101106104134.yjwh4qw28cw8gck0@mail.elegosoft.com> Quoting Jay K : > Is rm_rec known to work/fail? > > You can see it is still instrumented and seems to be working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console I haven't noticed any problems with rmrec recently, but then I haven't monitored the cm3 regression very carefully. I seem to remember that problems faced in m3tests and we introduced a workaround there. Perhaps we could disable that and see what happens. > Refresher: > ? the main problem was likely to do with symlinks and stat > ? the fix is hacky, deep in m3core/libm3, I changed stat to first > stat and if that fails, lstat > ??? (maybe should only lstat upon particular erors) > ?Otherwise deleting a symlink to a nonexistant file/directory failed. > > ?I also changed it to not delete while enumerating, but that > probably was ok either way. > ?I also changed it to stat much less (caveat that the "real fix" > involves more calls sometimes). That all sounds OK. You could simply make the debug code depend on the -trace or -debug option of cm3 to be prepared for the next failure ;-) 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 Sat Nov 6 10:44:25 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:44:25 +0100 Subject: [M3devel] hudson/ppc_darwin In-Reply-To: References: Message-ID: <20101106104425.y2ezk1i9gys0ws4w@mail.elegosoft.com> Quoting Jay K : > > PPC_DARWIN in Hudson will be broken a very short while. > I know the problem. It has an older g++. No problem. > Other platforms should be ok, or at least several were. > Definitely a few succeeded. > > The opencsw machines need human intervention, which I can do, later. That would be great. > ? At least somewhat. If they say "no cm3 installed", I'm not sure. > ? If they say "invalid type: 0x17", I'll reinstall cm3. -- 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 Sat Nov 6 13:29:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Nov 2010 12:29:04 +0000 Subject: [M3devel] small note for Solaris 2.9 Message-ID: fyi, to convert a SOLsun bootstrap to Solaris 2.9: for a in *s; do perl -pi.bak -e "s/^\s+\.hidden\s+.+$//" $a; done There are other ways. Native builds using autoconf and discover if .hidden works or not. Cross builds have to make an assumption and we err toward Solaris 2.10. We could err toward 2.9. We could adapt automatically at the "end" of "bootstrap". If we don't get a C/C++ backend, distributing as assembly-source and improving how that is built will be in order. e.g. err toward 2.9 and ship assembly source for "everything" e.g. err toward 2.9 but do this replacement if the probed assembler supports .hidden e.g. err toward 2.9 but only ship assembly for cm3, build everything else native from there. or just ignore it and nobody will notice. ?- Jay From jay.krell at cornell.edu Sun Nov 7 04:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 03:48:49 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw Message-ID: Gets as far as: --- building in SOLsun --- ignoring ../src/m3overrides /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB stubgen: Processing RemoteView.T *** *** runtime error: ***??? Thread client error: -1 ***??? file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 *** Abort - core dumped "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB I'll try 2.10 instead.. ?- Jay From jay.krell at cornell.edu Sun Nov 7 13:35:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 12:35:22 +0000 Subject: [M3devel] init_offset? Message-ID: m3cg.i3: init_offset (o: ByteOffset;? var: Var); (* initializes the static variable at 'ADR(v)+o' with the integer ?? frame offset of the local variable 'var' relative to the frame ?? pointers returned at runtime in RTStack.Frames *) The implications of this make me nervous. ? Must locals be at the indicated location when the garbage collector runs? Should we maybe make all traced pointers volatile? ?Or at least stores to them? ? I know we have a compacting garbage collector. ? If it moves a pointer.. it updates any instance of that value seen on the stack? ? (and I know, we endeavor to "flush" registers when paused for gc, so that ? stack suffices and no need to worry further about registers, except on NT386 ? where it is a little different, we can get/set the registers of the paused thread) If the stack is scanned and updated beyond this information, what is this information for? Maybe an optimization? Granted, I haven't looked at what the frontend does here. There's lots of stuff I could figure out by reading the code.. ?- Jay From dragisha at m3w.org Sun Nov 7 13:41:40 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 13:41:40 +0100 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> We don't'. Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). So, no need to "volatilize" anything explicitly. IMO :) On Nov 7, 2010, at 1:35 PM, Jay K wrote: > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) From hosking at cs.purdue.edu Sun Nov 7 14:24:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:24:09 -0500 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: This is used for exception handling. Sent from my iPad On 07/11/2010, at 7:35 AM, Jay K wrote: > > m3cg.i3: > > init_offset (o: ByteOffset; var: Var); > (* initializes the static variable at 'ADR(v)+o' with the integer > frame offset of the local variable 'var' relative to the frame > pointers returned at runtime in RTStack.Frames *) > > > The implications of this make me nervous. > Must locals be at the indicated location when the garbage collector runs? > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) > > If the stack is scanned and updated beyond this information, what is this information for? > Maybe an optimization? > > Granted, I haven't looked at what the frontend does here. > There's lots of stuff I could figure out by reading the code.. > > - Jay > From hosking at cs.purdue.edu Sun Nov 7 14:22:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:22:50 -0500 Subject: [M3devel] init_offset? In-Reply-To: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> References: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> Message-ID: Even if we did move stack-referenced objects we still would not need to volatilise. The assumption should always be that registers (as captured when a thread is stopped) will also be available for scanning. That's why on some targets we explicitly capture the thread registers. But it is true that we don't move stack-referenced objects. Sent from my iPad On 07/11/2010, at 7:41 AM, Dragi?a Duri? wrote: > We don't'. > > Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). > > So, no need to "volatilize" anything explicitly. > > IMO :) > > On Nov 7, 2010, at 1:35 PM, Jay K wrote: > >> Should we maybe make all traced pointers volatile? >> Or at least stores to them? >> I know we have a compacting garbage collector. >> If it moves a pointer.. it updates any instance of that value seen on the stack? >> (and I know, we endeavor to "flush" registers when paused for gc, so that >> stack suffices and no need to worry further about registers, except on NT386 >> where it is a little different, we can get/set the registers of the paused thread) > From lemming at henning-thielemann.de Sun Nov 7 17:33:04 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 17:33:04 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > And to put Modula-3 in this neighborhood.... JIT, LLDB... I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. From dragisha at m3w.org Sun Nov 7 20:15:57 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:15:57 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> I mentioned JIT just so, LLVM is not just JIT. And yes, you are right. GCC is a pillar of stability. Especially when you run after them trying to catch their undocumented changes to IR. NOT :) On Nov 7, 2010, at 5:33 PM, Henning Thielemann wrote: > > On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > >> And to put Modula-3 in this neighborhood.... JIT, LLDB... > > I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. > From lemming at henning-thielemann.de Sun Nov 7 20:38:31 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 20:38:31 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > I mentioned JIT just so, LLVM is not just JIT. Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. From dragisha at m3w.org Sun Nov 7 20:45:27 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:45:27 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: <7FDAA6E8-7503-4105-AED4-9DE27A17D526@m3w.org> http://llvm.org/Users.html On Nov 7, 2010, at 8:38 PM, Henning Thielemann wrote: > > On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > >> I mentioned JIT just so, LLVM is not just JIT. > > Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. > From jay.krell at cornell.edu Sun Nov 7 22:40:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:40:02 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: Message-ID: It works on 2.10 (opencsw current10s). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLsun/Solaris 2.9/opencsw > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > Gets as far as: > --- building in SOLsun --- > > ignoring ../src/m3overrides > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > stubgen: Processing RemoteView.T > > > *** > *** runtime error: > *** Thread client error: -1 > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > *** > > Abort - core dumped > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > I'll try 2.10 instead.. > > - Jay > > > > > From jay.krell at cornell.edu Sun Nov 7 22:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:35:32 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? Message-ID: == package /home/jkrell/dev2/cm3/m3-ui/opengl == ?+++ /home/jkrell/cm3.sparc32-5.10/bin/cm3??? -build -DROOT=/home/jkrell/dev2/cm3 +++ --- building in SOLsun --- ignoring ../src/m3overrides new source -> compiling GL.i3 new source -> compiling GLu.i3 new source -> compiling GLX.i3 ?-> archiving libopengl.a ld: fatal: library -lGLU: not found ld: fatal: library -lGL: not found ?- Jay From jay.krell at cornell.edu Sun Nov 7 22:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:53:25 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? In-Reply-To: References: Message-ID: (I can workaround this reasonably.) ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de; m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:35:32 +0000 > Subject: [M3devel] Solaris 2.10/x86/OpenGL? > > > == package /home/jkrell/dev2/cm3/m3-ui/opengl == > > +++ /home/jkrell/cm3.sparc32-5.10/bin/cm3 -build -DROOT=/home/jkrell/dev2/cm3 +++ > --- building in SOLsun --- > > ignoring ../src/m3overrides > > new source -> compiling GL.i3 > new source -> compiling GLu.i3 > new source -> compiling GLX.i3 > -> archiving libopengl.a > ld: fatal: library -lGLU: not found > ld: fatal: library -lGL: not found > > > - Jay > > > > > From jay.krell at cornell.edu Mon Nov 8 00:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:28:36 +0000 Subject: [M3devel] slight hudson/opencsw oddity Message-ID: I saw this on current10s also. Notice how last-ok.3799 is in the subdirectories. I'll delete them and we'll see if they come back. Maybe I'll check others. m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls *??????????????? current: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg current--all-pkgs: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg last-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg prev-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg rel-d5.8.2: bin????? lib????? license? pkg ?- Jay From jay.krell at cornell.edu Mon Nov 8 00:42:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:42:35 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> Message-ID: Some quoting problem on the date? Notice also checkout vs. update. So far the Hudson configurations look the same. I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop building the old source and fail if cvs fails, at least initially. I'll maybe do that on current10s also, though maybe I should leave it working/updating. working: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 Building remotely on opencsw_current10s [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC not working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs? -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 ?- Jay ---------------------------------------- > Subject: Re: opencsw/cvs > From: dam at baltic-online.de > Date: Sun, 7 Nov 2010 14:00:50 +0100 > CC: m3devel at elegosoft.com; wagner at elegosoft.com > To: jay.krell at cornell.edu > > Hi Jay, > > Am 06.11.2010 um 00:52 schrieb Jay K: > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > Specifically, here, 10x: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > it is using old source. > > > > But this one, 9s: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > is working. > > This is strange as both seem to use cvs-feature which is ok. However, > the build is quite old and was done with current build system. How does > the proxy-setup look like as both build machines are on internal > network only? > > > Best regards > > -- Dago > From jay.krell at cornell.edu Mon Nov 8 00:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:50:47 +0000 Subject: [M3devel] maximum size bits vs. bytes Message-ID: It appears we might limit data structures to LAST(INTEGER) bits instead of LAST(INTEGER) bytes. Judging from m3core/TextLiteral.i3. I see that measuring in bits instead of bytes is surprisingly convenient, but this seems not great. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:37:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:37:11 +0000 Subject: [M3devel] Hudson/status Message-ID: Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a matter of CVS now I think. Ditto Darwin/AMD64. So I'll "reset" Hudson's state. I'm trying Solaris 2.9 again. I don't remember about Solaris/x86. I'll try again. Later. I *think* everything else is ok -- Linux/x86/amd64, FreeBSD/x86/amd64, Darwin/x86/ppc. ? I'll double check these but later. ? Not sure about OpenBSD/NetBSD. ? Network to OpenBSD seems to not work any longer in Hudson. ? - Jay From jay.krell at cornell.edu Mon Nov 8 01:34:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:34:24 +0000 Subject: [M3devel] field references in m3cg Message-ID: I was slow to realize this. Slow to realize how procs/labels/vars work. Fields need to be small integers that index into a global array of trees, just like procs/labels/vars. Types also should work this way -- that I do binary search for type id is not great. I'll get to this pretty soon as part of making the gcc IR typeful. After I get Hudson into better shape. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:39:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:39:37 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de>, Message-ID: ?>> Notice also checkout vs. update. I think that's it. I think I did the checkout manually. And then here is update succeeding: ?? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/105/console ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de > CC: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: opencsw/cvs > Date: Sun, 7 Nov 2010 23:42:35 +0000 > > > Some quoting problem on the date? > Notice also checkout vs. update. > So far the Hudson configurations look the same. > I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop > building the old source and fail if cvs fails, at least initially. > I'll maybe do that on current10s also, though maybe I should leave it working/updating. > > working: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" > /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC > > > not working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > > > - Jay > > ---------------------------------------- > > Subject: Re: opencsw/cvs > > From: dam at baltic-online.de > > Date: Sun, 7 Nov 2010 14:00:50 +0100 > > CC: m3devel at elegosoft.com; wagner at elegosoft.com > > To: jay.krell at cornell.edu > > > > Hi Jay, > > > > Am 06.11.2010 um 00:52 schrieb Jay K: > > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > > > Specifically, here, 10x: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > > > it is using old source. > > > > > > But this one, 9s: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > > > is working. > > > > This is strange as both seem to use cvs-feature which is ok. However, > > the build is quite old and was done with current build system. How does > > the proxy-setup look like as both build machines are on internal > > network only? > > > > > > Best regards > > > > -- Dago > > > From wagner at elegosoft.com Mon Nov 8 09:40:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 09:40:26 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: Message-ID: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Quoting Jay K : > I saw this on current10s also. > Notice how last-ok.3799 is in the subdirectories. If you see such a name (for longer than a few seconds), then something has crashed during the final exchange of m3 package pools. I don't really know why exactly this happens. It would be great if we could make it as atomic as possible. > I'll delete them and we'll see if they come back. If you see a pattern there, let mw know. Olaf > Maybe I'll check others. > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > *??????????????? > current: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > current--all-pkgs: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > last-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > prev-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > rel-d5.8.2: > bin????? lib????? license? pkg > > > ?- 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 jay.krell at cornell.edu Mon Nov 8 09:50:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 08:50:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: Presumably it's mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* ? I've definitely saw a bunch of these directories, just not with the wrong layout. I've been going to all the nodes and cleaning up/recovering. There is something bad I don't understand that hit many of them. This: ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 The "best" and very not good explanation is an m3cg intermediate format change and incorrect upgrade process. I did make a change in the past week, the removal of set_runtime_hook or such. I made sure my upgrade.py works, which I know isn't what Hudson uses. But I suspect(ed) Hudson does things right. I also added a field to a call within the past few months and it worked ok. So I don't know. - Jay > Date: Mon, 8 Nov 2010 09:40:26 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] slight hudson/opencsw oddity > > Quoting Jay K : > > > I saw this on current10s also. > > Notice how last-ok.3799 is in the subdirectories. > > If you see such a name (for longer than a few seconds), then something > has crashed during the final exchange of m3 package pools. I don't really > know why exactly this happens. It would be great if we could make it > as atomic as possible. > > > I'll delete them and we'll see if they come back. > > If you see a pattern there, let mw know. > > Olaf > > > Maybe I'll check others. > > > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > > * > > current: > > bin lib man www > > last-ok.3799 license pkg > > > > current--all-pkgs: > > bin lib man www > > last-ok.3799 license pkg > > > > last-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > prev-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > rel-d5.8.2: > > bin lib license pkg > > > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:05:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:05:50 +0100 Subject: [M3devel] Hudson/status In-Reply-To: References: Message-ID: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Quoting Jay K : > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > matter of CVS now I think. > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > I'm trying Solaris 2.9 again. > I don't remember about Solaris/x86. I'll try again. Later. > I *think* everything else is ok -- Linux/x86/amd64, > FreeBSD/x86/amd64, Darwin/x86/ppc. FreeBSD/x84 seems to be broken since 17 days: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ PPC_DARWIN has been broken for 7 days: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ Solaris 2.9 hasn't succeeded for more than a month: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ Same for AMD64_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ We should try to get all of these working again and then keep them in that state :-) Currently everything seems to be very unstable, but I haven't said much because (a) I haven't had much time to care and (b) I thought you were doing same major changes on the backend again. Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson display. > ? I'll double check these but later. > ? Not sure about OpenBSD/NetBSD. > ? Network to OpenBSD seems to not work any longer in Hudson. If we should exclude some platforms from the view due to non-available build machines, let me know. You can do that yourself, too at http://hudson.modula3.com:8080/view/cm3-current/configure. 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 Nov 8 10:16:03 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:16:03 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Quoting Jay K : > Presumably it's > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > ? Why/how should that fail unless the machine actually goes down, which didn't really happen, did it? > I've definitely saw a bunch of these directories, just not with the > wrong layout. > I've been going to all the nodes and cleaning up/recovering. > There is something bad I don't understand that hit many of them. > This: > ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal > type: 0x17, at m3cg_lineno 4 > > The "best" and very not good explanation is an m3cg intermediate > format change and incorrect upgrade process. > I did make a change in the past week, the removal of > set_runtime_hook or such. > I made sure my upgrade.py works, which I know isn't what Hudson uses. > But I suspect(ed) Hudson does things right. The Hudson jobs uses the upgrade.sh script, but that should work, too. Actually nothing that didn't compile the core should ever get installed in the cm3-inst/last-ok package pool, but sometimes this doesn't seem to work :-/ > I also added a field to a call within the past few months and it worked ok. > > So I don't know. -- 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 Nov 8 10:18:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:18:45 +0000 Subject: [M3devel] Hudson/status In-Reply-To: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> References: , <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Message-ID: Yes, I'm working on fixing all the Hudson breakage. I have more changes coming. None of them are particularly major, but in proportion to my ability to execute.... :( Everything did work on my machine (*). Hm, It could therefore be the m3cg/ir/interface change, which was an ok change, it just has to be scripted/danced properly. I believe I'll have more m3cg changes soon -- representing fields and types as "ordinals". We do have to be able to make such changes. I would be willing to have the version number actually ever change (I never ever has I believe) and use it to indicate the form and have one cm3cg that handles multiple forms. At least temporarily until they all get updated. But I know many folks dislike that kind of thing. It gets ugly as many versions are supported. I didn't anticipate C++ being such a problem, but I'm still willing to go with it. It is supposed to work, and it does "just work" with g++ 4.x. It just didn't work with g++ 3.x and Sun CC. (*) -- however a) I forgot to checkin m3makefile a few times and b) due to incrementality, it wasn't always using current files. Yep... 2010-11-01 09:59 jkrell * scripts/python/upgrade.py, m3-sys/m3cggen/src/Main.m3, m3-sys/m3middle/src/M3CG_BinRd.m3, m3-sys/m3middle/src/M3CG_Binary.i3, m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h, m3-sys/m3cc/gcc/gcc/m3cg/parse.c: remove the rest of set_runtime_hook 2010-11-01 09:37 jkrell * m3-sys/: m3cggen/src/Main.m3, m3middle/src/M3CG.m3, m3middle/src/M3CG_BinRd.m3, m3middle/src/M3CG_BinWr.m3, m3middle/src/M3CG_Binary.i3, m3middle/src/M3CG_Check.m3, m3middle/src/M3CG_Ops.i3, m3middle/src/M3CG_Rd.m3, m3middle/src/M3CG_Wr.m3, m3back/src/M3C.m3, m3back/src/M3x86.m3, m3cc/gcc/gcc/m3cg/parse.c: remove get_runtime_hook, set_runtime_hook small part remains, until I work m3cggen into upgrade.py so that m3cg.h can be more easily updated - Jay > Date: Mon, 8 Nov 2010 10:05:50 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson/status > > Quoting Jay K : > > > > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > > matter of CVS now I think. > > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > > I'm trying Solaris 2.9 again. > > I don't remember about Solaris/x86. I'll try again. Later. > > I *think* everything else is ok -- Linux/x86/amd64, > > FreeBSD/x86/amd64, Darwin/x86/ppc. > > FreeBSD/x84 seems to be broken since 17 days: > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ > PPC_DARWIN has been broken for 7 days: > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ > Solaris 2.9 hasn't succeeded for more than a month: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ > Same for AMD64_DARWIN: > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ > > We should try to get all of these working again and then keep them > in that state :-) Currently everything seems to be very unstable, > but I haven't said much because (a) I haven't had much time to care and > (b) I thought you were doing same major changes on the backend again. > > Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson > display. > > > I'll double check these but later. > > Not sure about OpenBSD/NetBSD. > > Network to OpenBSD seems to not work any longer in Hudson. > > If we should exclude some platforms from the view due to non-available > build machines, let me know. You can do that yourself, too at > http://hudson.modula3.com:8080/view/cm3-current/configure. > > 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: From jay.krell at cornell.edu Mon Nov 8 10:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:20:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > > > ? > Why/how should that fail unless the machine actually goes down, which > didn't really happen, did it? Indeed, that is rare. Sometimes I have to reboot for some updates. xdarwin/xnbsd often "sleep". But uptime is high all around. I do wish Hudson could manage the power of the systems...leave them mostly off... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:47:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:47:10 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: , Message-ID: This is wierd. It is pthread_create returning -1. I have seen it a number of times, but I also have seen it work ok. I'm going to punt for now and move on to other Hudson breaks. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:40:02 +0000 > Subject: Re: [M3devel] SOLsun/Solaris 2.9/opencsw > > > It works on 2.10 (opencsw current10s). > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: SOLsun/Solaris 2.9/opencsw > > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > > > > Gets as far as: > > --- building in SOLsun --- > > > > ignoring ../src/m3overrides > > > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > stubgen: Processing RemoteView.T > > > > > > *** > > *** runtime error: > > *** Thread client error: -1 > > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > > *** > > > > Abort - core dumped > > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > > > > I'll try 2.10 instead.. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:50:37 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > The Hudson jobs uses the upgrade.sh script, but that should work, too. > Actually nothing that didn't compile the core should ever get installed > in the cm3-inst/last-ok package pool, but sometimes this doesn't seem The important thing is that cm3 and cm3cg need to be updated together. They must always be taken as a matched pair. You may never mix and match. Well, max/match *usually* works. But the way to allow interface changes is to not do that. But those changes are rare... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:59:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:59:42 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Quoting Jay K : >> The Hudson jobs uses the upgrade.sh script, but that should work, too. >> Actually nothing that didn't compile the core should ever get installed >> in the cm3-inst/last-ok package pool, but sometimes this doesn't seem > > The important thing is that cm3 and cm3cg need to be updated together. > They must always be taken as a matched pair. > You may never mix and match. > Well, max/match *usually* works. But the way to allow interface changes > is to not do that. But those changes are rare... Our current separation of Hudson jobs for m3cc and cm3 will only work if we start with m3cc _and_ the new cm3cg can be used by the _old_ cm3 front-end. If we expect more incompatible changes related to the cm3-gcc interface, we should indeed consider a version mechanism there at least to detect mismatches. 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 Nov 8 11:11:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 10:11:38 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com>, , <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Message-ID: > > The important thing is that cm3 and cm3cg need to be updated together. > > They must always be taken as a matched pair. > > You may never mix and match. > > Well, max/match *usually* works. But the way to allow interface changes > > is to not do that. But those changes are rare... > > Our current separation of Hudson jobs for m3cc and cm3 will only work > if we start with m3cc _and_ the new cm3cg can be used by the _old_ > cm3 front-end. If we expect more incompatible changes related to the Hm. Well, it was good to discover this, eventually. It is fine to split the tasks. You can build stuff in whatever order. But the updated files should only be used/copied at the right times/combinations. It shouldn't be difficult. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 9 11:49:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 10:49:10 +0000 Subject: [M3devel] still recovering Hudson.. Message-ID: The incorrect updating of cm3cg in Hudson is expensive to recover from. What I'm doing is for each platform, is the usual... ./boot1.py copy the result to the target machine build it there -- giving an up to date cm3 copy cm3 to a new install make a new CVS checkout boot2.sh overkill, but also a good test originally I was doing this on opencsw where I'm not sure how much succeed we've had, so doing the full boot2 was more valid. and then subset the boot2.sh output and copy it all around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. The FreeBSD4 machine is really slow! I think the CVS checkout took hours! We really need to fix this very soon -- update cm3/cm3cg correctly. I could have sworn a similar update went ok within the past few months. - Jay From wagner at elegosoft.com Tue Nov 9 12:38:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 12:38:21 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: Message-ID: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Quoting Jay K : > The incorrect updating of cm3cg in Hudson is expensive > to recover from. Sorry to hear that. > What I'm doing is for each platform, is the usual... > ./boot1.py > copy the result to the target machine > build it there -- giving an up to date cm3 > > copy cm3 to a new install > make a new CVS checkout > boot2.sh > overkill, but also a good test > originally I was doing this on opencsw where I'm not > sure how much succeed we've had, so doing the full > boot2 was more valid. > > and then subset the boot2.sh output and copy it all > around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. Wouldn't it have been possible to backup all the package pools from from prev-ok and then perform the upgrade in the correct order? > The FreeBSD4 machine is really slow! > I think the CVS checkout took hours! This should not be; but then, something else may run during the daytime either on the server or load the network. > We really need to fix this very soon -- update cm3/cm3cg correctly. > I could have sworn a similar update went ok within the past few months. Have tou got a concrete plan? 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 Nov 9 13:02:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:02:27 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 9 Nov 2010 12:38:21 +0100 > From: wagner > Wouldn't it have been possible to backup all the package pools > from from prev-ok and then perform the upgrade in the correct order? I'm sure there's a better way but I'm doing what I know for now. Slowing me down will probably please some people anyway. :) > > The FreeBSD4 machine is really slow! > > I think the CVS checkout took hours! > > This should not be; but then, something else may run during the daytime > either on the server or load the network. I assumed maybe it is a virtual machine, and lacks "para viritualization"? > Have tou got a concrete plan? Read through more of the code and Hudson configuration and fix it. Mostly seriously. The required behavior should be trivial to implement. I just have to know where to put it. I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" are the problem. I *somewhat* suspect cm3cg is copied from one task to the other merely at the wrong time. But I have to look through the code and Hudson tasks. I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, at the same time m3cc would do its normal build. Anyway, I just have to poke around some. - Jay From jay.krell at cornell.edu Tue Nov 9 13:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:05:38 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: ps: current, last-ok, prev-ok, etc. I don't know what all these are. So I just make a valid current install and replace them all. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] still recovering Hudson.. > Date: Tue, 9 Nov 2010 12:02:27 +0000 > > > ---------------------------------------- > > Date: Tue, 9 Nov 2010 12:38:21 +0100 > > From: wagner > > > Wouldn't it have been possible to backup all the package pools > > from from prev-ok and then perform the upgrade in the correct order? > > > I'm sure there's a better way but I'm doing what I know for now. > Slowing me down will probably please some people anyway. :) > > > > > The FreeBSD4 machine is really slow! > > > I think the CVS checkout took hours! > > > > This should not be; but then, something else may run during the daytime > > either on the server or load the network. > > > I assumed maybe it is a virtual machine, and lacks "para viritualization"? > > > Have tou got a concrete plan? > > > Read through more of the code and Hudson configuration and fix it. > Mostly seriously. > The required behavior should be trivial to implement. I just have to know > where to put it. > > > > I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" > are the problem. > I *somewhat* suspect cm3cg is copied from one task to the other merely > at the wrong time. But I have to look through the code and Hudson tasks. > I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, > at the same time m3cc would do its normal build. > Anyway, I just have to poke around some. > > > > - Jay > From jay.krell at cornell.edu Tue Nov 9 13:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:44:19 +0000 Subject: [M3devel] last-ok.1234 Message-ID: just a sample before I clean it up... new.elego.de [~/work/cm3-inst/new] hudson % ls -l total 24 drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current--all-pkgs/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 current--lastok-build/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.23891/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.25217/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.41276/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.49455/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.63073/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.72551/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 prev-ok/ drwxrwx--- 8 hudson Ghudson 8 Feb 12 2010 rel-d5.7.1/ From wagner at elegosoft.com Tue Nov 9 14:20:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 14:20:30 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Quoting Jay K : > ps: current, last-ok, prev-ok, etc. I don't know what all these are. > So I just make a valid current install and replace them all. I thought I had explained that some time ago, but maybe I forgot. So here is the gist: o current, last-ok, prev-ok are all complete package pools + compiler that contain a complete cm3 installation o for builds, current is initialized from last-ok; then packages are built and shipped to current o if a build succeeds: - prev-ok is replaced by last-ok - last-ok is replaced by current Thus we should always have a backup for recovery in case something goes wrong. And last-ok should always be exactly what its name indicates (the last working version) (it seems that this invariant sometimes does not hold :-/) o tests usually just use last-ok Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] still recovering Hudson.. >> Date: Tue, 9 Nov 2010 12:02:27 +0000 >> >> >> ---------------------------------------- >> > Date: Tue, 9 Nov 2010 12:38:21 +0100 >> > From: wagner >> >> > Wouldn't it have been possible to backup all the package pools >> > from from prev-ok and then perform the upgrade in the correct order? >> >> >> I'm sure there's a better way but I'm doing what I know for now. >> Slowing me down will probably please some people anyway. :) >> >> >> > > The FreeBSD4 machine is really slow! >> > > I think the CVS checkout took hours! >> > >> > This should not be; but then, something else may run during the daytime >> > either on the server or load the network. >> >> >> I assumed maybe it is a virtual machine, and lacks "para viritualization"? >> >> > Have tou got a concrete plan? >> >> >> Read through more of the code and Hudson configuration and fix it. >> Mostly seriously. >> The required behavior should be trivial to implement. I just have to know >> where to put it. >> >> >> >> I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" >> are the problem. >> I *somewhat* suspect cm3cg is copied from one task to the other merely >> at the wrong time. But I have to look through the code and Hudson tasks. >> I also suspected it worked right, in that the copy is done in >> m3cc/src/m3makefile, >> at the same time m3cc would do its normal build. >> Anyway, I just have to poke around some. >> >> >> >> - 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 jay.krell at cornell.edu Wed Nov 10 08:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 07:47:57 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: > I thought I had explained that some time ago, but maybe I forgot. So here > is the gist: > > o current, last-ok, prev-ok are all complete package pools + compiler that > contain a complete cm3 installation > o for builds, current is initialized from last-ok; then packages > are built and shipped to current > o if a build succeeds: > - prev-ok is replaced by last-ok > - last-ok is replaced by current > Thus we should always have a backup for recovery in case something > goes wrong. And last-ok should always be exactly what its name > indicates (the last working version) (it seems that this invariant > sometimes does not hold :-/) > o tests usually just use last-ok Do we need all this? I guess it is ok. There should be just two when idle and three during a build. ?But there are more than that currently, more than what you list. But we don't need them to be complete. They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. More generally I thinking of digging into the Hudson stuff. I think I know what to do about cm3cg, at least. There are two kinds of "ships" or installs. There is ship/install on top of the "currently running" install, and there is install to other than it, possibly to a directory that started empty (recently). Shipping of cm3 doesn't do anything. This could be viewed as a limitation -- the comments indicate it is at least partly due to shipping in-use files doesn't work on some operating systems (not just Windows, in fact, it is easy to do on Windows -- rename away first). However it is also a good thing. Shipping of m3cc/cm3g does do something. I assert that shipping either of cm3 or cm3cg on top of the "currently running" install is wrong. Shipping into other, a new empty directory, is perfectly fine. In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. For the "currently running" install, ship should do nothing, and should instead be done "outside the usual system" via sh/python. Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. And the config files (I suspect also already the case). That way they can be updated together.? *** the very important point ** Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? I'd like there to be as few of tasks as possible. "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. Related: we currently keep all snapshots on the build machines. We shouldn't keep so many. ?- Jay From jay.krell at cornell.edu Wed Nov 10 09:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 08:32:01 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: References: , , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , , , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, Message-ID: The fact that upgrade.sh does NOT "ship" m3cc, but installs it in a "special" way/time along with cm3, looks promising I have to look closer..to confirm/deny that things are written correctly or not. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 10 Nov 2010 07:47:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson structure? > > > > I thought I had explained that some time ago, but maybe I forgot. So here > > is the gist: > > > > o current, last-ok, prev-ok are all complete package pools + compiler that > > contain a complete cm3 installation > > o for builds, current is initialized from last-ok; then packages > > are built and shipped to current > > o if a build succeeds: > > - prev-ok is replaced by last-ok > > - last-ok is replaced by current > > Thus we should always have a backup for recovery in case something > > goes wrong. And last-ok should always be exactly what its name > > indicates (the last working version) (it seems that this invariant > > sometimes does not hold :-/) > > o tests usually just use last-ok > > > Do we need all this? > I guess it is ok. There should be just two when idle and three during a build. > But there are more than that currently, more than what you list. > > > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. > > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that started empty (recently). > > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is at least partly > due to shipping in-use files doesn't work on some operating systems (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. > > > I assert that shipping either of cm3 or cm3cg on top of the "currently running" > install is wrong. > > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. > > > For the "currently running" install, ship should do nothing, and should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. > And the config files (I suspect also already the case). > > > That way they can be updated together. *** the very important point ** > > > Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. > Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. > > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. > > > - Jay > > From wagner at elegosoft.com Wed Nov 10 09:48:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 09:48:22 +0100 Subject: [M3devel] Hudson structure? In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Quoting Jay K : > >> I thought I had explained that some time ago, but maybe I forgot. So here >> is the gist: >> >> o current, last-ok, prev-ok are all complete package pools + compiler that >> contain a complete cm3 installation >> o for builds, current is initialized from last-ok; then packages >> are built and shipped to current >> o if a build succeeds: >> - prev-ok is replaced by last-ok >> - last-ok is replaced by current >> Thus we should always have a backup for recovery in case something >> goes wrong. And last-ok should always be exactly what its name >> indicates (the last working version) (it seems that this invariant >> sometimes does not hold :-/) >> o tests usually just use last-ok > > Do we need all this? > I guess it is ok. There should be just two when idle and three > during a build. > ?But there are more than that currently, more than what you list. test and build jobs may run in parallel, I think test-all-pkgs uses its own current. > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), > m3core, libm3. > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that > started empty (recently). > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is > at least partly > due to shipping in-use files doesn't work on some operating systems > (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. Yes. That's not consequent. I seem to remember that there were objections to _not_ ship cm3cg to bin though. > I assert that shipping either of cm3 or cm3cg on top of the > "currently running" > install is wrong. > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as > the destination doesn't yet exist. > > For the "currently running" install, ship should do nothing, and > should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg > is dealt with. > And the config files (I suspect also already the case). > > That way they can be updated together.? *** the very important point ** Yes. > Related question: now that we have far less frequent builds, can we > merge the m3cc and build Hudson tasks? I'd rather avoid that. The m3cc builds takes hours on some systems, and _usually_ (unless someone is working on the backend) this should not need to be built at all. On the other hand: you may be right. We could easily just disable all the m3cc jobs for the time being and always build m3cc together with the other core packages in the -build- jobs. > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations > to test, etc. > Though granularity is also nice -- if some things are broken, still > nice to see some tasks succeeding. > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. Do we? We shouldn't keep any on the build machine. Snapshots are (should be?) copied to birch.elegosoft.com and kept there for some time. 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 Wed Nov 10 10:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 09:08:53 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, , <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Message-ID: ?> I seem to remember that there were objections to _not_ ship cm3cg to bin though I think it actually ship to bin/target or bin/host/target, but that is a different matter. Anyway, the problem is solved, in that upgrade.sh doesn't ship m3cc. As long as we use upgrade.sh and don't just launch into a buildship of everything, ok. ?> stuff running in parallel ? ? ah ? ?> The m3cc builds takes hours on some systems ? ? They should be faster now and better at being incremental. ? (somewhat contradictory: I used to throw -disable-dependency-checking ? as a speed up, now I don't; Cygwin is probably significantly slower ? therefore, far more forks(), but other platforms not) ? ? But that doesn't completely counter your point. ? gmp/mpfr/mpc were a significant portion, almost gone now ??? (I'm tempted to further reduce them -- one of the main ??? existing dependencies is in loop unrolling, but ??? the frontend I think already does loop unrolling; ??? but cm3cg should be able to do better since it does ??? more sophisticated analysis -- and still, cm3cg ??? has available efficient 64bit integers without gmp, ??? the need for gmp is in general therefore, unclear; ??? the need for mpfr is actually sort of "more clear", except ??? that it isn't used where I thought it might be -- it isn't ??? used for floating point constant propagation, but for implementing ??? builtin" functions; besides, floating point is essentially ??? identical across all build hosts, so doesn't need to be "simulated"; ??? and mpc is for complex math, which we never use..mpfr ??? and mpc are completely gone, gmp is much smaller than previously) I'm torn now. I want to test an m3cg.i3 change, but if it fails, I don't want to do the tedious recovery. Maybe if I'm quick, only one or two machines will see it? ?- Jay From jay.krell at cornell.edu Wed Nov 10 12:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 11:37:10 +0000 Subject: [M3devel] rcc_upgradecm3.cmd Message-ID: Randy, code like this: pushd ..\..\.. if exist "bin\cm3.exe" if exist "pkg" set CM3_ROOT=%CD%& popd & goto FoundRoot is almost exactly equivalent to: if exist "..\..\..\bin\cm3.exe" if exist "..\..\..\pkg" set CM3_ROOT=..\..\..& popd & goto FoundRoot the advantage of the second form is fewer intermediate side effects ? i.e. not cd'ing around to the various possible path, just using them more directly the disadvantage of the second form is the ".." survive? and may be unsightly. ? But leaving ".." will work ok with very little exception. The ".." can be removed via e.g.: call :GetFullPath CM3_ROOT %CM3_ROOT% goto :end_GetFullPath :GetFullPath set %1=%~f2 goto :eof :end_GetFullPath I believe that would also work. There are other ways.. such as looping over all the possibilities and taking the first that works. anyway.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 13:48:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 12:48:14 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile Message-ID: == package /Users/jay/dev2/cm3/elego/m3msh == ?+++ /cm3/bin/cm3??? -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling M3MiniShell.m3 ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' ? m3_backend => 1 I've been sprinkling volatile around, no luck yet.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 14:15:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:15:31 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: nevermind, I found a workaround that is probably ok a deoptimization but it shouldn't be common and significant But it also isn't the expected one. I figured volatile somewhere would do the trick, not avoiding inlining. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > From jay.krell at cornell.edu Wed Nov 10 14:39:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:39:08 +0000 Subject: [M3devel] hudson/m3cg ir changes Message-ID: Looking into why the m3cg.i3 changes broke... http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull This log doesn't show the "safe" upgrade that avoids ship and then ships all at once process. But it does show something else that should work: ?it builds all ?and then ships all (including cm3cg) ?and then presumably would handle cm3 specially However when it goes to ship cm3, it compiles stuff. That should already be compiled. And cm3cg had just been updated. Here: === package m3-sys/cm3 === +++ cm3 -build -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' +++ ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 This I don't understand. And can't trivially reproduce. I understand that every time you build cm3, it will recompile Version.i3 and another file. But 1) this tries to recompile more and 2) for me, cm3 -ship never recompiles anything anyway Also notice that LINUXLIBC6 never broke. Hm. Given the break Oct 27 and what I might have done to fix, that's inconclusive. You can see LINUXLIBC6 also compiling during -ship. So, two things now... change the process to use upgrade.sh. and/or find out why -ship is compiling anything. - Jay From hosking at cs.purdue.edu Wed Nov 10 16:14:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Nov 2010 10:14:01 -0500 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: Did you disable inlining on everything? Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 10 Nov 2010 12:48:14 +0000 >> Subject: [M3devel] setjmp/longjmp still missing volatile >> >> >> == package /Users/jay/dev2/cm3/elego/m3msh == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling M3MiniShell.m3 >> ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': >> ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' >> m3_backend => 1 >> >> >> >> I've been sprinkling volatile around, no luck yet.. >> >> - Jay >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Nov 10 16:22:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 16:22:31 +0100 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: References: Message-ID: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Quoting Jay K : > Looking into why the m3cg.i3 changes broke... > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull > > This log doesn't show the "safe" upgrade that avoids ship and then > ships all at once process. > > But it does show something else that should work: > ?it builds all > ?and then ships all (including cm3cg) > ?and then presumably would handle cm3 specially > > However when it goes to ship cm3, it compiles stuff. That should > already be compiled. > And cm3cg had just been updated. > > Here: > > === package m3-sys/cm3 === > +++ cm3 -build > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > $RARGS && cm3 -ship $RARGS > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > +++ > ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at > m3cg_lineno 4 > compilation terminated. > m3_backend => 1 > > This I don't understand. > And can't trivially reproduce. > I understand that every time you build cm3, it will recompile > Version.i3 and another file. > But 1) this tries to recompile more and 2) for me, cm3 -ship never > recompiles anything anyway What you probably see is that a set of packages is first built locally and then with buildship. You cannot just use ship on a locally compiled set (with overrides), because the compiler will refuse to do that as the dependencies have changed. > Also notice that LINUXLIBC6 never broke. > Hm. Given the break Oct 27 and what I might have done to fix, that's > inconclusive. > You can see LINUXLIBC6 also compiling during -ship. This is strange. > So, two things now... change the process to use upgrade.sh. > and/or find out why -ship is compiling anything. If upgrade.sh already works OK, how could the last-ok installations on the Hudson nodes become corrupted? Ideally, the cm3-current-build job should fail and retry everything with upgrade.sh. Probably the new incompatible cm3cg has already been installed then in current, and we would need to restart with last-ok. Could that be the problem? Then it should be easy to fix (in scripts/regression/defs.sh in test_build_system). 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 Wed Nov 10 22:04:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:04:01 +0000 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> References: , <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Message-ID: > What you probably see is that a set of packages is first built locally > and then with buildship. You cannot just use ship on a locally compiled Oops, you are right. I misread the log. > > You can see LINUXLIBC6 also compiling during -ship. > > This is strange. I probably misread the log there too. > If upgrade.sh already works OK, how could the last-ok installations > on the Hudson nodes become corrupted? Ideally, the cm3-current-build > job should fail and retry everything with upgrade.sh. Probably the > new incompatible cm3cg has already been installed then in current, and > we would need to restart with last-ok. Could that be the problem? > Then it should be easy to fix (in scripts/regression/defs.sh in > test_build_system). Thanks, I will look further. Basically, endeavor to use upgrade more and buildship less. ?- Jay From jay.krell at cornell.edu Wed Nov 10 22:00:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:00:34 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , Message-ID: No, and it doesn't. Variables are introduced later. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Wed, 10 Nov 2010 10:14:01 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > Did you disable inlining on everything? > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would > do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > > > From jay.krell at cornell.edu Thu Nov 11 00:29:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 23:29:33 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , , Message-ID: I'll try to run volatization after the variables are introduced. I still like the idea of the frontend unnesting nested functions. It'd probably help here. I'm very willing to selectively suppress inlining to fix this, which I had done, but I'd rather not broadly suppress inlining. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] setjmp/longjmp still missing volatile > Date: Wed, 10 Nov 2010 21:00:34 +0000 > > > No, and it doesn't. > Variables are introduced later. > > - Jay > > ________________________________ > > From: hosking at cs.purdue.edu > > Date: Wed, 10 Nov 2010 10:14:01 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > > > Did you disable inlining on everything? > > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > > > > nevermind, I found a workaround that is probably ok > > a deoptimization but it shouldn't be common and significant > > But it also isn't the expected one. I figured volatile somewhere would > > do the trick, > > not avoiding inlining. > > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Wed, 10 Nov 2010 12:48:14 +0000 > > Subject: [M3devel] setjmp/longjmp still missing volatile > > > > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > > --- building in AMD64_DARWIN --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling M3MiniShell.m3 > > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > > might be clobbered by 'longjmp' or 'vfork' > > m3_backend => 1 > > > > > > > > I've been sprinkling volatile around, no luck yet.. > > > > - Jay > > > > > > > > > > > > > > > From jay.krell at cornell.edu Mon Nov 15 11:18:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Nov 2010 10:18:40 +0000 Subject: [M3devel] configur -enable-checking vs. types Message-ID: jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression struct { } * struct { } D.1466 = &M_RsrcFilter; I don't think this is actually "struct value" vs. "struct pointer". It is actually "struct1 pointer" vs. "struct2 pointer". So, I can probably just cast it away. But it points to a need in compiler to deal differently with types. They should be small integers like procs/labels/vars, I believe. So should fields. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 16 01:00:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 00:00:53 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: Message-ID: I tried various casts, no luck. I'm confused here.. :( - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: configur -enable-checking vs. types > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > struct > { > } * > > struct > { > } > > D.1466 = &M_RsrcFilter; > > > > I don't think this is actually "struct value" vs. "struct pointer". > It is actually "struct1 pointer" vs. "struct2 pointer". > So, I can probably just cast it away. > But it points to a need in compiler to deal differently with types. > They should be small integers like procs/labels/vars, I believe. > So should fields. > > > - Jay From jay.krell at cornell.edu Tue Nov 16 22:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 21:10:58 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: , Message-ID: The problem seems to be that we set the type for the segment, use that, and then change it. M3CG_HANDLER (BIND_SEGMENT) { gcc_assert (align >= !!size); current_segment = var; TREE_TYPE (var) = m3_build_type (type, size, align); M3CG_HANDLER (DECLARE_SEGMENT) { TREE_TYPE (var) = m3_build_type_id (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT, type_id); layout_decl (var, BIGGEST_ALIGNMENT); however, when I fix lots of configure -enable-checking problems, I get crashes. I suspect this one needs to be this way -- need the correct segment size. Making more passes will enable getting it right up front. Later. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: configur -enable-checking vs. types > Date: Tue, 16 Nov 2010 00:00:53 +0000 > > > I tried various casts, no luck. I'm confused here.. :( > > - Jay > > > ________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: configur -enable-checking vs. types > > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > > struct > > { > > } * > > > > struct > > { > > } > > > > D.1466 = &M_RsrcFilter; > > > > > > > > I don't think this is actually "struct value" vs. "struct pointer". > > It is actually "struct1 pointer" vs. "struct2 pointer". > > So, I can probably just cast it away. > > But it points to a need in compiler to deal differently with types. > > They should be small integers like procs/labels/vars, I believe. > > So should fields. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 17 22:55:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Nov 2010 21:55:24 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 Archiving artifacts Recording fingerprints Finished: FAILURE Can we format the time in a way that doesn't have any spaces? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Nov 18 09:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 09:16:39 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: Message-ID: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Quoting Jay K : > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > Archiving artifacts > Recording fingerprints > Finished: FAILURE > > Can we format the time in a way that doesn't have any spaces? I'm sure I already fixed that one months ago, though I don't remember the details. Has somehow an old script been installed in bin/cvs? 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 Nov 18 12:15:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:15:20 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:36:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:36:48 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Quoting Jay K : > Hm. Yes and no. I hadn't looked enough, but I think it is still broken. > There is $HOME/bin/cvs. I didn't know. > I guess it is mainly to avoid -z3. > Which rings a bell. We had some problem with that. Yes. I know that the first version didn't work, but I fixed that. And I think it _did_ run well some time. > Build #103 is not current. It is from Nov 8. > Before it, a bunch of success. Since it, a bunch of failure. > I had failed to look if the failures were all the same. > They are not. In fact the CVS failures seem to be all/mainly Nov 8. > > HOWEVER the later failures have been fixed in CVS. > Even though cvs upd isn't erroring, it also isn't working. > > I'm manually updating now, so the evidence will be lost. > But I'm sure it will either come back or is easily deliberately brought back. I'll have a look at the weekend, 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 Nov 18 12:38:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:38:12 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: scripts/regression/cvs.sh was in CVS It doesn't seem to work -- quotes are lost. cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, I put in place, we'll see. Would be nice to only quote if there are spaces though. Can we make Hudson use a date form without spaces? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:15:20 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:43:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:43:15 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Quoting Jay K : > scripts/regression/cvs.sh was in CVS > It doesn't seem to work -- quotes are lost. > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. Strange. > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > I put in place, we'll see. Would be nice to only quote if there are > spaces though. > > Can we make Hudson use a date form without spaces? I don't think so. Not without changing the CVS plugin source at least. 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 Nov 18 12:48:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:48:03 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Message-ID: > And I think it _did_ run well some time. It ran without error, I can see that. But across a few days/builds, no changed. #97 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/97/console no changes detected Deleting old artifacts from #95 #96 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/96/console $ no changes detected L?sche alte Artefakte von #94 Maybe I logged in around that time, and that caused something to change from German to English? But the date format is the same either way. - We'll see if my updated cvs helps? - Maybe if you merely login it'll change back and that's it?? (Great example of touching something and it breaks/fixes..but we don't know if that was it. It appears to pickup no changes for a while, even in German, and there is another language change if you keep going back... I went all the way back to the oldest retained build, it doesn't seem to have ever picked up any changes. We'll see with my updated cvs..I'd rather write these wrappers in Python, of course. Or Modula-3. Or quake if possible. :) ) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 18 12:53:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:53:43 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> References: , , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Message-ID: Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Thu Nov 18 13:26:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 12:26:32 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: ,,, , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com>, Message-ID: Looking good. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/120/console - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:53:43 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Fri Nov 19 10:12:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 09:12:16 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining Message-ID: parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 11:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 10:01:44 +0000 Subject: [M3devel] bind_segment vs. declare_segment? Message-ID: I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:39:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:39:00 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: Message-ID: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> This is a shame. 1. gcc supports nested functions. 2. gcc supports inlining. 3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong. Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote: > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:43:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:43:03 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: Message-ID: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled. Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote: > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 19 16:36:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Nov 2010 16:36:05 +0100 Subject: [M3devel] m3cc compilation errors Message-ID: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Currently I cannot compile m3cc on AMD64-FREEBSD: ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token gmake: *** [m3cg/parse.o] Error 1 "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg 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 Nov 19 17:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:20:00 +0000 Subject: [M3devel] m3cc compilation errors In-Reply-To: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> References: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Message-ID: book2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c Connection closed by 88.198.39.217 [ I fell asleep] cvs [commit aborted]: end of file from server (consult above messages if any) [ I woke up[ jbook2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v <-- parse.c new revision: 1.458; previous revision: 1.457 - Jay > Date: Fri, 19 Nov 2010 16:36:05 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc compilation errors > > Currently I cannot compile m3cc on AMD64-FREEBSD: > > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token > gmake: *** [m3cg/parse.o] Error 1 > "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake > runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg > > 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: From jay.krell at cornell.edu Fri Nov 19 17:21:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:21:02 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: Good question. I can look into that. But notice that it will *definitely* be different. But maybe not in a critical way -- they use trampolines. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:39:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining This is a shame.1. gcc supports nested functions.2. gcc supports inlining.3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong.Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote:parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:24:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:24:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:41:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:41:24 +0000 Subject: [M3devel] incorrect copying in Hudson? Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_DARWIN/61/console t/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post /rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/ rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/last-ok/ pkg/m3core/src/text: name too long (not copied) I had caused this before manually installing. But I'm not sure I did this time. I'll clean it up. We'll see if it comes bcak. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 18:08:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 17:08:14 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, Message-ID: Another option would be that every time we get an offset load against it, see if it is beyond the current size, in which case grow the size and relayout. That could end up relayout many times. Besides accessing beyond its size, the problem, for configure -enable-checking, is that we later completely replace the type, so returning its address from the module initializer ends up a different type than the actual data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 16:24:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 19:51:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 13:51:49 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: <3586ABC8-1EE1-4E1D-8B81-67450C7E51BA@cs.purdue.edu> The trampoline is purely a method for constructing a closure that can be passed. So long as we are using the same mechanism to grab the static chain we should be working similarly. We just need to emulate the effect of the trampoline on the rest of gcc. On Nov 19, 2010, at 11:21 AM, Jay K wrote: > Good question. I can look into that. But notice that it will *definitely* be different. But maybe not > in a critical way -- they use trampolines. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:39:00 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining > > This is a shame. > 1. gcc supports nested functions. > 2. gcc supports inlining. > 3. gcc should work with both nested functions and inlining. > > If gcc can handle all of this for C but not M3 then we must be doing something wrong. > Can we see how similar code fragments behave when expressed in C? > > On Nov 19, 2010, at 4:12 AM, Jay K wrote: > > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 09:43:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 08:43:56 +0000 Subject: [M3devel] LONGINT in frontend? Message-ID: How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 13:47:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 12:47:41 +0000 Subject: [M3devel] gmp dependency? Message-ID: I already eliminated the mpc and mpfr dependency. They are only used for "builtins", which we never use. And drastically reduced gmp use. These were a big part of building m3cc. The remaining use of gmp appears to only be in tree-ssa-loop-niter.c which determines/estimates the number of times a loop runs, I believe in order to possibly unroll it, or other loop optimizations. Considering removing this, in order to cut the gmp dependency? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 14:02:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 13:02:29 +0000 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? Message-ID: Olaf, I'm not sure Hudson works right in terms of using/copying the right prebuilt cm3cg at the right time. I see evidence of using out of date cm3cg. Given that we don't ever by default clean m3cc. And given that I adjusted stuff to use upgrade.sh and I believe install cm3cg and cm3 together at the right time. But given that I didn't look into or adjust how the pairs of tasks (m3cc and build) interace. Given that I think build works on its own. I request that we stop all the m3cc tasks and remove or at least disable the PREBUILD_CM3CG stuff. i.e. asking agreement/permission. I'm willing to do it. Alternately stated: I understand and can fix if needed upgrade.sh. Though I do use upgrade.py myself, all the time. We should consider it..but they are about the same. Anyway, my point is, I understand, like, "a single workspace" setup. Maybe Hudson should work that way? Now, I understand there is granularity. You want to see some Hudson tasks finish, before others run. So, in the interest of that, I'm very willing to leave m3cc first, and if that succeeds, have build build its own cm3cg. That is wasteful, but can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 15:11:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 14:11:26 +0000 Subject: [M3devel] enable-checking vs. static link Message-ID: So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Nov 20 17:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 20 Nov 2010 11:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: Message-ID: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Target.Int is appropriate here, not LONGINT. Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote: > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 21:55:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 20:55:10 +0000 Subject: [M3devel] enable-checking vs. static link In-Reply-To: References: Message-ID: Alas.. == package /Users/jay/dev2/cm3/m3-tools/m3tk == new source -> compiling StdFormat.m3 ../src/astdisplay/StdFormat.m3: In function 'StdFormat__Enumeration_type': ../src/astdisplay/StdFormat.m3:193:0: internal compiler error: Bus error Please submit a full bug report, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: enable-checking vs. static link Date: Sat, 20 Nov 2010 14:11:26 +0000 So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 22:35:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 21:35:40 +0000 Subject: [M3devel] Hudson vs. ..? Message-ID: Hudson is great. and by ".." I don't mean Tinderbox or any alternative. I mean vs. my own ongoing development. Things are working for me. I build AMD64_DARWIN repeatly, using the built cm3, with -O3. It all works. Sometimes I boot1.py to other platforms, which exercises a fair amount. Yet Hudson is getting various internal compiler errors, on some platforms. e.g. Darwin, Solaris. But not all, I think e.g. FreeBSD, Linux. And it isn't using optimization realize. Possible but unlikely that -O3 is covering up problems. Usually optimization only ever hurts, doesn't help, in terms of getting a successful compilation. I strongly suspect this is due to cm3 vs. cm3cg mismatch. I believe upgrade.sh works. I believe the regression scripts work now, by using upgrade.sh. Except if you run "build" w/o "m3cc" and it picks up old cm3cg. Can we somehow easily "reset" everything? I have tried somewhat, but it was tedious and didn't clearly work. Going back to rel 5.8.6 and then upgrade.sh should work. I don't want to have to visit every node or do my own boot1.py + boot2.sh again. I did that fairly recently, when Hudson was definitely not upgrading cm3/cm3cg properly. I *think* it does now, but I think it got mixed up in some cases. e.g. maybe by building "build" w/o building "m3cc"? Maybe that guarantees it picks up an old mismatched cm3cg? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 01:02:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 01:02:20 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: Message-ID: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Quoting Jay K : > > Hudson is great. > and by ".." I don't mean Tinderbox or any alternative. > I mean vs. my own ongoing development. > > Things are working for me. > I build AMD64_DARWIN repeatly, using the built cm3, with -O3. > > It all works. > > Sometimes I boot1.py to other platforms, which exercises a fair amount. > > Yet Hudson is getting various internal compiler errors, on some platforms. > e.g. Darwin, Solaris. Yes, those are broken currently. > But not all, I think e.g. FreeBSD, Linux. > And it isn't using optimization realize. > Possible but unlikely that -O3 is covering up problems. Usually > optimization > only ever hurts, doesn't help, in terms of getting a successful > compilation. > > I strongly suspect this is due to cm3 vs. cm3cg mismatch. > I believe upgrade.sh works. > I believe the regression scripts work now, by using upgrade.sh. > Except if you run "build" w/o "m3cc" and it picks up old cm3cg. > > Can we somehow easily "reset" everything? > I have tried somewhat, but it was tedious and didn't clearly work. > > Going back to rel 5.8.6 and then upgrade.sh should work. I think we can insert that as a last fallback: build from the last-rel version (which should be 5.8.6). I'll have a look at it tomorrow. > I don't want to have to visit every node or do my own boot1.py + > boot2.sh again. > I did that fairly recently, when Hudson was definitely not upgrading > cm3/cm3cg properly. > I *think* it does now, but I think it got mixed up in some cases. > e.g. maybe by building "build" w/o building "m3cc"? Maybe that > guarantees it picks > up an old mismatched cm3cg? On your own systems (xdarwin) you could easily inject a working pair of cm3/cm3cg into the last-ok pool, that should fix mismatches. 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 Nov 21 01:15:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:15:37 +0000 Subject: [M3devel] Hudson vs. ..? In-Reply-To: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: > On your own systems (xdarwin) you could easily inject a working pair > of cm3/cm3cg into the last-ok pool, that should fix mismatches. Yeah, I thought so, and tried, no luck. I can try again. Later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 01:26:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:26:49 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 13:24:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 13:24:38 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: <20101121132438.dlvido2jgggw8go8@mail.elegosoft.com> Quoting Jay K : > > > On your own systems (xdarwin) you could easily inject a working pair > > of cm3/cm3cg into the last-ok pool, that should fix mismatches. > > Yeah, I thought so, and tried, no luck. > I can try again. Later. I think I've found the reason for that. Let's see if it suffices to get everything into working condition again. 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 Nov 21 14:16:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 14:16:26 +0100 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? In-Reply-To: References: Message-ID: <20101121141626.tmgwxxzaos4ckso0@mail.elegosoft.com> Quoting Jay K : I didn't notice this mail before... see below > Olaf, I'm not sure Hudson works right in terms of using/copying the right > prebuilt cm3cg at the right time. > > I see evidence of using out of date cm3cg. > > Given that we don't ever by default clean m3cc. > And given that I adjusted stuff to use upgrade.sh and I believe > install cm3cg and cm3 together at the right time. > > But given that I didn't look into or adjust how the pairs of tasks > (m3cc and build) interace. > > Given that I think build works on its own. > > I request that we stop all the m3cc tasks and remove or at least > disable the PREBUILD_CM3CG stuff. > i.e. asking agreement/permission. I'm willing to do it. I'm not against disabling all the m3cc tasks and just build m3cc in the usual way in the build jobs. That was just a performance optimization making sense we built release candiate after release candidate again and again on many more platforms than now. I suggest something like this: % cvs diff -u scripts/regression/ Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. cvs diff: Diffing scripts/regression Index: scripts/regression/hudson_build_system.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/regression/hudson_build_system.sh,v retrieving revision 1.21 diff -u -u -r1.21 hudson_build_system.sh --- scripts/regression/hudson_build_system.sh 21 Nov 2010 13:00:38 -0000 1.21 +++ scripts/regression/hudson_build_system.sh 21 Nov 2010 13:14:07 -0000 @@ -37,7 +37,7 @@ ;; esac fi -if [ "$CLEAN" = "false" ]; then +if [ "$CLEAN" = "false" && "$USE_PREBUILT_CM3CG" = "true" ]; then if [ -x "${CM3CG}" ]; then echo "checking for working pre-built cm3cg in ${CM3CG}" cp -p "${CM3CG}" ${WS}/cm3cg > Alternately stated: > I understand and can fix if needed upgrade.sh. > Though I do use upgrade.py myself, all the time. We should > consider it..but they are about the same. > Anyway, my point is, I understand, like, "a single workspace" setup. > Maybe Hudson should work that way? > Now, I understand there is granularity. You want to see some > Hudson tasks finish, > before others run. So, in the interest of that, I'm very willing > to leave m3cc first, > and if that succeeds, have build build its own cm3cg. That is wasteful, but > can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Single build workspace setup should be OK now. Shall I disable all the m3cc jobs? We'll keep all the test jobs though... Olaf PS: The lastok and release installations on your Darwin machine are all empty, see http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/63/console. -- 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 Nov 21 16:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:44:40 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 16:48:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:48:00 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:03:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:03:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> Message-ID: > In general, it is OK for a cross-host to impose smaller restrictions than the target. I don't think I agree. To some extent it is unavoidable: e.g. compiling really really large files However, I ought to be able to do this? typedef struct { int a[1UL << 40]; } foo; foo* a; I can in C, from a 32host to a 64bit target. The way to allow it is reasonably easy, just tedious in Modula- w/o LONGINT or operator overloading. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:48:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:08:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:10:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:10:59 +0000 Subject: [M3devel] operator overloading? Message-ID: Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:33:31 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:33:31 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Some of us find operator overloading anathema because it obscures the actual underlying code. It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain situations. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote: > Isn't it at least better than current situation of using INTEGER? > I understand in the future LONGINT might not suffice and Target.Int might be desired. > But today LONGINT suffices and lets more things work. > > > Granted you can no longer compile with older compilers. > > > Surely what we could at that time is introduce INTEGER128. > Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, > and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? > > > And perhaps by then have switched LONGINT to Target.Int? > Perhaps by then we'll have operator overloading in Modula-3? > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 10:44:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. > > On Nov 20, 2010, at 7:26 PM, Jay K wrote: > > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:50:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:50:22 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , , , , , Message-ID: I disagree there also. 32bit addresses/size_t and 64bit quantities can be mixed reasonably, and have been for a very long time in a *lot* of code. There are plenty of files and volumes over 2GB in size manipulated by 32 bit code. The 32-bit world will continue for a while -- phones, iPad, etc. But yet iPad is available with 64GB storage. Are the 53bits of precision in double for migration to a 53bit world? I agree the *name* LONGINT is a hack though, in the poor tradition of C's "long long". Again again again, 32bit host C compilers have been targeting 64bit targets for a very long time and continue to do so. And I would hope they don't have the same problem we have. I know gcc has this "HOST_WIDE_INT" for this reason -- long long for 32bit hosts targeting 64bit. Obviously a bit inefficient, but probably really ok and worth it. Also, again, I believe our limit is in number of bits, not bytes. So it is even too small for native builds. But I agree, maybe not easy to fix, if the problem is real (I think it is). Bit counts are convenient. I guess maybe this is a good reason to extend Target.Int another byte? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote:Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:53:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:53:55 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: "Obscures the underlying code" is true of so many things. Exceptions. Garbage collection. Objects. Nested functions. Function calls! Default parameters. Generics. Pickles. RPC. It is a matter of degree, cost, value though, granted. The runtime cost of operating overloading is zero, at least. And the unobscured code is horrible to read and write actually (which is the reason for many features). This is case where "obscure" is clearly good, and not obscure. But it is a matter of degree. I should probably try implementing it before I ask for it too strongly. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:33:31 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? Some of us find operator overloading anathema because it obscures the actual underlying code.It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote:Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:08:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking Message-ID: gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:24:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:24:53 +0000 Subject: [M3devel] configure -enable-checking In-Reply-To: References: Message-ID: (ps: we should also be using -O1/-O2/-O3 in some Hudson tasks; or maybe just one -- cm3 accepts -O and then passes down to cm3cg whatever is in the config file..I don't find this model adequate though and I always edit the config; probably better approach is a) environment variable + b) different build_dir; many systems work that way, you don't want too many variants/build_dirs, but 2 isn't unusual ("debug" and "retail" for example)) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Nov 21 20:27:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 21 Nov 2010 11:27:34 -0800 Subject: [M3devel] operator overloading? In-Reply-To: References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: <20101121192734.DB4761A208C@async.async.caltech.edu> I don't like changes in Modula-3, on principle. I have a lot of code that is over ten years old and that I never look at, and I never want to look at, despite the fact that things that I do depend on computers that execute probably billions of instructions in this code every day. Now I depend on such code that depends on being able to parse Modula-3 itself, so the language, I feel should stay both forward- and backward-compatible. (I really don't like LONGINT for that reason.) But that being said, operator overloading seems relatively harmless. It changes the meaning only of executable code, not interfaces, and unless you are writing a compiler, there isn't much reason to be processing the executable code. This is all assuming you do it right. And there must be some way of calling the overloaded operators using functional notation so that generated code can get at them. What has always bugged me about operator overloading in C++ is just what an unabashed hack it is. You can use the operators from C, but no others? And they have to have the same associativity and commutativity rules as in C? And they can be only unary or binary? Does anyone do this better? Is it even possible? I suppose the main thing is to specify a rule for converting a OP b to OP(a,b)... What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And then the associativity rules... is addition left- or right-associative? Who remembers that..? now *that* is obscure. And it won't work on RECORDs or ARRAYs or SETs, which don't have methods... Would it be possible to write a pre-processor using m3tk that would implement the entirety of operator overloading? I think that would be an elegant solution, but I've never used m3tk on implementations... The reason I am saying this is that judging from the syntax equations in the Green Book, it is possible that m3tk might accept a program using overloaded operators, and only semantic analysis on the parsed structure would uncover the overloaded operators and flag them as semantic errors (in standard Modula-3). But I might be wrong. And m3tk might have broken code in it. When we were designing async. hardware with Modula-3 we had a thing called "m3texthack" that would let you do special kinds of macros in Modula-3 code. Your source file would be Module.c3, which would be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 of course). In any case, an m3tk solution rather than a Modula-3 solution would easily allow you to specify different rules for different types, or even for different source files, rather than being tied to something nailed down in the language spec. Mika Jay K writes: >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >"Obscures the underlying code" is true of so many things. >Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >Default parameters. Generics. Pickles. RPC. >It is a matter of degree=2C cost=2C value though=2C granted. > The runtime cost of operating overloading is zero=2C at least. > And the unobscured code is horrible to read and write actually (which is = >the reason for many features). > This is case where "obscure" is clearly good=2C and not obscure. > But it is a matter of degree. I should probably try implementing it befor= >e I ask for it too strongly. > > > - Jay > >From: hosking at cs.purdue.edu >Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] operator overloading? > > > >Some of us find operator overloading anathema because it obscures the actua= >l underlying code.It certainly does not fit well with the design philosophy= > of Modula-3. > >On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > add operator overloading to the language? > >>From a user's point of view=2C I know it is very useful in certain situatio= >ns. > > > - Jay > > > > > > = > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >"Obscures the underlying code" is true of so many things.
Exceptions. Ga= >rbage collection. Objects. Nested functions. Function calls! Default parame= >ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >though=2C granted.
 =3B The runtime cost of operating overloading is= > zero=2C at least.
 =3B And the unobscured code is horrible to read = >and write actually (which is the reason for many features).
 =3B Thi= >s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >ut it is a matter of degree. I should probably try implementing it before I= > ask for it too strongly.


 =3B - Jay

elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >e: [M3devel] operator overloading?

>"> >Some of us find ope= >rator overloading anathema because it obscures the actual underlying code.<= >div>It certainly does not fit well with the design philosophy of Modula-3.<= >br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >
ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >a=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 font-size: med= >ium=3B">
: Tahoma=3B">Is it really so difficult to add operator overloading to the l= >anguage?

From a user's point of view=2C I know it is very useful in = >certain situations.


 =3B- Jay




n>

>= > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From hosking at cs.purdue.edu Sun Nov 21 21:04:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:04:09 -0500 Subject: [M3devel] operator overloading? In-Reply-To: <20101121192734.DB4761A208C@async.async.caltech.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> <20101121192734.DB4761A208C@async.async.caltech.edu> Message-ID: I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > I don't like changes in Modula-3, on principle. I have a lot of code > that is over ten years old and that I never look at, and I never want > to look at, despite the fact that things that I do depend on computers > that execute probably billions of instructions in this code every day. > > Now I depend on such code that depends on being able to parse > Modula-3 itself, so the language, I feel should stay both forward- > and backward-compatible. (I really don't like LONGINT for that > reason.) > > But that being said, operator overloading seems relatively harmless. > It changes the meaning only of executable code, not interfaces, and unless > you are writing a compiler, there isn't much reason to be processing > the executable code. This is all assuming you do it right. And there > must be some way of calling the overloaded operators using functional > notation so that generated code can get at them. > > What has always bugged me about operator overloading in C++ is just > what an unabashed hack it is. You can use the operators from C, > but no others? And they have to have the same associativity and > commutativity rules as in C? And they can be only unary or binary? > Does anyone do this better? Is it even possible? I suppose the main > thing is to specify a rule for converting > > a OP b > > to > > OP(a,b)... > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > then the associativity rules... is addition left- or right-associative? > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > or ARRAYs or SETs, which don't have methods... > > Would it be possible to write a pre-processor using m3tk that would > implement the entirety of operator overloading? I think that would > be an elegant solution, but I've never used m3tk on implementations... > The reason I am saying this is that judging from the syntax equations > in the Green Book, it is possible that m3tk might accept a program using > overloaded operators, and only semantic analysis on the parsed structure > would uncover the overloaded operators and flag them as semantic errors > (in standard Modula-3). But I might be wrong. And m3tk might have > broken code in it. > > When we were designing async. hardware with Modula-3 we had a thing > called "m3texthack" that would let you do special kinds of macros in > Modula-3 code. Your source file would be Module.c3, which would > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > of course). > > In any case, an m3tk solution rather than a Modula-3 solution would easily > allow you to specify different rules for different types, or even for > different source files, rather than being tied to something nailed down > in the language spec. > > Mika > > > > Jay K writes: >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> "Obscures the underlying code" is true of so many things. >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >> Default parameters. Generics. Pickles. RPC. >> It is a matter of degree=2C cost=2C value though=2C granted. >> The runtime cost of operating overloading is zero=2C at least. >> And the unobscured code is horrible to read and write actually (which is = >> the reason for many features). >> This is case where "obscure" is clearly good=2C and not obscure. >> But it is a matter of degree. I should probably try implementing it befor= >> e I ask for it too strongly. >> >> >> - Jay >> >> From: hosking at cs.purdue.edu >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] operator overloading? >> >> >> >> Some of us find operator overloading anathema because it obscures the actua= >> l underlying code.It certainly does not fit well with the design philosophy= >> of Modula-3. >> >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= >> add operator overloading to the language? >> >>> From a user's point of view=2C I know it is very useful in certain situatio= >> ns. >> >> >> - Jay >> >> >> >> >> >> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= >> rbage collection. Objects. Nested functions. Function calls! Default parame= >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >> though=2C granted.
 =3B The runtime cost of operating overloading is= >> zero=2C at least.
 =3B And the unobscured code is horrible to read = >> and write actually (which is the reason for many features).
 =3B Thi= >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >> ut it is a matter of degree. I should probably try implementing it before I= >> ask for it too strongly.


 =3B - Jay

> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >> e: [M3devel] operator overloading?

>> > "> >> Some of us find ope= >> rator overloading anathema because it obscures the actual underlying code.<= >> div>It certainly does not fit well with the design philosophy of Modula-3.<= >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >>
> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >> a=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 font-size: med= >> ium=3B">
> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= >> anguage?

From a user's point of view=2C I know it is very useful in = >> certain situations.


 =3B- Jay




> n>

>> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From rodney_bates at lcwb.coop Sun Nov 21 20:52:08 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 13:52:08 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <4CE97868.3050804@lcwb.coop> I've been around that block too many times with Ada and C++. Programmer- defined overloading (either operator and/or function name) is a semantic disaster. It interacts with stuff all over the language, and the complexity just explodes. I have spent several years of my life having to learn every in and out and dark corner of overloading and all its fallout in Ada, both to implement it and to try to help working programmers cope with it. I can say with complete confidence that Ada would be half the size/complexity it is, without it. Moreover, hard as it is for a compiler writer or language lawyer to understand it, it is even worse for the everyday programmer. Again, I can testify that almost nobody (the above types excepted) comes anywhere close to understanding the rules. They don't even want to try. Their eyes glaze over, and they just want you to tell them how to code such-and-such so it will compile and call the function they want it to. For the future, all they want is restrictive but simple programming guidelines on things to avoid unconditionally, so they won't keep getting burned again and again. C++'s take on overloading is simpler in some respects, more complicated in others, but overall, quite a bit worse and, I dare say, much poorer-understood by working programmers. The upshot is that the (mis)feature of programmer-defined overloading is mostly used only in degenerate and trivial ways. This, of course, raises the question what good is it when: 1) it makes programming more difficult, 2) programmers avoid most of it anyway, and 3) even so, it results in lots of code that programmers just barely hope they understand the meaning of what they wrote. The latter is a *very* big deal in quality of released code. And I didn't even mention the added difficulty in implementing the language. I do realize that function call notation can be a lot harder to read (and write) than operator notation in a few situations. I've also been around that block more times than one, in fact quite recently. I have many times mused over whether it would be possible to add something that would give the most important benefits and not be a complete semantic train wreck. Sometimes I think it could be done a lot better than we have seen, but at best, it would be a significant semantic complication, even if restricted to operators only. In Modula-3, we have a language whose most distinctive characteristic is an exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other language that comes close by this criterion. We need to preserve that. Rodney Bates Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain > situations. > > > - Jay > > > > From jay.krell at cornell.edu Sun Nov 21 21:11:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:11:46 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: > I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 21:14:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:14:08 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: On Nov 21, 2010, at 3:11 PM, Jay K wrote: > > I'm now starting to wish that we had left LONGINT out, > > > Just now? :) > (This is another reason I'm somewhat open to tediously using Target.Int in frontend, > in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > > ARRAY [1..2] OF INTEGER .. same representation as C "long long" > > > These are potentially much different, e.g. when being returned from a function by value. > NT/x86 returns them in the register pair edx:eax. > Granted, it *might* also store small structs that way, but I'm not sure. > (you could bury the array in a struct then as well) > But I guess a small special case would do. > > > Why are sets in the language, with infix operators? > Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. > > > If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. > Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. > > > I have done a *little* bit of Scheme programming, so I at least was at some point > sympathetic to the view of having no infix operators whatsoever. > > > The story of the Dylan programming language is also interesting. > It was originally prefix only but caved and went infix for the sake of > programmer convenience. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 21 Nov 2010 15:04:09 -0500 > > To: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] operator overloading? > > > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > > that is over ten years old and that I never look at, and I never want > > > to look at, despite the fact that things that I do depend on computers > > > that execute probably billions of instructions in this code every day. > > > > > > Now I depend on such code that depends on being able to parse > > > Modula-3 itself, so the language, I feel should stay both forward- > > > and backward-compatible. (I really don't like LONGINT for that > > > reason.) > > > > > > But that being said, operator overloading seems relatively harmless. > > > It changes the meaning only of executable code, not interfaces, and unless > > > you are writing a compiler, there isn't much reason to be processing > > > the executable code. This is all assuming you do it right. And there > > > must be some way of calling the overloaded operators using functional > > > notation so that generated code can get at them. > > > > > > What has always bugged me about operator overloading in C++ is just > > > what an unabashed hack it is. You can use the operators from C, > > > but no others? And they have to have the same associativity and > > > commutativity rules as in C? And they can be only unary or binary? > > > Does anyone do this better? Is it even possible? I suppose the main > > > thing is to specify a rule for converting > > > > > > a OP b > > > > > > to > > > > > > OP(a,b)... > > > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > > then the associativity rules... is addition left- or right-associative? > > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > > or ARRAYs or SETs, which don't have methods... > > > > > > Would it be possible to write a pre-processor using m3tk that would > > > implement the entirety of operator overloading? I think that would > > > be an elegant solution, but I've never used m3tk on implementations... > > > The reason I am saying this is that judging from the syntax equations > > > in the Green Book, it is possible that m3tk might accept a program using > > > overloaded operators, and only semantic analysis on the parsed structure > > > would uncover the overloaded operators and flag them as semantic errors > > > (in standard Modula-3). But I might be wrong. And m3tk might have > > > broken code in it. > > > > > > When we were designing async. hardware with Modula-3 we had a thing > > > called "m3texthack" that would let you do special kinds of macros in > > > Modula-3 code. Your source file would be Module.c3, which would > > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > > of course). > > > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > > allow you to specify different rules for different types, or even for > > > different source files, rather than being tied to something nailed down > > > in the language spec. > > > > > > Mika > > > > > > > > > > > > Jay K writes: > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/plain; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> "Obscures the underlying code" is true of so many things. > > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > > >> Default parameters. Generics. Pickles. RPC. > > >> It is a matter of degree=2C cost=2C value though=2C granted. > > >> The runtime cost of operating overloading is zero=2C at least. > > >> And the unobscured code is horrible to read and write actually (which is = > > >> the reason for many features). > > >> This is case where "obscure" is clearly good=2C and not obscure. > > >> But it is a matter of degree. I should probably try implementing it befor= > > >> e I ask for it too strongly. > > >> > > >> > > >> - Jay > > >> > > >> From: hosking at cs.purdue.edu > > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] operator overloading? > > >> > > >> > > >> > > >> Some of us find operator overloading anathema because it obscures the actua= > > >> l underlying code.It certainly does not fit well with the design philosophy= > > >> of Modula-3. > > >> > > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > > >> add operator overloading to the language? > > >> > > >>> From a user's point of view=2C I know it is very useful in certain situatio= > > >> ns. > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> > > >> > > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/html; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> > > >> > > >> > > >> > > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > > >> and write actually (which is the reason for many features).
 =3B Thi= > > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > > >> ut it is a matter of degree. I should probably try implementing it before I= > > >> ask for it too strongly.


 =3B - Jay

> >> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > > >> e: [M3devel] operator overloading?

> > >> > >> "> > > >> Some of us find ope= > > >> rator overloading anathema because it obscures the actual underlying code.<= > > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > > >>
> >> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > > >> a=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 font-size: med= > > >> ium=3B">
> >> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > > >> anguage?

From a user's point of view=2C I know it is very useful in = > > >> certain situations.


 =3B- Jay




> >> n>

> > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:16:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:16:28 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <4CE97868.3050804@lcwb.coop> References: , <4CE97868.3050804@lcwb.coop> Message-ID: Rodney, what if the signatures of overloaded operators is "fixed". That is + can only take two T's and return one T. < can only take two T's and return one boolean. No implicit conversions. (I do think some conversions are ok, integers to wider integers, but nobody else agrees.) Isn't that much simpler than any other language does it? Are the rules still hard to understand? (And I believe this is still fairly valuable.) Furthermore, something like, maybe, the operators may only be defined in the interface that declares T? Or maybe, the operators are always available on all types, but you get a link error if they weren't defined? And of course, you can't define them for builtin types. They are already defined. And, I realize, there is a question of errors. + can fail. The interface would have to that they raise exceptions. You could have something like FPU.i3 custom per type to control it. The compiler wouldn't know about this (except maybe for builtin LONGINT). - Jay > Date: Sun, 21 Nov 2010 13:52:08 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] operator overloading? > > I've been around that block too many times with Ada and C++. Programmer- > defined overloading (either operator and/or function name) is a semantic > disaster. It interacts with stuff all over the language, and the complexity > just explodes. I have spent several years of my life having to learn every > in and out and dark corner of overloading and all its fallout in Ada, both > to implement it and to try to help working programmers cope with it. I can > say with complete confidence that Ada would be half the size/complexity > it is, without it. > > Moreover, hard as it is for a compiler writer or language lawyer to understand > it, it is even worse for the everyday programmer. Again, I can testify that > almost nobody (the above types excepted) comes anywhere close to understanding > the rules. They don't even want to try. Their eyes glaze over, and they just > want you to tell them how to code such-and-such so it will compile and call > the function they want it to. For the future, all they want is restrictive > but simple programming guidelines on things to avoid unconditionally, so they > won't keep getting burned again and again. > > C++'s take on overloading is simpler in some respects, more complicated in > others, but overall, quite a bit worse and, I dare say, much poorer-understood > by working programmers. > > The upshot is that the (mis)feature of programmer-defined overloading is mostly > used only in degenerate and trivial ways. This, of course, raises the question > what good is it when: 1) it makes programming more difficult, 2) programmers > avoid most of it anyway, and 3) even so, it results in lots of code that > programmers just barely hope they understand the meaning of what they wrote. > The latter is a *very* big deal in quality of released code. And I didn't even > mention the added difficulty in implementing the language. > > I do realize that function call notation can be a lot harder to read (and write) > than operator notation in a few situations. I've also been around that block more > times than one, in fact quite recently. > > I have many times mused over whether it would be possible to add something that > would give the most important benefits and not be a complete semantic train wreck. > Sometimes I think it could be done a lot better than we have seen, but at best, > it would be a significant semantic complication, even if restricted to operators > only. > > In Modula-3, we have a language whose most distinctive characteristic is an > exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other > language that comes close by this criterion. We need to preserve that. > > Rodney Bates > > > Jay K wrote: > > Is it really so difficult to add operator overloading to the language? > > > > From a user's point of view, I know it is very useful in certain > > situations. > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:25:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:25:41 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , , , <20101121192734.DB4761A208C@async.async.caltech.edu>, , , , Message-ID: > What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? I believe m3-libs/arithmetic/src/basictypes/biginteger. Though this arithmetic library is very large and I understand little of it. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 15:14:08 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? On Nov 21, 2010, at 3:11 PM, Jay K wrote:> I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Nov 21 21:56:56 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 14:56:56 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: , <4CE97868.3050804@lcwb.coop> Message-ID: <4CE98798.7060006@lcwb.coop> Jay K wrote: > Rodney, what if the signatures of overloaded operators is "fixed". > That is + can only take two T's and return one T. > < can only take two T's and return one boolean. > That is one of the ways that would greatly simplify the semantics. It would also make it more difficult for programmers to define operator meanings with no resemblance to traditional mathematical meanings of the operators, which I regard as really bad practice, but is encouraged by the overloading systems I know about. > > No implicit conversions. > (I do think some conversions are ok, integers to wider integers, but > nobody else agrees.) We already have something far better than implied conversions. We have assignability, which, simplified, says that in a lot of assignment-like contexts, what is needed is that the RHS _value_ must be a member of the LHS's _type_. The types are not necessarily disjoint, so there are lots of cases where this accomplishes something. Enforcing this requires a mix of static and runtime rules. Obviously, if the RHS type is disjoint with the LHS type, that is statically know to be illegal. When it's legally assignable, Modula-3 doesn't call it a type conversion. This is higher-level and more abstract. There may well be an implied _representation_ conversion, for example, different sizes of integers. Most (all?) other languages require that every different machine-level representation be a different type, and this creates a need for programmer-awareness of lots more type conversions, implicit or explicit, than the Modula-3 approach We didn't get assignability between INTEGER and LONGINT, but we have it between a base ordinal type and all its subranges and all their packed types (subject to value inclusion.) as well as several other cases. > Isn't that much simpler than any other language does it? I think it can be a lot simpler than any other language. There is still a _lot_ of unanticipated detail. > Are the rules still hard to understand? > (And I believe this is still fairly valuable.) > > > Furthermore, something like, maybe, the operators may only be defined in > the interface that declares T? > Or maybe, the operators are always available on all types, but you get a > link error if they weren't defined? > I can think of another visibility rule, but it derives from other things I would have to describe first. > > And of course, you can't define them for builtin types. They are already > defined. > Yes, I would strongly support that rule. (Did you know Ada does not?) > > And, I realize, there is a question of errors. > + can fail. > The interface would have to that they raise exceptions. > You could have something like FPU.i3 custom per type to control it. The > compiler > wouldn't know about this (except maybe for builtin LONGINT). > I think exception raising can be kept orthogonal to operator overloading by defining an operator expression (once resolved to a single function) as equivalent to an ordinary call. In fact, everything except determining what function is to be called can be defined by an equivalence to an ordinary call of that function. > > - Jay > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] operator overloading? > > > > I've been around that block too many times with Ada and C++. Programmer- > > defined overloading (either operator and/or function name) is a semantic > > disaster. It interacts with stuff all over the language, and the > complexity > > just explodes. I have spent several years of my life having to learn > every > > in and out and dark corner of overloading and all its fallout in Ada, > both > > to implement it and to try to help working programmers cope with it. > I can > > say with complete confidence that Ada would be half the size/complexity > > it is, without it. > > > > Moreover, hard as it is for a compiler writer or language lawyer to > understand > > it, it is even worse for the everyday programmer. Again, I can > testify that > > almost nobody (the above types excepted) comes anywhere close to > understanding > > the rules. They don't even want to try. Their eyes glaze over, and > they just > > want you to tell them how to code such-and-such so it will compile > and call > > the function they want it to. For the future, all they want is > restrictive > > but simple programming guidelines on things to avoid unconditionally, > so they > > won't keep getting burned again and again. > > > > C++'s take on overloading is simpler in some respects, more > complicated in > > others, but overall, quite a bit worse and, I dare say, much > poorer-understood > > by working programmers. > > > > The upshot is that the (mis)feature of programmer-defined overloading > is mostly > > used only in degenerate and trivial ways. This, of course, raises the > question > > what good is it when: 1) it makes programming more difficult, 2) > programmers > > avoid most of it anyway, and 3) even so, it results in lots of code that > > programmers just barely hope they understand the meaning of what they > wrote. > > The latter is a *very* big deal in quality of released code. And I > didn't even > > mention the added difficulty in implementing the language. > > > > I do realize that function call notation can be a lot harder to read > (and write) > > than operator notation in a few situations. I've also been around > that block more > > times than one, in fact quite recently. > > > > I have many times mused over whether it would be possible to add > something that > > would give the most important benefits and not be a complete semantic > train wreck. > > Sometimes I think it could be done a lot better than we have seen, > but at best, > > it would be a significant semantic complication, even if restricted > to operators > > only. > > > > In Modula-3, we have a language whose most distinctive characteristic > is an > > exceptionally high ratio of useful stuff to complexity. AFAIK, there > is no other > > language that comes close by this criterion. We need to preserve that. > > > > Rodney Bates > > > > > > Jay K wrote: > > > Is it really so difficult to add operator overloading to the language? > > > > > > From a user's point of view, I know it is very useful in certain > > > situations. > > > > > > > > > - Jay > > > > > > > > > > > > From dabenavidesd at yahoo.es Mon Nov 22 04:04:23 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 22 Nov 2010 03:04:23 +0000 (GMT) Subject: [M3devel] operator overloading? In-Reply-To: <4CE98798.7060006@lcwb.coop> Message-ID: <16723.97158.qm@web29716.mail.ird.yahoo.com> Hi all: perhaps in behalf of this issue, one remembers the rules for the type inference algorithms are of variable complexity depending on the semantics or what one calls meaning but also syntaic aids, not like syntatic sugared language constructs but syntax directed checking, and if you want to look an example please look at javascript type inference vs Obliq Modula-3 runtime type inference (which uses m3tk lib by the way), it tourns out that the semantics (object oriented dynamically typed based languages) are quite different in terms of type checking, i.e given Obliq algorithm may checks up to in O[n^5] order but could be less according to certain conditions but in terms of the javascript kernel considered in an research work is not that quick by now, but remains in general as an open issue, perhaps waiting for someone who gets a Turing Award for it ( see http://jiangxi.cs.uwm.edu/publication/js.pdf ) Please consider no just simplicity of our thoughts but of our algorithms, specially when someone has code that already dependends on parsing Modula-3 statements all the day long by many millions of instruction per second. Thanks in advance --- El dom, 21/11/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] operator overloading? > Para: "m3devel" > Fecha: domingo, 21 de noviembre, 2010 15:56 > > > Jay K wrote: > > Rodney, what if the signatures of overloaded operators > is "fixed". > > That is + can only take two T's and return one T. > > < can only take two T's and return one boolean. > > > > That is one of the ways that would greatly simplify the > semantics. > It would also make it more difficult for programmers to > define > operator meanings with no resemblance to traditional > mathematical > meanings of the operators, which I regard as really bad > practice, > but is encouraged by the overloading systems I know about. > > > > > No implicit conversions. > > (I do think some conversions are ok, > integers to wider integers, but nobody else agrees.) > > We already have something far better than implied > conversions. We have > assignability, which, simplified, says that in a lot of > assignment-like > contexts, what is needed is that the RHS _value_ must be a > member of the > LHS's _type_. The types are not necessarily disjoint, > so there are lots > of cases where this accomplishes something. Enforcing > this requires a > mix of static and runtime rules. Obviously, if the > RHS type is disjoint > with the LHS type, that is statically know to be illegal. > > When it's legally assignable, Modula-3 doesn't call it a > type conversion. > This is higher-level and more abstract. There may > well be an implied > _representation_ conversion, for example, different sizes > of integers. > Most (all?) other languages require that every different > machine-level > representation be a different type, and this creates a need > for > programmer-awareness of lots more type conversions, > implicit or explicit, > than the Modula-3 approach > > We didn't get assignability between INTEGER and LONGINT, > but we have > it between a base ordinal type and all its subranges and > all their > packed types (subject to value inclusion.) as well as > several other > cases. > > > Isn't that much simpler than any other language does > it? > > I think it can be a lot simpler than any other > language. There is > still a _lot_ of unanticipated detail. > > > Are the rules still hard to understand? > > (And I believe this is still fairly > valuable.) > > > > > > Furthermore, something like, maybe, the operators may > only be defined in the interface that declares T? > > Or maybe, the operators are always available on all > types, but you get a link error if they weren't defined? > > > > I can think of another visibility rule, but it derives from > other things > I would have to describe first. > > > > > And of course, you can't define them for builtin > types. They are already defined. > > > > Yes, I would strongly support that rule. (Did you > know Ada does not?) > > > > > And, I realize, there is a question of errors. > > + can fail. > > The interface would have to that they raise > exceptions. > > You could have something like FPU.i3 custom per type > to control it. The compiler > > wouldn't know about this (except maybe for builtin > LONGINT). > > > > I think exception raising can be kept orthogonal to > operator overloading by > defining an operator expression (once resolved to a single > function) as > equivalent to an ordinary call. In fact, everything > except determining > what function is to be called can be defined by an > equivalence to an > ordinary call of that function. > > > > > - Jay > > > > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] operator > overloading? > > > > > > I've been around that block too many times > with Ada and C++. Programmer- > > > defined overloading (either operator and/or > function name) is a semantic > > > disaster. It interacts with stuff all over > the language, and the complexity > > > just explodes. I have spent several years > of my life having to learn every > > > in and out and dark corner of overloading > and all its fallout in Ada, both > > > to implement it and to try to help working > programmers cope with it. I can > > > say with complete confidence that Ada would > be half the size/complexity > > > it is, without it. > > > > > > Moreover, hard as it is for a compiler > writer or language lawyer to understand > > > it, it is even worse for the everyday > programmer. Again, I can testify that > > > almost nobody (the above types excepted) > comes anywhere close to understanding > > > the rules. They don't even want to try. > Their eyes glaze over, and they just > > > want you to tell them how to code > such-and-such so it will compile and call > > > the function they want it to. For the > future, all they want is restrictive > > > but simple programming guidelines on things > to avoid unconditionally, so they > > > won't keep getting burned again and again. > > > > > > C++'s take on overloading is simpler in > some respects, more complicated in > > > others, but overall, quite a bit worse and, > I dare say, much poorer-understood > > > by working programmers. > > > > > > The upshot is that the (mis)feature of > programmer-defined overloading is mostly > > > used only in degenerate and trivial ways. > This, of course, raises the question > > > what good is it when: 1) it makes > programming more difficult, 2) programmers > > > avoid most of it anyway, and 3) even so, it > results in lots of code that > > > programmers just barely hope they > understand the meaning of what they wrote. > > > The latter is a *very* big deal in quality > of released code. And I didn't even > > > mention the added difficulty in > implementing the language. > > > > > > I do realize that function call notation > can be a lot harder to read (and write) > > > than operator notation in a few situations. > I've also been around that block more > > > times than one, in fact quite recently. > > > > > > I have many times mused over whether it > would be possible to add something that > > > would give the most important benefits and > not be a complete semantic train wreck. > > > Sometimes I think it could be done a lot > better than we have seen, but at best, > > > it would be a significant semantic > complication, even if restricted to operators > > > only. > > > > > > In Modula-3, we have a language whose most > distinctive characteristic is an > > > exceptionally high ratio of useful stuff to > complexity. AFAIK, there is no other > > > language that comes close by this > criterion. We need to preserve that. > > > > > > Rodney Bates > > > > > > > > > Jay K wrote: > > > > Is it really so difficult to add > operator overloading to the language? > > > > > > > > From a user's point of view, I know it > is very useful in certain > > > > situations. > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > From wagner at elegosoft.com Mon Nov 22 07:56:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Nov 2010 07:56:31 +0100 Subject: [M3devel] latest regressions Message-ID: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> out of memory on FreeBSD4: cc1plus: out of memory allocating 235058936 bytes gmake: *** [insn-recog.o] Error 1 "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console m3cc compilation failure on PPC_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console 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 Nov 22 08:20:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: [M3devel] latest regressions In-Reply-To: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> Message-ID: Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 08:28:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:28:16 +0000 Subject: [M3devel] latest regressions In-Reply-To: References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com>, Message-ID: I'll see if PPC_DARWIN error can be reproduced building a cross compiler. It should be. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: Re: [M3devel] latest regressions Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 21:25:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 20:25:54 +0000 Subject: [M3devel] I386_DARWIN Message-ID: I386_DARWIN is still broken http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/84/console but probably just needs to restart with a known good cm3cg, I'll get to that later. (I'm hoping that the update of cm3/cm3cg in the "middle" of upgrade.sh doesn't go into last-ok/current until the end of the task, in case of a mistake.) - Jay From jay.krell at cornell.edu Tue Nov 23 01:23:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 00:23:03 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. I think. Right? So here it could do that just as well. Right? - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:43:03 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > declare_segment doesn't have the size because it is unknown at the time > of the declaration, which comes before the module is compiled. > Only as the module is compiled does the size become known, with > Bind_segment emitted at the end. > > > On Nov 19, 2010, at 5:01 AM, Jay K wrote: > > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > > From hosking at cs.purdue.edu Tue Nov 23 02:17:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 20:17:54 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > I think. Right? > So here it could do that just as well. Right? > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 19 Nov 2010 09:43:03 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> declare_segment doesn't have the size because it is unknown at the time >> of the declaration, which comes before the module is compiled. >> Only as the module is compiled does the size become known, with >> Bind_segment emitted at the end. >> >> >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >> >> I'm not looking at m3front. I should. >> >> Why does declare_segment not have the size? >> >> I'm going to just live with whatever the frontend does for now. >> Make an extra pass to find the bind_segments, so that when >> I do things "for real", declare_segment can set the size correctly. >> >> Later I'll do better -- making the segment contain fields. >> So that globals become debuggable, in stock gdb (as big records). >> >> But first I want configure enable-checking to work. >> (with one exception, the static link stuff..) >> >> - Jay >> >> >> >> >> From jay.krell at cornell.edu Tue Nov 23 02:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 01:51:11 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. And, it could be "fixed" by adding an additional pass? And, you didn't say this, we very well could/should, if all the backends needed it? Or if it was cheap enough? You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. Or at least in the backend that could easily benefit from it. But actually there's probably another way. I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 20:17:54 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > > Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > > > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > > I think. Right? > > So here it could do that just as well. Right? > > > > - Jay > > > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> declare_segment doesn't have the size because it is unknown at the time > >> of the declaration, which comes before the module is compiled. > >> Only as the module is compiled does the size become known, with > >> Bind_segment emitted at the end. > >> > >> > >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >> > >> I'm not looking at m3front. I should. > >> > >> Why does declare_segment not have the size? > >> > >> I'm going to just live with whatever the frontend does for now. > >> Make an extra pass to find the bind_segments, so that when > >> I do things "for real", declare_segment can set the size correctly. > >> > >> Later I'll do better -- making the segment contain fields. > >> So that globals become debuggable, in stock gdb (as big records). > >> > >> But first I want configure enable-checking to work. > >> (with one exception, the static link stuff..) > >> > >> - Jay > >> > >> > >> > >> > >> > From hosking at cs.purdue.edu Tue Nov 23 03:59:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 21:59:29 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > And, it could be "fixed" by adding an additional pass? No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > And, you didn't say this, we very well could/should, if all the backends needed it? > Or if it was cheap enough? > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > Or at least in the backend that could easily benefit from it. > But actually there's probably another way. > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). Yes, I think that would be better. > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 20:17:54 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >> >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >> >>> >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>> I think. Right? >>> So here it could do that just as well. Right? >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> declare_segment doesn't have the size because it is unknown at the time >>>> of the declaration, which comes before the module is compiled. >>>> Only as the module is compiled does the size become known, with >>>> Bind_segment emitted at the end. >>>> >>>> >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>> >>>> I'm not looking at m3front. I should. >>>> >>>> Why does declare_segment not have the size? >>>> >>>> I'm going to just live with whatever the frontend does for now. >>>> Make an extra pass to find the bind_segments, so that when >>>> I do things "for real", declare_segment can set the size correctly. >>>> >>>> Later I'll do better -- making the segment contain fields. >>>> So that globals become debuggable, in stock gdb (as big records). >>>> >>>> But first I want configure enable-checking to work. >>>> (with one exception, the static link stuff..) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >> From jay.krell at cornell.edu Tue Nov 23 04:59:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 03:59:23 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: > It's inevitable that we have types referenced before defined because of recursion in the type definitions. "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. Er, but you said reference before defined, not referenced before forward declared. Is it inevitable, say, to have a pointer to a record before declaring that the record exists? Seems unlikely. Is there really recursion, or just..some graph? Again something the frontend maybe could resolve but doesn't? Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) A point here is, really, I'm still trying to get the better-typed trees. Even though I went out on a tangent getting configure -enable-checking to work. -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. - Jay ---------------------------------------- > Subject: Re: [M3devel] bind_segment vs. declare_segment? > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 21:59:29 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > > > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > > And, it could be "fixed" by adding an additional pass? > > No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > > > And, you didn't say this, we very well could/should, if all the backends needed it? > > Or if it was cheap enough? > > > > > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > > Or at least in the backend that could easily benefit from it. > > But actually there's probably another way. > > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). > > Yes, I think that would be better. > > > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 22 Nov 2010 20:17:54 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > >> > >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > >> > >>> > >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > >>> I think. Right? > >>> So here it could do that just as well. Right? > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >>>> > >>>> declare_segment doesn't have the size because it is unknown at the time > >>>> of the declaration, which comes before the module is compiled. > >>>> Only as the module is compiled does the size become known, with > >>>> Bind_segment emitted at the end. > >>>> > >>>> > >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >>>> > >>>> I'm not looking at m3front. I should. > >>>> > >>>> Why does declare_segment not have the size? > >>>> > >>>> I'm going to just live with whatever the frontend does for now. > >>>> Make an extra pass to find the bind_segments, so that when > >>>> I do things "for real", declare_segment can set the size correctly. > >>>> > >>>> Later I'll do better -- making the segment contain fields. > >>>> So that globals become debuggable, in stock gdb (as big records). > >>>> > >>>> But first I want configure enable-checking to work. > >>>> (with one exception, the static link stuff..) > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> > >>>> > >> > From jay.krell at cornell.edu Tue Nov 23 08:26:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:26:30 +0000 Subject: [M3devel] configure -enable-checking Message-ID: The ridiculous cross product tests I put in p240 actually do cover stuff not covered anywhere else in the tree, seemingly. ../AMD64_DARWIN/Divide.m3: In function 'Divide__Divide_var_C_C': ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5567 = D.5565 /[ex] D.5566; ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5573 = D.5571 /[ex] D.5572; ../AMD64_DARWIN/Divide.m3:634:0: internal compiler error: verify_stmts failed jbook2:p240 jay$ wc -l AMD64_DARWIN/*.m3 46913 total :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 08:57:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:57:56 +0000 Subject: [M3devel] cardinal vs. word, divide? Message-ID: So, here are two maybe interesting cases. At least to jog my brain and help make sense of the system. DIV vs. Word.Divide of CARDINAL. u is for unsigned, or word C is for Cardinal. Cardinal is [0..LAST(INTEGER)]. <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 (5582) div type:int_64 (5583) check_lo type:int_64 0 code:1 (5584) exit_proc type:word_64 (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 (5574) div type:word_64 (5575) exit_proc type:int_64 (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C Thoughts? Is it right for the load to convert from word to int? (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) I can see how makes sense. CARDINAL is just a subrange of INTEGER. So it is INTEGER. If/when we are clever, we can represent the subranges in the types in the backend, and the optimizer should notice, and these would generate identical code, if they don't already. But the return types of the divides vary as well. There do exist unsigned types at this level. Does that imply that a,b:CARDINAL Word.Or(a, 0) DIV Word.Or(b, 0) is different than a DIV b? I guess so. Different code at least. Given that cardinal is "half range", the results should always match. That is, really, other than added/missing range checks, CARDINAL will always act the same as INTEGER. So then the unsigned types..don't mean anything? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 09:33:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 08:33:00 +0000 Subject: [M3devel] bit field operations for insert/extract Message-ID: Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 11:44:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 10:44:01 +0000 Subject: [M3devel] optimizer vs. gc? Message-ID: so.."the literate" (actually posts to usenet by people who worked on Modula-3 compilers!) warns about the following sort of thing: void F1(char* a, char* b) { int c; for (c = 10; c < 20; ++c) { a[c] = b[c]; } } getting transformed into something like: void F1(char* a, char* b) { int c; a += 10; b += 10; for (c = 0; c < 10; ++c) { a[c] = a[c]; } } actually it warns about something trickier, but this is the best I can come up with that I understand, off the top of my head. => "interior pointers" => "no gc roots in registers or on stack" Should we be concerned? Does our GC handle this? Should we, like, mark all stores volatile but not all loads? And maybe all parameters??? And maybe copy them into non-volatile locals? The trickier warning is something where the difference of the array bases is what is in registers, not merely an interior pointer. I searched a while but couldn't find it. It is probably by David Chase. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:28:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:28:12 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <8570A188-D9CF-4AF3-AAF1-B6A1459F6495@cs.purdue.edu> I'd have to think a bit more about this. I'm still not sure what the issue is for you in the back end. On Nov 22, 2010, at 10:59 PM, Jay K wrote: > >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From hosking at cs.purdue.edu Tue Nov 23 15:35:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:35:05 -0500 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <72D18BD8-B615-4269-98F2-82CC25A05ECA@cs.purdue.edu> Word.Or(a, 0) always has type Word.T, which is currently defined to be INTEGER. Word.Divide takes two Word.T, treats them as unsigned, and performs unsigned division on them, returning the bits as Word.T. DIV takes two INTEGERs and performs signed division on them. What was the question again? On Nov 23, 2010, at 2:57 AM, Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:37:00 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: Message-ID: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote: > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:46:41 -0500 Subject: [M3devel] optimizer vs. gc? In-Reply-To: References: Message-ID: I assume you are referring to: @article{boeh92, author = "Hans-Juergen Boehm and David R. Chase", title = "A Proposal for Garbage-Collector-Safe {C} Compilation", journal = "Journal of C Language Translation", mon = dec, year = 1992, pages = "126--141", URL = {http://reality.sgi.com/employees/boehm_mti/papers/boecha.ps.gz} } So long as the stacks have a pointer to anywhere on the heap page on which the object lies then it will not get reclaimed by our collector. I'd be surprised if gcc performs optimizations that break our collector. On Nov 23, 2010, at 5:44 AM, Jay K wrote: > so.."the literate" (actually posts to usenet > by people who worked on Modula-3 compilers!) > warns about the following sort of thing: > > void F1(char* a, char* b) > { > int c; > for (c = 10; c < 20; ++c) > { > a[c] = b[c]; > } > } > > getting transformed into something like: > > void F1(char* a, char* b) > { > int c; > a += 10; > b += 10; > for (c = 0; c < 10; ++c) > { > a[c] = a[c]; > } > } > > > actually it warns about something trickier, but this > is the best I can come up with that I understand, > off the top of my head. > > > => "interior pointers" > => "no gc roots in registers or on stack" > > > Should we be concerned? > Does our GC handle this? > > > Should we, like, mark all stores volatile but not all loads? > And maybe all parameters??? > And maybe copy them into non-volatile locals? > > The trickier warning is something where > the difference of the array bases is what is in registers, not merely an interior pointer. > I searched a while but couldn't find it. > It is probably by David Chase. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Nov 23 17:52:37 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 10:52:37 -0600 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <4CEBF155.3050703@lcwb.coop> Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE > uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN > Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE > Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV > b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C > Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C > Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only > conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. Same result value, for all a,b. The code should only differ if the compiler does not optimize away the noop Word.Or operations. At the language semantics level, applying a builtin operator like DIV or Word.Or to a subrange (CARDINAL) is like passing the subrange value to a procedure that takes an INTEGER formal parameter of VALUE mode. The actual must be 'assignable' to the formal, which is the case in all these examples, without runtime checks. There could be a representation change generated by the compiler (this is _not_ an implied type conversion), though that doesn't happen here, since surely CARDINAL will always be represented the same as INTEGER. If a were, say, [-128..127] or smaller, the compiler might well have represented/stored it in a (signed) byte, and would then have to do a representation conversion by expanding and sign-extending into a full word before applying the operator to it. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > I'd say yes, except when attached to the div operator. Most languages have different types for signed and unsigned. Then the same operator, applied to the different types does different things. These are (language-defined) overloaded operators. In the case of signed vs. unsigned, Modula-3 turns it around. There is only one type INTEGER=Word.T. Instead, there are different operators for the signed/unsigned operations: DIV vs. Word.Divide. They just apply different interpretations to the same bits. From these examples and some brief looks at M3x83.m3, it looks like the M3 backend system is designed to reflect the more common source language system of different types, with the front end having propagated a copy of the operand type to the operator too. I don't know how the gcc tree system works, but I'd bet it too uses different types. The way that I would match the Modula-3 semantics to the gcc system would be to keep everything in a signed type, except when an unsigned operator comes along. Then convert to unsigned, apply the unsigned operator, and convert back to signed. The conversions used would have to be LOOPHOLE-like in just reinterpreting the bits without changing them. No sign-check going to unsigned and no sign-extension coming back. So the only reason to need conversions at all is if gcc matches types of operands to types of operators and chokes on mismatch. I can see why the div operator needs separate types word_64 or int_64 attached to distinguish which operation is to be done. I can't see why the operand types need such a distinction at all, why the type is changed in the load, or why the source and destination types are what they are. The distinction might not actually mean much on the operands. > > - Jay > > > > From rodney_bates at lcwb.coop Tue Nov 23 18:21:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 11:21:04 -0600 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <4CEBF800.7050401@lcwb.coop> Jay K wrote: > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > It is inevitable that many programs will need to have types that refer to each other in recursive fashion. Just a simple linked list node needs a link pointer. The pointer's definition refers to the node's and vice-versa. with more than one node type, and links among them, it gets more complicated. Something has to come first, and it has to have a forward reference to something that comes later. There are various systems in various languages to support this. Most languages allow some way of splitting a type definition into two parts. One gives only partial information about the type, not enough to need the reference to the other type in the cycle. This could be the "declaring that the record exists" you mention. The other type can be declared next, referring to the incomplete type in some limited ways. Then the completion of the first type comes last. For example, it is usually possible to define a pointer to an incompletely-defined type. And this works OK for a compiler, which really only needs to know its size at this point, and all pointers are the same size. So we only need to know the referent is a type, but not what type, to define a pointer to it. Modula-3 is unusual in saying that all declarations in a single scope are made simultaneously. This is rather abstract talk for saying one declaration can make a forward reference to another declaration in the same scope. (Note that this changes the way redeclaring an identifier in an inner scope works.) Then there are separate rules limiting what kinds of recursion are legal in declarations. For example, records R1 and R2 can contain pointers to each other, but not imbedded instances of each other. (That would have infinite size.) A compiler can handle this in two passes, one to collect all the identifiers declared in the scope (and probably as much information about them as does not depend on any other referred-to declaration.) The second can then check the recursion rules and complete all attributes of the declared entities. > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> From jay.krell at cornell.edu Tue Nov 23 19:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 18:46:06 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. The change would be to remove those. - Jay Subject: Re: [M3devel] bit field operations for insert/extract From: hosking at cs.purdue.edu Date: Tue, 23 Nov 2010 09:37:00 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote:Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 20:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 19:51:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <4CEBF800.7050401@lcwb.coop> References: , , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , , , , , , <4CEBF800.7050401@lcwb.coop> Message-ID: > > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. As long as it is a pointer, I think that is easy and I understand. But granted, I think it is messed up in m3 today. I think m3front always says: record with n fields immediately followed by n fields And there is no forward declaration mechanism. We could probably use forward declare record That just gives the typeid. I have to look in more detail. I'm just speaking from memory here, and not all of the details have ever been, let alone remain, in my memory. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 22:34:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 16:34:25 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: Are they wrong? Seems strange that they worked previously! On Nov 23, 2010, at 1:46 PM, Jay K wrote: > None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 22:46:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 21:46:02 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: Let me clarify. Remember when you used bit field operations for extract_mn? And they didn't work on any big endian system? And I had to undo it? With your approval. I believe the way to go: the change you did in parse.c; it was correct, highly likely removing those endian checks in m3front, which you didn't do at the time Removing the endian checks will only affect big endian. The code reads something like: if little_endian extract_mn(offset, count) else extract_mn(size - offset, size - count) So just change it to: extract_mn(offset, count) And I strongly suspect it will affect it "in the right way". But I'm going to try diffing assembly before/after to be sure. And then watch the sparc and ppc hudson builds. :) (and fix PPC_DARWIN beforehand as well) This is perhaps an interface change in m3cg, but there are no other big endian backends and there are no other uses of extract_mn in the frontend, I think. i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. Anyway, still speculation at this point. But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; perhaps it is best to just leave everything asis...?) and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) - Jay ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 16:34:25 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Are they wrong? Seems strange that they worked previously! > > On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > None yet. But notice the endian checks around the insert_mn or > extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the > endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, > again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems > suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full > value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > > From hosking at cs.purdue.edu Tue Nov 23 23:46:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 17:46:06 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: If that's the case then I would argue for adjusting the offset accordingly in parse.c. extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > Let me clarify. > Remember when you used bit field operations for extract_mn? > And they didn't work on any big endian system? > And I had to undo it? With your approval. > > > I believe the way to go: > the change you did in parse.c; it was correct, highly likely > removing those endian checks in m3front, which you didn't do at the time > > > Removing the endian checks will only affect big endian. > The code reads something like: > if little_endian extract_mn(offset, count) > else extract_mn(size - offset, size - count) > > > So just change it to: > extract_mn(offset, count) > > > And I strongly suspect it will affect it "in the right way". > But I'm going to try diffing assembly before/after to be sure. > And then watch the sparc and ppc hudson builds. :) > (and fix PPC_DARWIN beforehand as well) > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > and there are no other uses of extract_mn in the frontend, I think. > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > Anyway, still speculation at this point. > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > perhaps it is best to just leave everything asis...?) > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > - Jay > > > ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 16:34:25 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Are they wrong? Seems strange that they worked previously! >> >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: >> >> None yet. But notice the endian checks around the insert_mn or >> extract_mn uses in cg.m3. >> The change would be to remove those. >> >> - Jay >> >> >> ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 09:37:00 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Refresh my memory. What m3front change did you make? >> >> >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: >> >> Tony, I'm going to try again to use bitfield operations for extract_mn. >> And insert_mn. >> I think I know what went wrong before for extract_mn: just remove the >> endian check in m3front. >> But I'm going to be sure test p240 covers it well. >> >> The easy part, duh, your original extract_mn was correct I think, just, >> again, missing the m3front change. >> >> Insert_mn is less obvious. >> I started writing it... bitfield_ref..modify_expr...uh, seems >> suspicious, to be modifying an existing value. >> >> I guess it's more like, that, but with a temp that starts with the full >> value of x: >> create temp >> modify(temp, x) >> modify(bitfield_ref(temp, count, offset), y); >> m3_load(temp) >> >> ? >> >> I'll try something like that. >> It seems unfortunate. >> Maybe we can know if x is already a value and not a variable? >> >> >> - Jay >> >> >> From jay.krell at cornell.edu Tue Nov 23 23:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 22:53:25 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , Message-ID: Fair enough, easy enough. I'd want to double check that the existing use is wanting that interpretation. Obviously for that matter, we can leave the code asis for big endian. And just take your code as it was, but under if (target_is_little_endian). Big endian is the minority anyway. :) (no, I won't do that) It would be cool if the frontend never checked target endianness. It does it very little as it is. But ok either way. (I want to move the Target.m3 stuff to the config files -- endianness, setjmp name, jmpbuf size/align, etc., though that's about all that is left) - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 17:46:06 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bit field operations for insert/extract > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > Let me clarify. > > Remember when you used bit field operations for extract_mn? > > And they didn't work on any big endian system? > > And I had to undo it? With your approval. > > > > > > I believe the way to go: > > the change you did in parse.c; it was correct, highly likely > > removing those endian checks in m3front, which you didn't do at the time > > > > > > Removing the endian checks will only affect big endian. > > The code reads something like: > > if little_endian extract_mn(offset, count) > > else extract_mn(size - offset, size - count) > > > > > > So just change it to: > > extract_mn(offset, count) > > > > > > And I strongly suspect it will affect it "in the right way". > > But I'm going to try diffing assembly before/after to be sure. > > And then watch the sparc and ppc hudson builds. :) > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > and there are no other uses of extract_mn in the frontend, I think. > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > Anyway, still speculation at this point. > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > perhaps it is best to just leave everything asis...?) > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > - Jay > > > > > > ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Are they wrong? Seems strange that they worked previously! > >> > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > >> > >> None yet. But notice the endian checks around the insert_mn or > >> extract_mn uses in cg.m3. > >> The change would be to remove those. > >> > >> - Jay > >> > >> > >> ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Refresh my memory. What m3front change did you make? > >> > >> > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > >> > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > >> And insert_mn. > >> I think I know what went wrong before for extract_mn: just remove the > >> endian check in m3front. > >> But I'm going to be sure test p240 covers it well. > >> > >> The easy part, duh, your original extract_mn was correct I think, just, > >> again, missing the m3front change. > >> > >> Insert_mn is less obvious. > >> I started writing it... bitfield_ref..modify_expr...uh, seems > >> suspicious, to be modifying an existing value. > >> > >> I guess it's more like, that, but with a temp that starts with the full > >> value of x: > >> create temp > >> modify(temp, x) > >> modify(bitfield_ref(temp, count, offset), y); > >> m3_load(temp) > >> > >> ? > >> > >> I'll try something like that. > >> It seems unfortunate. > >> Maybe we can know if x is already a value and not a variable? > >> > >> > >> - Jay > >> > >> > >> > From jay.krell at cornell.edu Thu Nov 25 11:52:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 10:52:56 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: <4CB2D03D.8080608@wickensonline.co.uk> References: , <1286270642.3514.3.camel@boromir.m3w.org>, , <4CB1F4CD.4020101@wickensonline.co.uk>, , <4CB2C557.70704@wickensonline.co.uk> , <4CB2D03D.8080608@wickensonline.co.uk> Message-ID: [again, sorry] Another chance on some items, people here will get big discounts. working SGI Fuel good fast SGI workstation runs Irix and should run OpenBSD http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651922577 AlphaServer 800 5/400, doesn't seem to work http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651918789 HPPA machine that can run Linux and HP-UX; works; loud; no video out, need to use serial console (over which I was able to install both Linux and HP-UX) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651902023 Anyone here can negotiate me way way way down, esp. if you provide me ssh access. AlphaServer would go for just half shipping for example. The rest probably $50-$100 + shipping. Or just half shipping if you give me occasional ssh access. I'm pretty sure the HP machine is worth over $100 and the SGI over $200. More coming, probably next week. Happy Thanksgiving, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 25 12:08:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 11:08:25 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: References: , , <1286270642.3514.3.camel@boromir.m3w.org>, , , , <4CB1F4CD.4020101@wickensonline.co.uk>, , , , , <4CB2C557.70704@wickensonline.co.uk>, , , <4CB2D03D.8080608@wickensonline.co.uk>, Message-ID: another, including the Linux/sparc Hudson node: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651928303 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 27 01:14:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:14:24 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>, , , , , , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, Message-ID: I don't know what the strong/weak casts are, but here is the problem seemingly: gcc-4.5 fold-const.c fold_binary_loc(code = FLOOR_DIV_EXPR, ??????????????? op0, op1, type all int_64 arg0, arg1 become word_64 (not op0, op1, but arg0, arg1) and then we end up here: ????? if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) ??? ? && multiple_of_p (type, arg0, arg1)) ??? return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); and then, configure -enable-checking=fold,...: error: type mismatch in binary expression int_64 word_64 word_64 D.1003 = D.1001 /[ex] D.1002; I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 22:50:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Aha. I had no idea and should investigate further. > Notice though that I've been applying the same sorts of casts > everywhere and they generally help. But perhaps they are > weak, and weak is usually strong enough, or some such. > Almost anything is possible. :) > > > - Jay > > > > ---------------------------------------- > > Subject: Re: [M3commit] CVS Update: cm3 > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > CC: m3commit at elegosoft.com > > To: jay.krell at cornell.edu > > > > There are weak and strong casts in gcc. > > I forget the precise details, but I believe they will make a difference. > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > Presumably fold is removing the cast somewhere. > > > Maybe a gcc bug??? > > > I can dig deeper if you really want. > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > but different in signedness, I want to try *not* taking the address. > > > Probably also for pointer<=>integer of pointer size. > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> That should be handled by placing an appropriate cast in the gcc tree. > > >> > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > >> > > >> Try building m3-sys/m3tests/p2/p240. > > >> There is an error in the configure enable-checking about the types > > >> being mismatched. > > >> > > >> - Jay > > >> > > >> > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> Go with the obvious less heavy handed fix of only avoiding > > >>>> fold for integer division. > > >>> > > >>> I don't understand what the issue is with folding on integer > > >> division. Please explain. > > >>> > > >>>> This is enough for test p240 and the unoptimized code is definitely > > >> better. > > >>>> NOT fully tested, but really probably works. > > >>>> It is probably worth digging into the frontend to see if there is a > > >> difference > > >>>> in the types. It is probably also worth digging in the backend, like, > > >>>> we do put in the casts consistently, why are they only not effective > > >>>> for divide? I realize that a little bit of analysis goes a long way > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > >>>> On the other hand, it isn't worth too much effort. > > >>>> Divide is the slowest least used integer operation. > > >>> > > >> > > From jay.krell at cornell.edu Sat Nov 27 01:38:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:38:40 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>,,, , , ,,, , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, , , Message-ID: The reason it gets there is that multiple_of_p is true, because I'm dividing something by itself, in the test case. The answer would be 1, unless the value is 0. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Nov 2010 00:14:24 +0000 > CC: m3devel at elegosoft.com > Subject: [M3devel] fold_build(divide) vs. build(divide) > > > I don't know what the strong/weak casts are, but here is the problem seemingly: > > gcc-4.5 > fold-const.c > > fold_binary_loc(code = FLOOR_DIV_EXPR, > op0, op1, type all int_64 > > arg0, arg1 become word_64 > (not op0, op1, but arg0, arg1) > > and then we end up here: > > if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) > && multiple_of_p (type, arg0, arg1)) > return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); > > and then, configure -enable-checking=fold,...: > > error: type mismatch in binary expression > int_64 > > word_64 > > word_64 > > D.1003 = D.1001 /[ex] D.1002; > > I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . > > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 22:50:02 +0000 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Aha. I had no idea and should investigate further. > > Notice though that I've been applying the same sorts of casts > > everywhere and they generally help. But perhaps they are > > weak, and weak is usually strong enough, or some such. > > Almost anything is possible. :) > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > Subject: Re: [M3commit] CVS Update: cm3 > > > From: hosking at cs.purdue.edu > > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > > CC: m3commit at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > There are weak and strong casts in gcc. > > > I forget the precise details, but I believe they will make a difference. > > > > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > > Presumably fold is removing the cast somewhere. > > > > Maybe a gcc bug??? > > > > I can dig deeper if you really want. > > > > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > > but different in signedness, I want to try *not* taking the address. > > > > Probably also for pointer<=>integer of pointer size. > > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > > > > - Jay > > > > > > > > > > > > ________________________________ > > > >> From: hosking at cs.purdue.edu > > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3commit at elegosoft.com > > > >> Subject: Re: [M3commit] CVS Update: cm3 > > > >> > > > >> That should be handled by placing an appropriate cast in the gcc tree. > > > >> > > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > > >> > > > >> Try building m3-sys/m3tests/p2/p240. > > > >> There is an error in the configure enable-checking about the types > > > >> being mismatched. > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> > > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> Go with the obvious less heavy handed fix of only avoiding > > > >>>> fold for integer division. > > > >>> > > > >>> I don't understand what the issue is with folding on integer > > > >> division. Please explain. > > > >>> > > > >>>> This is enough for test p240 and the unoptimized code is definitely > > > >> better. > > > >>>> NOT fully tested, but really probably works. > > > >>>> It is probably worth digging into the frontend to see if there is a > > > >> difference > > > >>>> in the types. It is probably also worth digging in the backend, like, > > > >>>> we do put in the casts consistently, why are they only not effective > > > >>>> for divide? I realize that a little bit of analysis goes a long way > > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > > >>>> On the other hand, it isn't worth too much effort. > > > >>>> Divide is the slowest least used integer operation. > > > >>> > > > >> > > > > From rcolebur at SCIRES.COM Mon Nov 29 03:01:51 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 Message-ID: I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 29 08:52:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 07:52:20 +0000 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Good catch. Please try with recent small update, thanks. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Nov 29 16:58:39 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 29 Nov 2010 10:58:39 -0500 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Jay: Your update seems to have fixed the problem. THANKS. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, November 29, 2010 2:52 AM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] build problem on Win2000 Good catch. Please try with recent small update, thanks. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcdurocher at gmail.com Mon Nov 29 18:14:56 2010 From: kcdurocher at gmail.com (Ken Durocher) Date: Mon, 29 Nov 2010 11:14:56 -0600 Subject: [M3devel] Enumeration or subrange value out of range Message-ID: I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I ran into a problem. The code compiles fine, but I get a runtime error. I'm running 5.8.6 RELEASE on AMD64. P.S. Is there already an unsigned int32 type? Is there a better way to create one? Here's the code: INTERFACE Tea; TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); END Tea. *** MODULE Tea; FROM Word IMPORT Xor, LeftShift, RightShift; VAR delta := 16_9e3779b9; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 0; BEGIN FOR i := 0 TO 31 DO sum := sum + delta; v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1))); v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3))); END; v[0] := v0; v[1] := v1; END Encrypt; PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 16_c6ef3720; BEGIN FOR i := 0 TO 32 DO v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3)); v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1)); sum := sum - delta; END; v[0] := v0; v[1] := v0; END Decrypt; BEGIN END Tea. *** MODULE Main; IMPORT IO, Fmt, Tea; VAR v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; BEGIN Tea.Encrypt(v,k); IO.Put(Fmt.Unsigned(v[0])); IO.Put(" - "); IO.Put(Fmt.Unsigned(v[1])); IO.Put("\n"); END Main. And the error: *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../Tea.m3", line 18 *** Aborted -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Nov 29 20:24:22 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 29 Nov 2010 14:24:22 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <20101129192421.GA31379@topoi.pooq.com> On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > ran into a problem. The code compiles fine, but I get a runtime error. I'm > running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? There's a signed int32, and an unsigned int31, which is designed to fit into a signed 32. The closes you can come to unsigned int32 is probably WORD. Look up Word.T. Unless you're using a 64-bit machine, in which case you get int64 and unsigned int63 for free, I suppose. -- hendrik From jay.krell at cornell.edu Mon Nov 29 21:22:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 20:22:17 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101129192421.GA31379@topoi.pooq.com> References: , <20101129192421.GA31379@topoi.pooq.com> Message-ID: Signed int32 probably works for you, for storage. (Cstdint.int32_t or such). For the operations, well, Word will do most of what you want. Just be sure to and with 16_FFFFFFFF before each assignment? We could flesh out /dev2/cm3/m3-libs/m3core/src/types to contain the Word operations. HOWEVER we'd want/need to provide version with exceptions or silence for overflow. - Jay > Date: Mon, 29 Nov 2010 14:24:22 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > > ran into a problem. The code compiles fine, but I get a runtime error. I'm > > running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > There's a signed int32, and an unsigned int31, which is designed to fit > into a signed 32. The closes you can come to unsigned int32 is probably > WORD. Look up Word.T. > > Unless you're using a 64-bit machine, in which case you get int64 and > unsigned int63 for free, I suppose. > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Nov 29 23:36:30 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 29 Nov 2010 16:36:30 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <4CF42AEE.3000807@lcwb.coop> The packed subrange type with an all-positive range doesn't do what I suspect you think it does. The subrange only affects what values can be legally stored in a variable, and the packed size only affects memory allocation when it is used as an element of an array or field of a record or object. None of this changes the semantics of the arithmetic operators +, -, Word.Xor, etc. when applied to values of this type. In Modula-3, all intermediate arithmetic is done in the native word size, in this case 64 bits. And the builtin operators +, etc. apply signed interpretation to the bit values. Only when you assign to a variable (or do any of a number of equivalent things, e.g., pass to a VALUE parameter) is a range check done. There is no trimming of intermediate results to 32 bits, despite the application of your arithmetic operators to variables of your UInt32 subrange type. So, without vetting the algorithm or knowing sample input, I can pretty well guess that things like LeftShift are shifting bits into the upper half of the word. Then when you try to assign to a UInt32 variable, you have a value outside its range. One way to do this would be to always And to 16_FFFFFFFF in your expression, before you store the result. This would ensure values within range, and, I suspect, the values you really want. Note that Modula-3 handles unsigned rather differently than many languages. You can use a subrange type, as you did, but it has to be a true subrange of INTEGER, so you can't get the normally-negative part of the range of INTEGER to be interpreted as positive, above the normal positive half of INTEGER. Should you really need full native-word-sized unsigned arithmetic, you use the type Word.T. But this is actually the same type as INTEGER, so naming it Word.T is just a programmer readability courtesy. The builtin operators +, -, etc. apply signed interpretation to the bits in a word. The operators from Word (Word.Plus, etc.) operate on values of the same type (INTEGER=Word.T), but apply unsigned interpretation to the entire word range. It would no doubt be good to replace your + operators with Word.Plus, to emphasize unsigned arithmetic. For + and -, in the absence of overflow checks, the signed and unsigned arithmetic are the same, of course, but it would be another readability courtesy. And if we ever get a compiler with overflow checking, it would still work right. I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while still And-ing results to 16_FFFFFFFF. I think this would make your code portable between 32-bit and 64-bit machines. All your arithmetic would just be applying unsigned interpretation to the bits, and the signed subrange would work like INTEGER on a 32-bit machine and as you have coded on 64 bits. All bit combinations (with no bits set in the upper half of a 64-bit word) would be in range. Of course, this all interacts with your client code and they type they use. Or maybe you could just dispense with trying to use the type system to enforce your ranges and use Word.T. If you always And your results to 16_FFFFFFFF, it will ensure they are within the desired range. There are some client interface design issues here, which you test program is not involved enough to expose. On another subject, it looks like your algorithms will either crash or won't work meaningfully unless v has exactly two elements and k has exactly 4. So using fixed array types instead of open might be a sensible way to use the type system to help here. P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The compiler is free to represent them in any way that can hold the range, and it may well give them 64 bits on a 64-bit machine. In any case, even if it gave them only 32, it would, by the semantics of the language, have to expand them to 64 before doing any arithmetic on them. HTH. Rodney Bates Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > but I ran into a problem. The code compiles fine, but I get a runtime > error. I'm running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? > > Here's the code: > > INTERFACE Tea; > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > END Tea. > > *** > > MODULE Tea; > > FROM Word IMPORT Xor, LeftShift, RightShift; > > VAR > delta := 16_9e3779b9; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 0; > > BEGIN > FOR i := 0 TO 31 DO > sum := sum + delta; > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1))); > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3))); > END; > v[0] := v0; v[1] := v1; > END Encrypt; > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 16_c6ef3720; > BEGIN > FOR i := 0 TO 32 DO > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3)); > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1)); > sum := sum - delta; > END; > v[0] := v0; v[1] := v0; > END Decrypt; > > BEGIN > END Tea. > > *** > > MODULE Main; > > IMPORT IO, Fmt, Tea; > > VAR > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > BEGIN > Tea.Encrypt(v,k); > IO.Put(Fmt.Unsigned(v[0])); > IO.Put(" - "); > IO.Put(Fmt.Unsigned(v[1])); > IO.Put("\n"); > END Main. > > And the error: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../Tea.m3", line 18 > *** > > Aborted > > From jay.krell at cornell.edu Tue Nov 30 00:01:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 23:01:47 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <4CF42AEE.3000807@lcwb.coop> References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. And *hopefully* a 64bit targeting compiler would "notice" and make some optimizations, such as only doing 32bit load/stores, but I could easily imagine it not doing that. Imho, it really would be nice to have the following types, with operator+, etc.: unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow 2 x 4 x 2 => 16 types C and C++ programmers the world over have 8 of these types (unspecified what signed overflow does, but overwhelmingly it is silent). The underlying backend exposes those 8 as well. - Jay ---------------------------------------- > Date: Mon, 29 Nov 2010 16:36:30 -0600 > From: rodney_bates at lcwb.coop > To: kcdurocher at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > The packed subrange type with an all-positive range doesn't do what > I suspect you think it does. The subrange only affects what values > can be legally stored in a variable, and the packed size only affects > memory allocation when it is used as an element of an array or field > of a record or object. None of this changes the semantics of the > arithmetic operators +, -, Word.Xor, etc. when applied to values > of this type. > > In Modula-3, all intermediate arithmetic is done in the native word > size, in this case 64 bits. And the builtin operators +, etc. apply signed > interpretation to the bit values. Only when you assign to a variable (or do > any of a number of equivalent things, e.g., pass to a VALUE parameter) > is a range check done. There is no trimming of intermediate results > to 32 bits, despite the application of your arithmetic operators to variables > of your UInt32 subrange type. > > So, without vetting the algorithm or knowing sample input, I can pretty > well guess that things like LeftShift are shifting bits into the upper > half of the word. Then when you try to assign to a UInt32 variable, > you have a value outside its range. > > One way to do this would be to always And to 16_FFFFFFFF in your expression, > before you store the result. This would ensure values within range, and, > I suspect, the values you really want. > > Note that Modula-3 handles unsigned rather differently than many languages. > You can use a subrange type, as you did, but it has to be a true subrange > of INTEGER, so you can't get the normally-negative part of the range of > INTEGER to be interpreted as positive, above the normal positive half of > INTEGER. > > Should you really need full native-word-sized unsigned arithmetic, you > use the type Word.T. But this is actually the same type as INTEGER, so > naming it Word.T is just a programmer readability courtesy. The builtin > operators +, -, etc. apply signed interpretation to the bits in a word. > The operators from Word (Word.Plus, etc.) operate on values of the same > type (INTEGER=Word.T), but apply unsigned interpretation to the entire > word range. > > It would no doubt be good to replace your + operators with Word.Plus, > to emphasize unsigned arithmetic. For + and -, in the absence of > overflow checks, the signed and unsigned arithmetic are the same, > of course, but it would be another readability courtesy. And if we > ever get a compiler with overflow checking, it would still work right. > > I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while > still And-ing results to 16_FFFFFFFF. I think this would make your code portable > between 32-bit and 64-bit machines. All your arithmetic would just be > applying unsigned interpretation to the bits, and the signed subrange would > work like INTEGER on a 32-bit machine and as you have coded on 64 bits. > All bit combinations (with no bits set in the upper half of a 64-bit word) > would be in range. Of course, this all interacts with your client code > and they type they use. > > Or maybe you could just dispense with trying to use the type system to > enforce your ranges and use Word.T. If you always And your results to > 16_FFFFFFFF, it will ensure they are within the desired range. There > are some client interface design issues here, which you test program > is not involved enough to expose. > > On another subject, it looks like your algorithms will either crash or > won't work meaningfully unless v has exactly two elements and k has exactly > 4. So using fixed array types instead of open might be a sensible way to > use the type system to help here. > > P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The > compiler is free to represent them in any way that can hold the range, and it > may well give them 64 bits on a 64-bit machine. In any case, even > if it gave them only 32, it would, by the semantics of the language, > have to expand them to 64 before doing any arithmetic on them. > > > HTH. Rodney Bates > > > Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > > but I ran into a problem. The code compiles fine, but I get a runtime > > error. I'm running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > > > Here's the code: > > > > INTERFACE Tea; > > > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > > > END Tea. > > > > *** > > > > MODULE Tea; > > > > FROM Word IMPORT Xor, LeftShift, RightShift; > > > > VAR > > delta := 16_9e3779b9; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 0; > > > > BEGIN > > FOR i := 0 TO 31 DO > > sum := sum + delta; > > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1))); > > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3))); > > END; > > v[0] := v0; v[1] := v1; > > END Encrypt; > > > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 16_c6ef3720; > > BEGIN > > FOR i := 0 TO 32 DO > > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3)); > > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1)); > > sum := sum - delta; > > END; > > v[0] := v0; v[1] := v0; > > END Decrypt; > > > > BEGIN > > END Tea. > > > > *** > > > > MODULE Main; > > > > IMPORT IO, Fmt, Tea; > > > > VAR > > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > > > BEGIN > > Tea.Encrypt(v,k); > > IO.Put(Fmt.Unsigned(v[0])); > > IO.Put(" - "); > > IO.Put(Fmt.Unsigned(v[1])); > > IO.Put("\n"); > > END Main. > > > > And the error: > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../Tea.m3", line 18 > > *** > > > > Aborted > > > > From hosking at cs.purdue.edu Tue Nov 30 04:13:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Nov 2010 22:13:32 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Rodney, Thank-you for your (as-usual) incredibly lucid explanation. Jay, On Nov 29, 2010, at 6:01 PM, Jay K wrote: > > ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. > And *hopefully* a 64bit targeting compiler would "notice" and make some > optimizations, such as only doing 32bit load/stores, but I could easily > imagine it not doing that. > > > Imho, it really would be nice to have the following types, with operator+, etc.: > > > unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow > 2 x 4 x 2 => 16 types This would be a nightmare. (i.e., over many of our dead bodies...) > C and C++ programmers the world over have 8 of these types (unspecified > what signed overflow does, but overwhelmingly it is silent). Let them rot in C hell. > The underlying backend exposes those 8 as well. But only for the purpose of accessing stored values (as Rodney explained). All operations are performed at INTEGER/Word.T granularity. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 29 Nov 2010 16:36:30 -0600 >> From: rodney_bates at lcwb.coop >> To: kcdurocher at gmail.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Enumeration or subrange value out of range >> >> The packed subrange type with an all-positive range doesn't do what >> I suspect you think it does. The subrange only affects what values >> can be legally stored in a variable, and the packed size only affects >> memory allocation when it is used as an element of an array or field >> of a record or object. None of this changes the semantics of the >> arithmetic operators +, -, Word.Xor, etc. when applied to values >> of this type. >> >> In Modula-3, all intermediate arithmetic is done in the native word >> size, in this case 64 bits. And the builtin operators +, etc. apply signed >> interpretation to the bit values. Only when you assign to a variable (or do >> any of a number of equivalent things, e.g., pass to a VALUE parameter) >> is a range check done. There is no trimming of intermediate results >> to 32 bits, despite the application of your arithmetic operators to variables >> of your UInt32 subrange type. >> >> So, without vetting the algorithm or knowing sample input, I can pretty >> well guess that things like LeftShift are shifting bits into the upper >> half of the word. Then when you try to assign to a UInt32 variable, >> you have a value outside its range. >> >> One way to do this would be to always And to 16_FFFFFFFF in your expression, >> before you store the result. This would ensure values within range, and, >> I suspect, the values you really want. >> >> Note that Modula-3 handles unsigned rather differently than many languages. >> You can use a subrange type, as you did, but it has to be a true subrange >> of INTEGER, so you can't get the normally-negative part of the range of >> INTEGER to be interpreted as positive, above the normal positive half of >> INTEGER. >> >> Should you really need full native-word-sized unsigned arithmetic, you >> use the type Word.T. But this is actually the same type as INTEGER, so >> naming it Word.T is just a programmer readability courtesy. The builtin >> operators +, -, etc. apply signed interpretation to the bits in a word. >> The operators from Word (Word.Plus, etc.) operate on values of the same >> type (INTEGER=Word.T), but apply unsigned interpretation to the entire >> word range. >> >> It would no doubt be good to replace your + operators with Word.Plus, >> to emphasize unsigned arithmetic. For + and -, in the absence of >> overflow checks, the signed and unsigned arithmetic are the same, >> of course, but it would be another readability courtesy. And if we >> ever get a compiler with overflow checking, it would still work right. >> >> I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while >> still And-ing results to 16_FFFFFFFF. I think this would make your code portable >> between 32-bit and 64-bit machines. All your arithmetic would just be >> applying unsigned interpretation to the bits, and the signed subrange would >> work like INTEGER on a 32-bit machine and as you have coded on 64 bits. >> All bit combinations (with no bits set in the upper half of a 64-bit word) >> would be in range. Of course, this all interacts with your client code >> and they type they use. >> >> Or maybe you could just dispense with trying to use the type system to >> enforce your ranges and use Word.T. If you always And your results to >> 16_FFFFFFFF, it will ensure they are within the desired range. There >> are some client interface design issues here, which you test program >> is not involved enough to expose. >> >> On another subject, it looks like your algorithms will either crash or >> won't work meaningfully unless v has exactly two elements and k has exactly >> 4. So using fixed array types instead of open might be a sensible way to >> use the type system to help here. >> >> P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The >> compiler is free to represent them in any way that can hold the range, and it >> may well give them 64 bits on a 64-bit machine. In any case, even >> if it gave them only 32, it would, by the semantics of the language, >> have to expand them to 64 before doing any arithmetic on them. >> >> >> HTH. Rodney Bates >> >> >> Ken Durocher wrote: >>> I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, >>> but I ran into a problem. The code compiles fine, but I get a runtime >>> error. I'm running 5.8.6 RELEASE on AMD64. >>> >>> P.S. Is there already an unsigned int32 type? Is there a better way to >>> create one? >>> >>> Here's the code: >>> >>> INTERFACE Tea; >>> >>> TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> >>> END Tea. >>> >>> *** >>> >>> MODULE Tea; >>> >>> FROM Word IMPORT Xor, LeftShift, RightShift; >>> >>> VAR >>> delta := 16_9e3779b9; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 0; >>> >>> BEGIN >>> FOR i := 0 TO 31 DO >>> sum := sum + delta; >>> v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1))); >>> v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3))); >>> END; >>> v[0] := v0; v[1] := v1; >>> END Encrypt; >>> >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 16_c6ef3720; >>> BEGIN >>> FOR i := 0 TO 32 DO >>> v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3)); >>> v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1)); >>> sum := sum - delta; >>> END; >>> v[0] := v0; v[1] := v0; >>> END Decrypt; >>> >>> BEGIN >>> END Tea. >>> >>> *** >>> >>> MODULE Main; >>> >>> IMPORT IO, Fmt, Tea; >>> >>> VAR >>> v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; >>> k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; >>> >>> BEGIN >>> Tea.Encrypt(v,k); >>> IO.Put(Fmt.Unsigned(v[0])); >>> IO.Put(" - "); >>> IO.Put(Fmt.Unsigned(v[1])); >>> IO.Put("\n"); >>> END Main. >>> >>> And the error: >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../Tea.m3", line 18 >>> *** >>> >>> Aborted >>> >>> From jay.krell at cornell.edu Tue Nov 30 04:43:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 03:43:26 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: > Let them rot in C hell. It's really not a bad place. Modula-3 is good: optional safety, optional unsafety ie: optional garbage collection, restrictions on taking address of locals, range checks on arrays better interface/implementation separation, such as to allow much faster compilation single inheritance object-orientation is nice, but I'd prefer for the safety to be optional (untraced objects) and multiple-inheritance generics are good, but not as good as C++ templates sets are kind of nice optionally indexing arrays by enums is kind of nice open arrays are kind of nice (relates to safety) Very small language definition is good, but I'd still like e.g. operator overloading, at least with a "fixed" interface as I described T +(T,T), never T1 +(T2, T3) for example. But I don't see why not providing these types is so good. I can see that maybe it is partly/all library instead of language. As well, as so much code is C, C++, or even Java and C#, it is what the hardware supports well. i.e. 8 bit, 16 bit, 32 bit operations are efficient, and 64 bit are also sometimes - Jay From dragisha at m3w.org Tue Nov 30 08:49:01 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 08:49:01 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? No, it isn't ! :) I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. On Nov 30, 2010, at 4:43 AM, Jay K wrote: > generics are good, but not as good as C++ templates From jay.krell at cornell.edu Tue Nov 30 09:32:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 08:32:12 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? The error messages are better these days. It is true they were terrible for a long time. Don't Modula-3 generics have the same problem? At least in the C++ case: - the errors aren't in generated files - you don't have to explicitly instantiate everything "in the build system" - for function templates, you never have to instantiate anything The automatic deduction of function template parameters is very powerful. You have to try it. I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent feature "auto". It is also true that templates seem to be largely accidental in what they allow. It seems they were designed with two primary applications: std::vector std::min/max The compile-time Turing-completeness seems to have been an accident, and what people use this for is/was perhaps better implemented through special language constructs builtin to the compiler. It is both impressive and depressive. Impressive that it is doable, depressive what it looks like. When people do "meta programming" like "is_pod", "has_copy_constructor", etc. Consider this though, have you heard the ability to do this: matrix a,b,c,d; a = b + c + d; where there are no intermediate matrices? The results are written directly into a. The people do this is that operator+ doesn't return a matrix, but rather a type that represents the result matrix addition, which is assignable to a matrix, and can also be added to matrices or the results of matrix addition. So ultimately what is assigned to a is something representation the addition of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within the rules of matrix multiplication) etc. There is no special casing, no special purpose code to handle certain combinations. I don't believe any other language has this power. Simple string addition can benefit from this same technique. Instead, string concatenation gets very special treatment by compilers, including I believe in Modula-3, Java, and C#. That's not "fair". Why should string get all the power and syntactic sugar, but not any user-defined types? Look for articles by Todd Veldhuzien. Libraries such as Blitz++. http://www.cs.rpi.edu/~musser/design/blitz/meta-art.html http://www.oonumerics.org/blitz/ etc. If C++ is just a bit too gnarly and difficult to understand and implement, I suspect subset exists with about the same level of expressiveness. But I don't know. - Jay > Subject: Re: [M3devel] Enumeration or subrange value out of range > From: dragisha at m3w.org > Date: Tue, 30 Nov 2010 08:49:01 +0100 > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; kcdurocher at gmail.com > To: jay.krell at cornell.edu > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > No, it isn't ! :) > > I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". > > I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. > > On Nov 30, 2010, at 4:43 AM, Jay K wrote: > > > generics are good, but not as good as C++ templates > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Nov 30 10:19:37 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 10:19:37 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > > The error messages are better these days. My experience is as recent as Snow Leopard, with 10.6.5 update. > It is true they were terrible for a long time. > Don't Modula-3 generics have the same problem? > At least in the C++ case: > - the errors aren't in generated files They are generated, but they are exact source you would "generate" for it. Aren't they? And you have them to step through with debugger. At least, I never hit a wall with them, like I did with that .h for vectors. > - you don't have to explicitly instantiate everything "in the build system" That would be a killing experience, to add even more complexity to Makefiles :). > - for function templates, you never have to instantiate anything > The automatic deduction of function template parameters is very powerful. > You have to try it. > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > feature "auto". A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. > It is also true that templates seem to be largely accidental in what they allow. > It seems they were designed with two primary applications: > std::vector > std::min/max There's folk saying here, it goes like: "To kill an ox for a kilo of meat." What you can do with these, and what you need to be done with these... It is mostly scope of some more dynamic environment, scripting comes to mind. To put them in compiled environment is just more of C++'s featurism (we can do it, why don't we...)... Your comparison to ML is right on spot. C++ is just mixed philosophy, mixed styles, mixed everything. Mixed results just follow suite. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Nov 30 15:45:01 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 09:45:01 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <20101130144501.GA11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 08:32:12AM +0000, Jay K wrote: > > > Consider this though, have you heard the ability to do this: > matrix a,b,c,d; > a = b + c + d; Does it work as well for a = b + a + d? > > > where there are no intermediate matrices? > The results are written directly into a. > > > The people do this is that operator+ doesn't return a matrix, but rather > a type that represents the result matrix addition, which is assignable > to a matrix, and can also be added to matrices or the results of matrix addition. > So ultimately what is assigned to a is something representation the addition > of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within > the rules of matrix multiplication) etc. There is no special casing, no special > purpose code to handle certain combinations. I don't believe any other > language has this power. Or a = a * a * a? -- hendrik From hendrik at topoi.pooq.com Tue Nov 30 16:04:18 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 10:04:18 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> Message-ID: <20101130150418.GB11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 10:19:37AM +0100, Dragi?a Duri? wrote: > > On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > > It is true they were terrible for a long time. > > Don't Modula-3 generics have the same problem? > > At least in the C++ case: > > - the errors aren't in generated files > > They are generated, but they are exact source you would "generate" for > it. Aren't they? And you have them to step through with debugger. At > least, I never hit a wall with them, like I did with that .h for > vectors. And you know what files they were gerenated from, and with what parameters. > > > - you don't have to explicitly instantiate everything "in the build system" > > That would be a killing experience, to add even more complexity to > Makefiles :). C++ managed to make linkers the world over vastly more ocmplex. It's the linker that discovers that some templates haven't been compiled yet and calls the compiler to compile them. I really don't think linkers should be all *that* language-dependent. > > > - for function templates, you never have to instantiate anything > > The automatic deduction of function template parameters is very powerful. > > You have to try it. Is finding the right template to instantiate with the right parameters always unambiguous? > > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > > feature "auto". > > A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. I don't mind ML's style, except that programmers tend to leave out too many explicit types for readability. I do mind, in C++, having something "similar to" ML without ML's internal discipline. > > > It is also true that templates seem to be largely accidental in what they allow. > > It seems they were designed with two primary applications: > > std::vector > > std::min/max > > There's folk saying here, it goes like: "To kill an ox for a kilo of meat." That's the standard practice in C++. To introduce complicated mechanisms tso that the programmer, with sufficient effort, can mimic features that should better have been reliably built into the language in the first place. > > What you can do with these, and what you need to be done with these... > It is mostly scope of some more dynamic environment, scripting comes > to mind. To put them in compiled environment is just more of C++'s > featurism (we can do it, why don't we...)... Your comparison to ML is > right on spot. Except that ML is more rationally and consistently typed. >C++ is just mixed philosophy, mixed styles, mixed > everything. Mixed results just follow suite. > -- hendrik From jay.krell at cornell.edu Tue Nov 30 18:18:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 17:18:10 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101130150418.GB11084@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com> Message-ID: > C++ managed to make linkers the world over vastly more ocmplex. It's > the linker that discovers that some templates haven't been compiled yet > and calls the compiler to compile them. I really don't think linkers > should be all *that* language-dependent. This is actually unfortunately false. C++ requires no or almost no linker support. Inline functions often use linker features that C didn't need. Templates do not. What really happens is templatized code is fully in headers. Which does have drawbacks -- large headers, slow compile. There was an implementation where the compiler looked at the linker errors. But I don't think any such implementation is in use today. > Is finding the right template to instantiate with the right > parameters always unambiguous? When it is ambiguous, there is an error. int i; long j; max(i,j); => error > That's the standard practice in C++. To introduce complicated > mechanisms tso that the programmer, with sufficient effort, can mimic > features that should better have been reliably built into the language > in the first place. In the case of templates leading to some meta programming, it was an accident. But in the case of operator overloading it seems just goodness. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 1 09:20:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Nov 2010 08:20:16 +0000 Subject: [M3devel] m3cg_set_runtime_proc vs. m3cg_set_runtime_hook Message-ID: m3cg_set_runtime_proc vs. m3cg_set_runtime_hook appear to serve almost the same purpose. m3cg_set_runtime_hook is never used. Go ahead and remove it? ?- Jay From jay.krell at cornell.edu Fri Nov 5 17:02:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 16:02:33 +0000 Subject: [M3devel] llvm Message-ID: http://llvm.org/releases/2.8/docs/ReleaseNotes.html wow, lots of progress! From dragisha at m3w.org Fri Nov 5 17:13:04 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 5 Nov 2010 17:13:04 +0100 Subject: [M3devel] llvm In-Reply-To: References: Message-ID: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> And to put Modula-3 in this neighborhood.... JIT, LLDB... On Nov 5, 2010, at 5:02 PM, Jay K wrote: > http://llvm.org/releases/2.8/docs/ReleaseNotes.html > > wow, lots of progress! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 5 22:29:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 21:29:34 +0000 Subject: [M3devel] Hudson: illegal type: 0x17, at m3cg_lineno 4 Message-ID: Fyi, I fixed these on Linux/amd64: ? illegal type: 0x17, at m3cg_lineno 4 by replacing all the installs with a release and the rebuilding. So maybe something off in the upgrade process. Maybe. But there wasn't an IL/IR/m3cg change. Not understood. I can try this on Solaris/PPC_DARWIN. (PPC_DARWIN has another problem still last I knew.) Later, - Jay From jay.krell at cornell.edu Sat Nov 6 00:17:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:17:13 +0000 Subject: [M3devel] hudson/ppc_darwin Message-ID: PPC_DARWIN in Hudson will be broken a very short while. I know the problem. It has an older g++. Other platforms should be ok, or at least several were. Definitely a few succeeded. The opencsw machines need human intervention, which I can do, later. ? At least somewhat. If they say "no cm3 installed", I'm not sure. ? If they say "invalid type: 0x17", I'll reinstall cm3. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:52:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:52:03 +0000 Subject: [M3devel] opencsw/cvs Message-ID: I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. Specifically, here, 10x: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console it is using old source. But this one, 9s: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ is working. ?- Jay From jay.krell at cornell.edu Sat Nov 6 00:56:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Nov 2010 23:56:07 +0000 Subject: [M3devel] quake rm_rec/instrumentation? Message-ID: Is rm_rec known to work/fail? You can see it is still instrumented and seems to be working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console Refresher: ? the main problem was likely to do with symlinks and stat ? the fix is hacky, deep in m3core/libm3, I changed stat to first stat and if that fails, lstat ??? (maybe should only lstat upon particular erors) ?Otherwise deleting a symlink to a nonexistant file/directory failed. ?I also changed it to not delete while enumerating, but that probably was ok either way. ?I also changed it to stat much less (caveat that the "real fix" involves more calls sometimes). ?- Jay From wagner at elegosoft.com Sat Nov 6 10:41:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:41:34 +0100 Subject: [M3devel] quake rm_rec/instrumentation? In-Reply-To: References: Message-ID: <20101106104134.yjwh4qw28cw8gck0@mail.elegosoft.com> Quoting Jay K : > Is rm_rec known to work/fail? > > You can see it is still instrumented and seems to be working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current10s/181/console I haven't noticed any problems with rmrec recently, but then I haven't monitored the cm3 regression very carefully. I seem to remember that problems faced in m3tests and we introduced a workaround there. Perhaps we could disable that and see what happens. > Refresher: > ? the main problem was likely to do with symlinks and stat > ? the fix is hacky, deep in m3core/libm3, I changed stat to first > stat and if that fails, lstat > ??? (maybe should only lstat upon particular erors) > ?Otherwise deleting a symlink to a nonexistant file/directory failed. > > ?I also changed it to not delete while enumerating, but that > probably was ok either way. > ?I also changed it to stat much less (caveat that the "real fix" > involves more calls sometimes). That all sounds OK. You could simply make the debug code depend on the -trace or -debug option of cm3 to be prepared for the next failure ;-) 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 Sat Nov 6 10:44:25 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 06 Nov 2010 10:44:25 +0100 Subject: [M3devel] hudson/ppc_darwin In-Reply-To: References: Message-ID: <20101106104425.y2ezk1i9gys0ws4w@mail.elegosoft.com> Quoting Jay K : > > PPC_DARWIN in Hudson will be broken a very short while. > I know the problem. It has an older g++. No problem. > Other platforms should be ok, or at least several were. > Definitely a few succeeded. > > The opencsw machines need human intervention, which I can do, later. That would be great. > ? At least somewhat. If they say "no cm3 installed", I'm not sure. > ? If they say "invalid type: 0x17", I'll reinstall cm3. -- 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 Sat Nov 6 13:29:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Nov 2010 12:29:04 +0000 Subject: [M3devel] small note for Solaris 2.9 Message-ID: fyi, to convert a SOLsun bootstrap to Solaris 2.9: for a in *s; do perl -pi.bak -e "s/^\s+\.hidden\s+.+$//" $a; done There are other ways. Native builds using autoconf and discover if .hidden works or not. Cross builds have to make an assumption and we err toward Solaris 2.10. We could err toward 2.9. We could adapt automatically at the "end" of "bootstrap". If we don't get a C/C++ backend, distributing as assembly-source and improving how that is built will be in order. e.g. err toward 2.9 and ship assembly source for "everything" e.g. err toward 2.9 but do this replacement if the probed assembler supports .hidden e.g. err toward 2.9 but only ship assembly for cm3, build everything else native from there. or just ignore it and nobody will notice. ?- Jay From jay.krell at cornell.edu Sun Nov 7 04:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 03:48:49 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw Message-ID: Gets as far as: --- building in SOLsun --- ignoring ../src/m3overrides /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB stubgen: Processing RemoteView.T *** *** runtime error: ***??? Thread client error: -1 ***??? file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 *** Abort - core dumped "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T?? -T.M3IMPTAB I'll try 2.10 instead.. ?- Jay From jay.krell at cornell.edu Sun Nov 7 13:35:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 12:35:22 +0000 Subject: [M3devel] init_offset? Message-ID: m3cg.i3: init_offset (o: ByteOffset;? var: Var); (* initializes the static variable at 'ADR(v)+o' with the integer ?? frame offset of the local variable 'var' relative to the frame ?? pointers returned at runtime in RTStack.Frames *) The implications of this make me nervous. ? Must locals be at the indicated location when the garbage collector runs? Should we maybe make all traced pointers volatile? ?Or at least stores to them? ? I know we have a compacting garbage collector. ? If it moves a pointer.. it updates any instance of that value seen on the stack? ? (and I know, we endeavor to "flush" registers when paused for gc, so that ? stack suffices and no need to worry further about registers, except on NT386 ? where it is a little different, we can get/set the registers of the paused thread) If the stack is scanned and updated beyond this information, what is this information for? Maybe an optimization? Granted, I haven't looked at what the frontend does here. There's lots of stuff I could figure out by reading the code.. ?- Jay From dragisha at m3w.org Sun Nov 7 13:41:40 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 13:41:40 +0100 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> We don't'. Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). So, no need to "volatilize" anything explicitly. IMO :) On Nov 7, 2010, at 1:35 PM, Jay K wrote: > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) From hosking at cs.purdue.edu Sun Nov 7 14:24:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:24:09 -0500 Subject: [M3devel] init_offset? In-Reply-To: References: Message-ID: This is used for exception handling. Sent from my iPad On 07/11/2010, at 7:35 AM, Jay K wrote: > > m3cg.i3: > > init_offset (o: ByteOffset; var: Var); > (* initializes the static variable at 'ADR(v)+o' with the integer > frame offset of the local variable 'var' relative to the frame > pointers returned at runtime in RTStack.Frames *) > > > The implications of this make me nervous. > Must locals be at the indicated location when the garbage collector runs? > Should we maybe make all traced pointers volatile? > Or at least stores to them? > I know we have a compacting garbage collector. > If it moves a pointer.. it updates any instance of that value seen on the stack? > (and I know, we endeavor to "flush" registers when paused for gc, so that > stack suffices and no need to worry further about registers, except on NT386 > where it is a little different, we can get/set the registers of the paused thread) > > If the stack is scanned and updated beyond this information, what is this information for? > Maybe an optimization? > > Granted, I haven't looked at what the frontend does here. > There's lots of stuff I could figure out by reading the code.. > > - Jay > From hosking at cs.purdue.edu Sun Nov 7 14:22:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Nov 2010 08:22:50 -0500 Subject: [M3devel] init_offset? In-Reply-To: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> References: <75F3DAA4-20B5-4C58-A389-EB8325CF13BE@m3w.org> Message-ID: Even if we did move stack-referenced objects we still would not need to volatilise. The assumption should always be that registers (as captured when a thread is stopped) will also be available for scanning. That's why on some targets we explicitly capture the thread registers. But it is true that we don't move stack-referenced objects. Sent from my iPad On 07/11/2010, at 7:41 AM, Dragi?a Duri? wrote: > We don't'. > > Any pointer references on stack and in registers are recognized as bit patterns during collection and conservatively kept in place. (I think it is the notion used:). > > So, no need to "volatilize" anything explicitly. > > IMO :) > > On Nov 7, 2010, at 1:35 PM, Jay K wrote: > >> Should we maybe make all traced pointers volatile? >> Or at least stores to them? >> I know we have a compacting garbage collector. >> If it moves a pointer.. it updates any instance of that value seen on the stack? >> (and I know, we endeavor to "flush" registers when paused for gc, so that >> stack suffices and no need to worry further about registers, except on NT386 >> where it is a little different, we can get/set the registers of the paused thread) > From lemming at henning-thielemann.de Sun Nov 7 17:33:04 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 17:33:04 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > And to put Modula-3 in this neighborhood.... JIT, LLDB... I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. From dragisha at m3w.org Sun Nov 7 20:15:57 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:15:57 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> Message-ID: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> I mentioned JIT just so, LLVM is not just JIT. And yes, you are right. GCC is a pillar of stability. Especially when you run after them trying to catch their undocumented changes to IR. NOT :) On Nov 7, 2010, at 5:33 PM, Henning Thielemann wrote: > > On Fri, 5 Nov 2010, Dragi?a Duri? wrote: > >> And to put Modula-3 in this neighborhood.... JIT, LLDB... > > I have worked a lot with LLVM-JIT from Haskell in the recent past. It's cool when it works, but it has several bugs. While the developers are hardly catching up fixing bugs, new ones that bother me, are in almost every new release. > From lemming at henning-thielemann.de Sun Nov 7 20:38:31 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 07 Nov 2010 20:38:31 +0100 (CET) Subject: [M3devel] llvm In-Reply-To: <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > I mentioned JIT just so, LLVM is not just JIT. Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. From dragisha at m3w.org Sun Nov 7 20:45:27 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Nov 2010 20:45:27 +0100 Subject: [M3devel] llvm In-Reply-To: References: <91283BFE-7DF5-4810-9018-FE9BC44A6B5B@m3w.org> <289F0DAD-EF50-4ECF-990E-B93E28D49D5C@m3w.org> Message-ID: <7FDAA6E8-7503-4105-AED4-9DE27A17D526@m3w.org> http://llvm.org/Users.html On Nov 7, 2010, at 8:38 PM, Henning Thielemann wrote: > > On Sun, 7 Nov 2010, Dragi?a Duri? wrote: > >> I mentioned JIT just so, LLVM is not just JIT. > > Since I could reproduce all of the bugs I found using .ll files, I think these bugs are also relevant for non-JIT compilation. > From jay.krell at cornell.edu Sun Nov 7 22:40:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:40:02 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: Message-ID: It works on 2.10 (opencsw current10s). ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLsun/Solaris 2.9/opencsw > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > Gets as far as: > --- building in SOLsun --- > > ignoring ../src/m3overrides > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > stubgen: Processing RemoteView.T > > > *** > *** runtime error: > *** Thread client error: -1 > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > *** > > Abort - core dumped > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > I'll try 2.10 instead.. > > - Jay > > > > > From jay.krell at cornell.edu Sun Nov 7 22:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:35:32 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? Message-ID: == package /home/jkrell/dev2/cm3/m3-ui/opengl == ?+++ /home/jkrell/cm3.sparc32-5.10/bin/cm3??? -build -DROOT=/home/jkrell/dev2/cm3 +++ --- building in SOLsun --- ignoring ../src/m3overrides new source -> compiling GL.i3 new source -> compiling GLu.i3 new source -> compiling GLX.i3 ?-> archiving libopengl.a ld: fatal: library -lGLU: not found ld: fatal: library -lGL: not found ?- Jay From jay.krell at cornell.edu Sun Nov 7 22:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 21:53:25 +0000 Subject: [M3devel] Solaris 2.10/x86/OpenGL? In-Reply-To: References: Message-ID: (I can workaround this reasonably.) ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de; m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:35:32 +0000 > Subject: [M3devel] Solaris 2.10/x86/OpenGL? > > > == package /home/jkrell/dev2/cm3/m3-ui/opengl == > > +++ /home/jkrell/cm3.sparc32-5.10/bin/cm3 -build -DROOT=/home/jkrell/dev2/cm3 +++ > --- building in SOLsun --- > > ignoring ../src/m3overrides > > new source -> compiling GL.i3 > new source -> compiling GLu.i3 > new source -> compiling GLX.i3 > -> archiving libopengl.a > ld: fatal: library -lGLU: not found > ld: fatal: library -lGL: not found > > > - Jay > > > > > From jay.krell at cornell.edu Mon Nov 8 00:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:28:36 +0000 Subject: [M3devel] slight hudson/opencsw oddity Message-ID: I saw this on current10s also. Notice how last-ok.3799 is in the subdirectories. I'll delete them and we'll see if they come back. Maybe I'll check others. m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls *??????????????? current: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg current--all-pkgs: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg last-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg prev-ok: bin?????????? lib?????????? man?????????? www last-ok.3799? license?????? pkg rel-d5.8.2: bin????? lib????? license? pkg ?- Jay From jay.krell at cornell.edu Mon Nov 8 00:42:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:42:35 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de> Message-ID: Some quoting problem on the date? Notice also checkout vs. update. So far the Hudson configurations look the same. I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop building the old source and fail if cvs fails, at least initially. I'll maybe do that on current10s also, though maybe I should leave it working/updating. working: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 Building remotely on opencsw_current10s [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC not working: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs? -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 ?- Jay ---------------------------------------- > Subject: Re: opencsw/cvs > From: dam at baltic-online.de > Date: Sun, 7 Nov 2010 14:00:50 +0100 > CC: m3devel at elegosoft.com; wagner at elegosoft.com > To: jay.krell at cornell.edu > > Hi Jay, > > Am 06.11.2010 um 00:52 schrieb Jay K: > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > Specifically, here, 10x: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > it is using old source. > > > > But this one, 9s: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > is working. > > This is strange as both seem to use cvs-feature which is ok. However, > the build is quite old and was done with current build system. How does > the proxy-setup look like as both build machines are on internal > network only? > > > Best regards > > -- Dago > From jay.krell at cornell.edu Mon Nov 8 00:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Nov 2010 23:50:47 +0000 Subject: [M3devel] maximum size bits vs. bytes Message-ID: It appears we might limit data structures to LAST(INTEGER) bits instead of LAST(INTEGER) bytes. Judging from m3core/TextLiteral.i3. I see that measuring in bits instead of bytes is surprisingly convenient, but this seems not great. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:37:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:37:11 +0000 Subject: [M3devel] Hudson/status Message-ID: Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a matter of CVS now I think. Ditto Darwin/AMD64. So I'll "reset" Hudson's state. I'm trying Solaris 2.9 again. I don't remember about Solaris/x86. I'll try again. Later. I *think* everything else is ok -- Linux/x86/amd64, FreeBSD/x86/amd64, Darwin/x86/ppc. ? I'll double check these but later. ? Not sure about OpenBSD/NetBSD. ? Network to OpenBSD seems to not work any longer in Hudson. ? - Jay From jay.krell at cornell.edu Mon Nov 8 01:34:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:34:24 +0000 Subject: [M3devel] field references in m3cg Message-ID: I was slow to realize this. Slow to realize how procs/labels/vars work. Fields need to be small integers that index into a global array of trees, just like procs/labels/vars. Types also should work this way -- that I do binary search for type id is not great. I'll get to this pretty soon as part of making the gcc IR typeful. After I get Hudson into better shape. ?- Jay From jay.krell at cornell.edu Mon Nov 8 01:39:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 00:39:37 +0000 Subject: [M3devel] opencsw/cvs In-Reply-To: References: , <7A5DDF7C-25EE-401F-B119-E3B0AF1B9E38@baltic-online.de>, Message-ID: ?>> Notice also checkout vs. update. I think that's it. I think I did the checkout manually. And then here is update succeeding: ?? http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/105/console ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dam at baltic-online.de > CC: m3devel at elegosoft.com; wagner at elegosoft.com > Subject: RE: opencsw/cvs > Date: Sun, 7 Nov 2010 23:42:35 +0000 > > > Some quoting problem on the date? > Notice also checkout vs. update. > So far the Hudson configurations look the same. > I did got and rm -rf .../m3cc on current10x to flush this out -- ie: to stop > building the old source and fail if cvs fails, at least initially. > I'll maybe do that on current10s also, though maybe I should leave it working/updating. > > working: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/345/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 349 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, November 7, 2010 11:13:14 PM UTC" > /opt/csw/cvs-feature/bin/cvs -q -z3 update -PdC -D Sunday, November 7, 2010 11:13:14 PM UTC > > > not working: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > > > - Jay > > ---------------------------------------- > > Subject: Re: opencsw/cvs > > From: dam at baltic-online.de > > Date: Sun, 7 Nov 2010 14:00:50 +0100 > > CC: m3devel at elegosoft.com; wagner at elegosoft.com > > To: jay.krell at cornell.edu > > > > Hi Jay, > > > > Am 06.11.2010 um 00:52 schrieb Jay K: > > > I think *some* but *not all* of the opencsw machines aren't succeeding with CVS. > > > > > > Specifically, here, 10x: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/101/console > > > > > > it is using old source. > > > > > > But this one, 9s: > > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-SOLsun-opencsw-current9s/72/ > > > > > > is working. > > > > This is strange as both seem to use cvs-feature which is ok. However, > > the build is quite old and was done with current build system. How does > > the proxy-setup look like as both build machines are on internal > > network only? > > > > > > Best regards > > > > -- Dago > > > From wagner at elegosoft.com Mon Nov 8 09:40:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 09:40:26 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: Message-ID: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Quoting Jay K : > I saw this on current10s also. > Notice how last-ok.3799 is in the subdirectories. If you see such a name (for longer than a few seconds), then something has crashed during the final exchange of m3 package pools. I don't really know why exactly this happens. It would be great if we could make it as atomic as possible. > I'll delete them and we'll see if they come back. If you see a pattern there, let mw know. Olaf > Maybe I'll check others. > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > *??????????????? > current: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > current--all-pkgs: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > last-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > prev-ok: > bin?????????? lib?????????? man?????????? www > last-ok.3799? license?????? pkg > > rel-d5.8.2: > bin????? lib????? license? pkg > > > ?- 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 jay.krell at cornell.edu Mon Nov 8 09:50:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 08:50:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: Presumably it's mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* ? I've definitely saw a bunch of these directories, just not with the wrong layout. I've been going to all the nodes and cleaning up/recovering. There is something bad I don't understand that hit many of them. This: ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 The "best" and very not good explanation is an m3cg intermediate format change and incorrect upgrade process. I did make a change in the past week, the removal of set_runtime_hook or such. I made sure my upgrade.py works, which I know isn't what Hudson uses. But I suspect(ed) Hudson does things right. I also added a field to a call within the past few months and it worked ok. So I don't know. - Jay > Date: Mon, 8 Nov 2010 09:40:26 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] slight hudson/opencsw oddity > > Quoting Jay K : > > > I saw this on current10s also. > > Notice how last-ok.3799 is in the subdirectories. > > If you see such a name (for longer than a few seconds), then something > has crashed during the final exchange of m3 package pools. I don't really > know why exactly this happens. It would be great if we could make it > as atomic as possible. > > > I'll delete them and we'll see if they come back. > > If you see a pattern there, let mw know. > > Olaf > > > Maybe I'll check others. > > > m3hudson at login [login]:~/current10x/work/cm3-inst/current10x > ls > > * > > current: > > bin lib man www > > last-ok.3799 license pkg > > > > current--all-pkgs: > > bin lib man www > > last-ok.3799 license pkg > > > > last-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > prev-ok: > > bin lib man www > > last-ok.3799 license pkg > > > > rel-d5.8.2: > > bin lib license pkg > > > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:05:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:05:50 +0100 Subject: [M3devel] Hudson/status In-Reply-To: References: Message-ID: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Quoting Jay K : > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > matter of CVS now I think. > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > I'm trying Solaris 2.9 again. > I don't remember about Solaris/x86. I'll try again. Later. > I *think* everything else is ok -- Linux/x86/amd64, > FreeBSD/x86/amd64, Darwin/x86/ppc. FreeBSD/x84 seems to be broken since 17 days: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ PPC_DARWIN has been broken for 7 days: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ Solaris 2.9 hasn't succeeded for more than a month: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ Same for AMD64_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ We should try to get all of these working again and then keep them in that state :-) Currently everything seems to be very unstable, but I haven't said much because (a) I haven't had much time to care and (b) I thought you were doing same major changes on the backend again. Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson display. > ? I'll double check these but later. > ? Not sure about OpenBSD/NetBSD. > ? Network to OpenBSD seems to not work any longer in Hudson. If we should exclude some platforms from the view due to non-available build machines, let me know. You can do that yourself, too at http://hudson.modula3.com:8080/view/cm3-current/configure. 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 Nov 8 10:16:03 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:16:03 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com> Message-ID: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Quoting Jay K : > Presumably it's > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > ? Why/how should that fail unless the machine actually goes down, which didn't really happen, did it? > I've definitely saw a bunch of these directories, just not with the > wrong layout. > I've been going to all the nodes and cleaning up/recovering. > There is something bad I don't understand that hit many of them. > This: > ../src/runtime/common/RTHooks.i3:15:0: fatal error: *** illegal > type: 0x17, at m3cg_lineno 4 > > The "best" and very not good explanation is an m3cg intermediate > format change and incorrect upgrade process. > I did make a change in the past week, the removal of > set_runtime_hook or such. > I made sure my upgrade.py works, which I know isn't what Hudson uses. > But I suspect(ed) Hudson does things right. The Hudson jobs uses the upgrade.sh script, but that should work, too. Actually nothing that didn't compile the core should ever get installed in the cm3-inst/last-ok package pool, but sometimes this doesn't seem to work :-/ > I also added a field to a call within the past few months and it worked ok. > > So I don't know. -- 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 Nov 8 10:18:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:18:45 +0000 Subject: [M3devel] Hudson/status In-Reply-To: <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> References: , <20101108100550.1jubh0em0wgwscc4@mail.elegosoft.com> Message-ID: Yes, I'm working on fixing all the Hudson breakage. I have more changes coming. None of them are particularly major, but in proportion to my ability to execute.... :( Everything did work on my machine (*). Hm, It could therefore be the m3cg/ir/interface change, which was an ok change, it just has to be scripted/danced properly. I believe I'll have more m3cg changes soon -- representing fields and types as "ordinals". We do have to be able to make such changes. I would be willing to have the version number actually ever change (I never ever has I believe) and use it to indicate the form and have one cm3cg that handles multiple forms. At least temporarily until they all get updated. But I know many folks dislike that kind of thing. It gets ugly as many versions are supported. I didn't anticipate C++ being such a problem, but I'm still willing to go with it. It is supposed to work, and it does "just work" with g++ 4.x. It just didn't work with g++ 3.x and Sun CC. (*) -- however a) I forgot to checkin m3makefile a few times and b) due to incrementality, it wasn't always using current files. Yep... 2010-11-01 09:59 jkrell * scripts/python/upgrade.py, m3-sys/m3cggen/src/Main.m3, m3-sys/m3middle/src/M3CG_BinRd.m3, m3-sys/m3middle/src/M3CG_Binary.i3, m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h, m3-sys/m3cc/gcc/gcc/m3cg/parse.c: remove the rest of set_runtime_hook 2010-11-01 09:37 jkrell * m3-sys/: m3cggen/src/Main.m3, m3middle/src/M3CG.m3, m3middle/src/M3CG_BinRd.m3, m3middle/src/M3CG_BinWr.m3, m3middle/src/M3CG_Binary.i3, m3middle/src/M3CG_Check.m3, m3middle/src/M3CG_Ops.i3, m3middle/src/M3CG_Rd.m3, m3middle/src/M3CG_Wr.m3, m3back/src/M3C.m3, m3back/src/M3x86.m3, m3cc/gcc/gcc/m3cg/parse.c: remove get_runtime_hook, set_runtime_hook small part remains, until I work m3cggen into upgrade.py so that m3cg.h can be more easily updated - Jay > Date: Mon, 8 Nov 2010 10:05:50 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson/status > > Quoting Jay K : > > > > > Solaris 2.10/sparc32/opencsw worked fine for me cross+boot. Just a > > matter of CVS now I think. > > Ditto Darwin/AMD64. So I'll "reset" Hudson's state. > > I'm trying Solaris 2.9 again. > > I don't remember about Solaris/x86. I'll try again. Later. > > I *think* everything else is ok -- Linux/x86/amd64, > > FreeBSD/x86/amd64, Darwin/x86/ppc. > > FreeBSD/x84 seems to be broken since 17 days: > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/ > PPC_DARWIN has been broken for 7 days: > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/ > Solaris 2.9 hasn't succeeded for more than a month: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/ > Same for AMD64_DARWIN: > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/ > > We should try to get all of these working again and then keep them > in that state :-) Currently everything seems to be very unstable, > but I haven't said much because (a) I haven't had much time to care and > (b) I thought you were doing same major changes on the backend again. > > Let's try to keep all the cm3-build an m3cc jobs blue in the Hudson > display. > > > I'll double check these but later. > > Not sure about OpenBSD/NetBSD. > > Network to OpenBSD seems to not work any longer in Hudson. > > If we should exclude some platforms from the view due to non-available > build machines, let me know. You can do that yourself, too at > http://hudson.modula3.com:8080/view/cm3-current/configure. > > 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: From jay.krell at cornell.edu Mon Nov 8 10:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:20:39 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > > mv foo foo-old-unique && mv foo-new foo && rm -rf foo-old-* > > > > ? > Why/how should that fail unless the machine actually goes down, which > didn't really happen, did it? Indeed, that is rare. Sometimes I have to reboot for some updates. xdarwin/xnbsd often "sleep". But uptime is high all around. I do wish Hudson could manage the power of the systems...leave them mostly off... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:47:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:47:10 +0000 Subject: [M3devel] SOLsun/Solaris 2.9/opencsw In-Reply-To: References: , Message-ID: This is wierd. It is pthread_create returning -1. I have seen it a number of times, but I also have seen it work ok. I'm going to punt for now and move on to other Hudson breaks. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 7 Nov 2010 21:40:02 +0000 > Subject: Re: [M3devel] SOLsun/Solaris 2.9/opencsw > > > It works on 2.10 (opencsw current10s). > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: SOLsun/Solaris 2.9/opencsw > > Date: Sun, 7 Nov 2010 03:48:49 +0000 > > > > > > Gets as far as: > > --- building in SOLsun --- > > > > ignoring ../src/m3overrides > > > > /home/jkrell/cm3.sparc32-5.9/bin/m3bundle -name ZeusBundle -F/home/jkrell/tmp/qk > > /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > stubgen: Processing RemoteView.T > > > > > > *** > > *** runtime error: > > *** Thread client error: -1 > > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 501 > > *** > > > > Abort - core dumped > > "/home/jkrell/cm3.sparc32-5.9/pkg/netobj/src/netobj.tmpl", line 37: quake runtime error: exit 134: /home/jkrell/cm3.sparc32-5.9/bin/stubgen -v1 -sno RemoteView.T -T.M3IMPTAB > > > > > > I'll try 2.10 instead.. > > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 8 10:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 09:50:37 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: > The Hudson jobs uses the upgrade.sh script, but that should work, too. > Actually nothing that didn't compile the core should ever get installed > in the cm3-inst/last-ok package pool, but sometimes this doesn't seem The important thing is that cm3 and cm3cg need to be updated together. They must always be taken as a matched pair. You may never mix and match. Well, max/match *usually* works. But the way to allow interface changes is to not do that. But those changes are rare... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Nov 8 10:59:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Nov 2010 10:59:42 +0100 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com> Message-ID: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Quoting Jay K : >> The Hudson jobs uses the upgrade.sh script, but that should work, too. >> Actually nothing that didn't compile the core should ever get installed >> in the cm3-inst/last-ok package pool, but sometimes this doesn't seem > > The important thing is that cm3 and cm3cg need to be updated together. > They must always be taken as a matched pair. > You may never mix and match. > Well, max/match *usually* works. But the way to allow interface changes > is to not do that. But those changes are rare... Our current separation of Hudson jobs for m3cc and cm3 will only work if we start with m3cc _and_ the new cm3cg can be used by the _old_ cm3 front-end. If we expect more incompatible changes related to the cm3-gcc interface, we should indeed consider a version mechanism there at least to detect mismatches. 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 Nov 8 11:11:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Nov 2010 10:11:38 +0000 Subject: [M3devel] slight hudson/opencsw oddity In-Reply-To: <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> References: , <20101108094026.4toyt90w0400gsg0@mail.elegosoft.com>, , <20101108101603.rbiqe64744s8cksw@mail.elegosoft.com>, , <20101108105942.hsp1izqpwkss040w@mail.elegosoft.com> Message-ID: > > The important thing is that cm3 and cm3cg need to be updated together. > > They must always be taken as a matched pair. > > You may never mix and match. > > Well, max/match *usually* works. But the way to allow interface changes > > is to not do that. But those changes are rare... > > Our current separation of Hudson jobs for m3cc and cm3 will only work > if we start with m3cc _and_ the new cm3cg can be used by the _old_ > cm3 front-end. If we expect more incompatible changes related to the Hm. Well, it was good to discover this, eventually. It is fine to split the tasks. You can build stuff in whatever order. But the updated files should only be used/copied at the right times/combinations. It shouldn't be difficult. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 9 11:49:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 10:49:10 +0000 Subject: [M3devel] still recovering Hudson.. Message-ID: The incorrect updating of cm3cg in Hudson is expensive to recover from. What I'm doing is for each platform, is the usual... ./boot1.py copy the result to the target machine build it there -- giving an up to date cm3 copy cm3 to a new install make a new CVS checkout boot2.sh overkill, but also a good test originally I was doing this on opencsw where I'm not sure how much succeed we've had, so doing the full boot2 was more valid. and then subset the boot2.sh output and copy it all around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. The FreeBSD4 machine is really slow! I think the CVS checkout took hours! We really need to fix this very soon -- update cm3/cm3cg correctly. I could have sworn a similar update went ok within the past few months. - Jay From wagner at elegosoft.com Tue Nov 9 12:38:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 12:38:21 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: Message-ID: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Quoting Jay K : > The incorrect updating of cm3cg in Hudson is expensive > to recover from. Sorry to hear that. > What I'm doing is for each platform, is the usual... > ./boot1.py > copy the result to the target machine > build it there -- giving an up to date cm3 > > copy cm3 to a new install > make a new CVS checkout > boot2.sh > overkill, but also a good test > originally I was doing this on opencsw where I'm not > sure how much succeed we've had, so doing the full > boot2 was more valid. > > and then subset the boot2.sh output and copy it all > around ~hudson/workspace/.../cm3-inst/current,last-ok,prev-ok, etc. Wouldn't it have been possible to backup all the package pools from from prev-ok and then perform the upgrade in the correct order? > The FreeBSD4 machine is really slow! > I think the CVS checkout took hours! This should not be; but then, something else may run during the daytime either on the server or load the network. > We really need to fix this very soon -- update cm3/cm3cg correctly. > I could have sworn a similar update went ok within the past few months. Have tou got a concrete plan? 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 Nov 9 13:02:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:02:27 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Tue, 9 Nov 2010 12:38:21 +0100 > From: wagner > Wouldn't it have been possible to backup all the package pools > from from prev-ok and then perform the upgrade in the correct order? I'm sure there's a better way but I'm doing what I know for now. Slowing me down will probably please some people anyway. :) > > The FreeBSD4 machine is really slow! > > I think the CVS checkout took hours! > > This should not be; but then, something else may run during the daytime > either on the server or load the network. I assumed maybe it is a virtual machine, and lacks "para viritualization"? > Have tou got a concrete plan? Read through more of the code and Hudson configuration and fix it. Mostly seriously. The required behavior should be trivial to implement. I just have to know where to put it. I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" are the problem. I *somewhat* suspect cm3cg is copied from one task to the other merely at the wrong time. But I have to look through the code and Hudson tasks. I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, at the same time m3cc would do its normal build. Anyway, I just have to poke around some. - Jay From jay.krell at cornell.edu Tue Nov 9 13:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:05:38 +0000 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: ps: current, last-ok, prev-ok, etc. I don't know what all these are. So I just make a valid current install and replace them all. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] still recovering Hudson.. > Date: Tue, 9 Nov 2010 12:02:27 +0000 > > > ---------------------------------------- > > Date: Tue, 9 Nov 2010 12:38:21 +0100 > > From: wagner > > > Wouldn't it have been possible to backup all the package pools > > from from prev-ok and then perform the upgrade in the correct order? > > > I'm sure there's a better way but I'm doing what I know for now. > Slowing me down will probably please some people anyway. :) > > > > > The FreeBSD4 machine is really slow! > > > I think the CVS checkout took hours! > > > > This should not be; but then, something else may run during the daytime > > either on the server or load the network. > > > I assumed maybe it is a virtual machine, and lacks "para viritualization"? > > > Have tou got a concrete plan? > > > Read through more of the code and Hudson configuration and fix it. > Mostly seriously. > The required behavior should be trivial to implement. I just have to know > where to put it. > > > > I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" > are the problem. > I *somewhat* suspect cm3cg is copied from one task to the other merely > at the wrong time. But I have to look through the code and Hudson tasks. > I also suspected it worked right, in that the copy is done in m3cc/src/m3makefile, > at the same time m3cc would do its normal build. > Anyway, I just have to poke around some. > > > > - Jay > From jay.krell at cornell.edu Tue Nov 9 13:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 9 Nov 2010 12:44:19 +0000 Subject: [M3devel] last-ok.1234 Message-ID: just a sample before I clean it up... new.elego.de [~/work/cm3-inst/new] hudson % ls -l total 24 drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 current--all-pkgs/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 current--lastok-build/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.23891/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.25217/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.41276/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.49455/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 last-ok.63073/ drwxrwx--- 9 hudson Ghudson 9 Feb 14 2010 last-ok.72551/ drwxrwxr-x 9 hudson Ghudson 9 Oct 6 22:40 prev-ok/ drwxrwx--- 8 hudson Ghudson 8 Feb 12 2010 rel-d5.7.1/ From wagner at elegosoft.com Tue Nov 9 14:20:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 09 Nov 2010 14:20:30 +0100 Subject: [M3devel] still recovering Hudson.. In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, Message-ID: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Quoting Jay K : > ps: current, last-ok, prev-ok, etc. I don't know what all these are. > So I just make a valid current install and replace them all. I thought I had explained that some time ago, but maybe I forgot. So here is the gist: o current, last-ok, prev-ok are all complete package pools + compiler that contain a complete cm3 installation o for builds, current is initialized from last-ok; then packages are built and shipped to current o if a build succeeds: - prev-ok is replaced by last-ok - last-ok is replaced by current Thus we should always have a backup for recovery in case something goes wrong. And last-ok should always be exactly what its name indicates (the last working version) (it seems that this invariant sometimes does not hold :-/) o tests usually just use last-ok Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] still recovering Hudson.. >> Date: Tue, 9 Nov 2010 12:02:27 +0000 >> >> >> ---------------------------------------- >> > Date: Tue, 9 Nov 2010 12:38:21 +0100 >> > From: wagner >> >> > Wouldn't it have been possible to backup all the package pools >> > from from prev-ok and then perform the upgrade in the correct order? >> >> >> I'm sure there's a better way but I'm doing what I know for now. >> Slowing me down will probably please some people anyway. :) >> >> >> > > The FreeBSD4 machine is really slow! >> > > I think the CVS checkout took hours! >> > >> > This should not be; but then, something else may run during the daytime >> > either on the server or load the network. >> >> >> I assumed maybe it is a virtual machine, and lacks "para viritualization"? >> >> > Have tou got a concrete plan? >> >> >> Read through more of the code and Hudson configuration and fix it. >> Mostly seriously. >> The required behavior should be trivial to implement. I just have to know >> where to put it. >> >> >> >> I suspect upgrade.sh and upgrade.py both work, but that the "split tasks" >> are the problem. >> I *somewhat* suspect cm3cg is copied from one task to the other merely >> at the wrong time. But I have to look through the code and Hudson tasks. >> I also suspected it worked right, in that the copy is done in >> m3cc/src/m3makefile, >> at the same time m3cc would do its normal build. >> Anyway, I just have to poke around some. >> >> >> >> - 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 jay.krell at cornell.edu Wed Nov 10 08:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 07:47:57 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: > I thought I had explained that some time ago, but maybe I forgot. So here > is the gist: > > o current, last-ok, prev-ok are all complete package pools + compiler that > contain a complete cm3 installation > o for builds, current is initialized from last-ok; then packages > are built and shipped to current > o if a build succeeds: > - prev-ok is replaced by last-ok > - last-ok is replaced by current > Thus we should always have a backup for recovery in case something > goes wrong. And last-ok should always be exactly what its name > indicates (the last working version) (it seems that this invariant > sometimes does not hold :-/) > o tests usually just use last-ok Do we need all this? I guess it is ok. There should be just two when idle and three during a build. ?But there are more than that currently, more than what you list. But we don't need them to be complete. They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. More generally I thinking of digging into the Hudson stuff. I think I know what to do about cm3cg, at least. There are two kinds of "ships" or installs. There is ship/install on top of the "currently running" install, and there is install to other than it, possibly to a directory that started empty (recently). Shipping of cm3 doesn't do anything. This could be viewed as a limitation -- the comments indicate it is at least partly due to shipping in-use files doesn't work on some operating systems (not just Windows, in fact, it is easy to do on Windows -- rename away first). However it is also a good thing. Shipping of m3cc/cm3g does do something. I assert that shipping either of cm3 or cm3cg on top of the "currently running" install is wrong. Shipping into other, a new empty directory, is perfectly fine. In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. For the "currently running" install, ship should do nothing, and should instead be done "outside the usual system" via sh/python. Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. And the config files (I suspect also already the case). That way they can be updated together.? *** the very important point ** Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? I'd like there to be as few of tasks as possible. "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. Related: we currently keep all snapshots on the build machines. We shouldn't keep so many. ?- Jay From jay.krell at cornell.edu Wed Nov 10 09:32:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 08:32:01 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: References: , , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , , , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, Message-ID: The fact that upgrade.sh does NOT "ship" m3cc, but installs it in a "special" way/time along with cm3, looks promising I have to look closer..to confirm/deny that things are written correctly or not. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 10 Nov 2010 07:47:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson structure? > > > > I thought I had explained that some time ago, but maybe I forgot. So here > > is the gist: > > > > o current, last-ok, prev-ok are all complete package pools + compiler that > > contain a complete cm3 installation > > o for builds, current is initialized from last-ok; then packages > > are built and shipped to current > > o if a build succeeds: > > - prev-ok is replaced by last-ok > > - last-ok is replaced by current > > Thus we should always have a backup for recovery in case something > > goes wrong. And last-ok should always be exactly what its name > > indicates (the last working version) (it seems that this invariant > > sometimes does not hold :-/) > > o tests usually just use last-ok > > > Do we need all this? > I guess it is ok. There should be just two when idle and three during a build. > But there are more than that currently, more than what you list. > > > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3. > > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that started empty (recently). > > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is at least partly > due to shipping in-use files doesn't work on some operating systems (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. > > > I assert that shipping either of cm3 or cm3cg on top of the "currently running" > install is wrong. > > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist. > > > For the "currently running" install, ship should do nothing, and should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with. > And the config files (I suspect also already the case). > > > That way they can be updated together. *** the very important point ** > > > Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks? > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations to test, etc. > Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding. > > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. > > > - Jay > > From wagner at elegosoft.com Wed Nov 10 09:48:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 09:48:22 +0100 Subject: [M3devel] Hudson structure? In-Reply-To: References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com> Message-ID: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Quoting Jay K : > >> I thought I had explained that some time ago, but maybe I forgot. So here >> is the gist: >> >> o current, last-ok, prev-ok are all complete package pools + compiler that >> contain a complete cm3 installation >> o for builds, current is initialized from last-ok; then packages >> are built and shipped to current >> o if a build succeeds: >> - prev-ok is replaced by last-ok >> - last-ok is replaced by current >> Thus we should always have a backup for recovery in case something >> goes wrong. And last-ok should always be exactly what its name >> indicates (the last working version) (it seems that this invariant >> sometimes does not hold :-/) >> o tests usually just use last-ok > > Do we need all this? > I guess it is ok. There should be just two when idle and three > during a build. > ?But there are more than that currently, more than what you list. test and build jobs may run in parallel, I think test-all-pkgs uses its own current. > But we don't need them to be complete. > They can all just contain cm3, cm3cg, mklib (for a few targets), > m3core, libm3. > > More generally I thinking of digging into the Hudson stuff. > I think I know what to do about cm3cg, at least. > > There are two kinds of "ships" or installs. > There is ship/install on top of the "currently running" install, > and there is install to other than it, possibly to a directory that > started empty (recently). > > Shipping of cm3 doesn't do anything. > This could be viewed as a limitation -- the comments indicate it is > at least partly > due to shipping in-use files doesn't work on some operating systems > (not just Windows, > in fact, it is easy to do on Windows -- rename away first). > However it is also a good thing. > > Shipping of m3cc/cm3g does do something. Yes. That's not consequent. I seem to remember that there were objections to _not_ ship cm3cg to bin though. > I assert that shipping either of cm3 or cm3cg on top of the > "currently running" > install is wrong. > > Shipping into other, a new empty directory, is perfectly fine. > In fact, a good metric might be, in both cases, to ship as long as > the destination doesn't yet exist. > > For the "currently running" install, ship should do nothing, and > should instead be done > "outside the usual system" via sh/python. > Exactly as we do for cm3 already. But that should also be how cm3cg > is dealt with. > And the config files (I suspect also already the case). > > That way they can be updated together.? *** the very important point ** Yes. > Related question: now that we have far less frequent builds, can we > merge the m3cc and build Hudson tasks? I'd rather avoid that. The m3cc builds takes hours on some systems, and _usually_ (unless someone is working on the backend) this should not need to be built at all. On the other hand: you may be right. We could easily just disable all the m3cc jobs for the time being and always build m3cc together with the other core packages in the -build- jobs. > I'd like there to be as few of tasks as possible. > "Multiplication is bad", so to speak. Multiplying work, combinations > to test, etc. > Though granularity is also nice -- if some things are broken, still > nice to see some tasks succeeding. > > Related: we currently keep all snapshots on the build machines. > We shouldn't keep so many. Do we? We shouldn't keep any on the build machine. Snapshots are (should be?) copied to birch.elegosoft.com and kept there for some time. 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 Wed Nov 10 10:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 09:08:53 +0000 Subject: [M3devel] Hudson structure? In-Reply-To: <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> References: , <20101109123821.025xzr298gww0kkc@mail.elegosoft.com>, , , <20101109142030.13pj7icnk800wkok@mail.elegosoft.com>, , <20101110094822.svn655n0o4ss0480@mail.elegosoft.com> Message-ID: ?> I seem to remember that there were objections to _not_ ship cm3cg to bin though I think it actually ship to bin/target or bin/host/target, but that is a different matter. Anyway, the problem is solved, in that upgrade.sh doesn't ship m3cc. As long as we use upgrade.sh and don't just launch into a buildship of everything, ok. ?> stuff running in parallel ? ? ah ? ?> The m3cc builds takes hours on some systems ? ? They should be faster now and better at being incremental. ? (somewhat contradictory: I used to throw -disable-dependency-checking ? as a speed up, now I don't; Cygwin is probably significantly slower ? therefore, far more forks(), but other platforms not) ? ? But that doesn't completely counter your point. ? gmp/mpfr/mpc were a significant portion, almost gone now ??? (I'm tempted to further reduce them -- one of the main ??? existing dependencies is in loop unrolling, but ??? the frontend I think already does loop unrolling; ??? but cm3cg should be able to do better since it does ??? more sophisticated analysis -- and still, cm3cg ??? has available efficient 64bit integers without gmp, ??? the need for gmp is in general therefore, unclear; ??? the need for mpfr is actually sort of "more clear", except ??? that it isn't used where I thought it might be -- it isn't ??? used for floating point constant propagation, but for implementing ??? builtin" functions; besides, floating point is essentially ??? identical across all build hosts, so doesn't need to be "simulated"; ??? and mpc is for complex math, which we never use..mpfr ??? and mpc are completely gone, gmp is much smaller than previously) I'm torn now. I want to test an m3cg.i3 change, but if it fails, I don't want to do the tedious recovery. Maybe if I'm quick, only one or two machines will see it? ?- Jay From jay.krell at cornell.edu Wed Nov 10 12:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 11:37:10 +0000 Subject: [M3devel] rcc_upgradecm3.cmd Message-ID: Randy, code like this: pushd ..\..\.. if exist "bin\cm3.exe" if exist "pkg" set CM3_ROOT=%CD%& popd & goto FoundRoot is almost exactly equivalent to: if exist "..\..\..\bin\cm3.exe" if exist "..\..\..\pkg" set CM3_ROOT=..\..\..& popd & goto FoundRoot the advantage of the second form is fewer intermediate side effects ? i.e. not cd'ing around to the various possible path, just using them more directly the disadvantage of the second form is the ".." survive? and may be unsightly. ? But leaving ".." will work ok with very little exception. The ".." can be removed via e.g.: call :GetFullPath CM3_ROOT %CM3_ROOT% goto :end_GetFullPath :GetFullPath set %1=%~f2 goto :eof :end_GetFullPath I believe that would also work. There are other ways.. such as looping over all the possibilities and taking the first that works. anyway.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 13:48:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 12:48:14 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile Message-ID: == package /Users/jay/dev2/cm3/elego/m3msh == ?+++ /cm3/bin/cm3??? -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling M3MiniShell.m3 ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' ? m3_backend => 1 I've been sprinkling volatile around, no luck yet.. ?- Jay From jay.krell at cornell.edu Wed Nov 10 14:15:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:15:31 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: nevermind, I found a workaround that is probably ok a deoptimization but it shouldn't be common and significant But it also isn't the expected one. I figured volatile somewhere would do the trick, not avoiding inlining. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > From jay.krell at cornell.edu Wed Nov 10 14:39:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 13:39:08 +0000 Subject: [M3devel] hudson/m3cg ir changes Message-ID: Looking into why the m3cg.i3 changes broke... http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull This log doesn't show the "safe" upgrade that avoids ship and then ships all at once process. But it does show something else that should work: ?it builds all ?and then ships all (including cm3cg) ?and then presumably would handle cm3 specially However when it goes to ship cm3, it compiles stuff. That should already be compiled. And cm3cg had just been updated. Here: === package m3-sys/cm3 === +++ cm3 -build -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' +++ ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 This I don't understand. And can't trivially reproduce. I understand that every time you build cm3, it will recompile Version.i3 and another file. But 1) this tries to recompile more and 2) for me, cm3 -ship never recompiles anything anyway Also notice that LINUXLIBC6 never broke. Hm. Given the break Oct 27 and what I might have done to fix, that's inconclusive. You can see LINUXLIBC6 also compiling during -ship. So, two things now... change the process to use upgrade.sh. and/or find out why -ship is compiling anything. - Jay From hosking at cs.purdue.edu Wed Nov 10 16:14:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Nov 2010 10:14:01 -0500 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: Message-ID: Did you disable inlining on everything? Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 10 Nov 2010 12:48:14 +0000 >> Subject: [M3devel] setjmp/longjmp still missing volatile >> >> >> == package /Users/jay/dev2/cm3/elego/m3msh == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling M3MiniShell.m3 >> ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': >> ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' >> m3_backend => 1 >> >> >> >> I've been sprinkling volatile around, no luck yet.. >> >> - Jay >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Nov 10 16:22:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Nov 2010 16:22:31 +0100 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: References: Message-ID: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Quoting Jay K : > Looking into why the m3cg.i3 changes broke... > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/113/consoleFull > > This log doesn't show the "safe" upgrade that avoids ship and then > ships all at once process. > > But it does show something else that should work: > ?it builds all > ?and then ships all (including cm3cg) > ?and then presumably would handle cm3 specially > > However when it goes to ship cm3, it compiles stuff. That should > already be compiled. > And cm3cg had just been updated. > > Here: > > === package m3-sys/cm3 === > +++ cm3 -build > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > $RARGS && cm3 -ship $RARGS > -DROOT='/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3' > +++ > ../FreeBSD4/Version.i3:1:0: fatal error: *** illegal type: 0x17, at > m3cg_lineno 4 > compilation terminated. > m3_backend => 1 > > This I don't understand. > And can't trivially reproduce. > I understand that every time you build cm3, it will recompile > Version.i3 and another file. > But 1) this tries to recompile more and 2) for me, cm3 -ship never > recompiles anything anyway What you probably see is that a set of packages is first built locally and then with buildship. You cannot just use ship on a locally compiled set (with overrides), because the compiler will refuse to do that as the dependencies have changed. > Also notice that LINUXLIBC6 never broke. > Hm. Given the break Oct 27 and what I might have done to fix, that's > inconclusive. > You can see LINUXLIBC6 also compiling during -ship. This is strange. > So, two things now... change the process to use upgrade.sh. > and/or find out why -ship is compiling anything. If upgrade.sh already works OK, how could the last-ok installations on the Hudson nodes become corrupted? Ideally, the cm3-current-build job should fail and retry everything with upgrade.sh. Probably the new incompatible cm3cg has already been installed then in current, and we would need to restart with last-ok. Could that be the problem? Then it should be easy to fix (in scripts/regression/defs.sh in test_build_system). 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 Wed Nov 10 22:04:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:04:01 +0000 Subject: [M3devel] hudson/m3cg ir changes In-Reply-To: <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> References: , <20101110162231.xt3dhsezsoco0sk0@mail.elegosoft.com> Message-ID: > What you probably see is that a set of packages is first built locally > and then with buildship. You cannot just use ship on a locally compiled Oops, you are right. I misread the log. > > You can see LINUXLIBC6 also compiling during -ship. > > This is strange. I probably misread the log there too. > If upgrade.sh already works OK, how could the last-ok installations > on the Hudson nodes become corrupted? Ideally, the cm3-current-build > job should fail and retry everything with upgrade.sh. Probably the > new incompatible cm3cg has already been installed then in current, and > we would need to restart with last-ok. Could that be the problem? > Then it should be easy to fix (in scripts/regression/defs.sh in > test_build_system). Thanks, I will look further. Basically, endeavor to use upgrade more and buildship less. ?- Jay From jay.krell at cornell.edu Wed Nov 10 22:00:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 21:00:34 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , Message-ID: No, and it doesn't. Variables are introduced later. ?- Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Wed, 10 Nov 2010 10:14:01 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > Did you disable inlining on everything? > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > nevermind, I found a workaround that is probably ok > a deoptimization but it shouldn't be common and significant > But it also isn't the expected one. I figured volatile somewhere would > do the trick, > not avoiding inlining. > > - Jay > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 10 Nov 2010 12:48:14 +0000 > Subject: [M3devel] setjmp/longjmp still missing volatile > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > new source -> compiling M3MiniShell.m3 > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > might be clobbered by 'longjmp' or 'vfork' > m3_backend => 1 > > > > I've been sprinkling volatile around, no luck yet.. > > - Jay > > > > > > > From jay.krell at cornell.edu Thu Nov 11 00:29:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Nov 2010 23:29:33 +0000 Subject: [M3devel] setjmp/longjmp still missing volatile In-Reply-To: References: , , , Message-ID: I'll try to run volatization after the variables are introduced. I still like the idea of the frontend unnesting nested functions. It'd probably help here. I'm very willing to selectively suppress inlining to fix this, which I had done, but I'd rather not broadly suppress inlining. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] setjmp/longjmp still missing volatile > Date: Wed, 10 Nov 2010 21:00:34 +0000 > > > No, and it doesn't. > Variables are introduced later. > > - Jay > > ________________________________ > > From: hosking at cs.purdue.edu > > Date: Wed, 10 Nov 2010 10:14:01 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] setjmp/longjmp still missing volatile > > > > Did you disable inlining on everything? > > Really, the volatilize code should handle 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 Nov 10, 2010, at 8:15 AM, Jay K wrote: > > > > > > nevermind, I found a workaround that is probably ok > > a deoptimization but it shouldn't be common and significant > > But it also isn't the expected one. I figured volatile somewhere would > > do the trick, > > not avoiding inlining. > > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Wed, 10 Nov 2010 12:48:14 +0000 > > Subject: [M3devel] setjmp/longjmp still missing volatile > > > > > > == package /Users/jay/dev2/cm3/elego/m3msh == > > > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > > --- building in AMD64_DARWIN --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling M3MiniShell.m3 > > ../src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > > ../src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' > > might be clobbered by 'longjmp' or 'vfork' > > m3_backend => 1 > > > > > > > > I've been sprinkling volatile around, no luck yet.. > > > > - Jay > > > > > > > > > > > > > > > From jay.krell at cornell.edu Mon Nov 15 11:18:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Nov 2010 10:18:40 +0000 Subject: [M3devel] configur -enable-checking vs. types Message-ID: jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression struct { } * struct { } D.1466 = &M_RsrcFilter; I don't think this is actually "struct value" vs. "struct pointer". It is actually "struct1 pointer" vs. "struct2 pointer". So, I can probably just cast it away. But it points to a need in compiler to deal differently with types. They should be small integers like procs/labels/vars, I believe. So should fields. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 16 01:00:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 00:00:53 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: Message-ID: I tried various casts, no luck. I'm confused here.. :( - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: configur -enable-checking vs. types > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > struct > { > } * > > struct > { > } > > D.1466 = &M_RsrcFilter; > > > > I don't think this is actually "struct value" vs. "struct pointer". > It is actually "struct1 pointer" vs. "struct2 pointer". > So, I can probably just cast it away. > But it points to a need in compiler to deal differently with types. > They should be small integers like procs/labels/vars, I believe. > So should fields. > > > - Jay From jay.krell at cornell.edu Tue Nov 16 22:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Nov 2010 21:10:58 +0000 Subject: [M3devel] configur -enable-checking vs. types In-Reply-To: References: , Message-ID: The problem seems to be that we set the type for the segment, use that, and then change it. M3CG_HANDLER (BIND_SEGMENT) { gcc_assert (align >= !!size); current_segment = var; TREE_TYPE (var) = m3_build_type (type, size, align); M3CG_HANDLER (DECLARE_SEGMENT) { TREE_TYPE (var) = m3_build_type_id (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT, type_id); layout_decl (var, BIGGEST_ALIGNMENT); however, when I fix lots of configure -enable-checking problems, I get crashes. I suspect this one needs to be this way -- need the correct segment size. Making more passes will enable getting it right up front. Later. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: configur -enable-checking vs. types > Date: Tue, 16 Nov 2010 00:00:53 +0000 > > > I tried various casts, no luck. I'm confused here.. :( > > - Jay > > > ________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: configur -enable-checking vs. types > > Date: Mon, 15 Nov 2010 10:18:40 +0000 > > > > jbook2:graphicutils jay$ cm3cg AMD64_DARWIN/RsrcFilter.mc -quiet -m64 > > ../src/RsrcFilter.m3: In function 'RsrcFilter_M3': > > ../src/RsrcFilter.m3:145:0: error: type mismatch in address expression > > struct > > { > > } * > > > > struct > > { > > } > > > > D.1466 = &M_RsrcFilter; > > > > > > > > I don't think this is actually "struct value" vs. "struct pointer". > > It is actually "struct1 pointer" vs. "struct2 pointer". > > So, I can probably just cast it away. > > But it points to a need in compiler to deal differently with types. > > They should be small integers like procs/labels/vars, I believe. > > So should fields. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 17 22:55:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Nov 2010 21:55:24 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console Started by user jkrell Building remotely on opencsw_current10x [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts /opt/csw/cvs-feature/bin/cvs -Q -z3 -d :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs co -P -D Sunday, November 7, 2010 11:31:42 PM UTC cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src cm3/scripts cvs server: cannot find module `November' - ignored cvs server: cannot find module `7,' - ignored cvs server: cannot find module `2010' - ignored cvs server: cannot find module `11:31:42' - ignored cvs server: cannot find module `PM' - ignored cvs server: cannot find module `UTC' - ignored cvs [checkout aborted]: cannot expand modules FATAL: CVS failed. exit code=1 Archiving artifacts Recording fingerprints Finished: FAILURE Can we format the time in a way that doesn't have any spaces? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Nov 18 09:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 09:16:39 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: Message-ID: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Quoting Jay K : > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > Started by user jkrell > Building remotely on opencsw_current10x > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > cm3/scripts > cvs server: cannot find module `November' - ignored > cvs server: cannot find module `7,' - ignored > cvs server: cannot find module `2010' - ignored > cvs server: cannot find module `11:31:42' - ignored > cvs server: cannot find module `PM' - ignored > cvs server: cannot find module `UTC' - ignored > cvs [checkout aborted]: cannot expand modules > FATAL: CVS failed. exit code=1 > Archiving artifacts > Recording fingerprints > Finished: FAILURE > > Can we format the time in a way that doesn't have any spaces? I'm sure I already fixed that one months ago, though I don't remember the details. Has somehow an old script been installed in bin/cvs? 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 Nov 18 12:15:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:15:20 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:36:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:36:48 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com> Message-ID: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Quoting Jay K : > Hm. Yes and no. I hadn't looked enough, but I think it is still broken. > There is $HOME/bin/cvs. I didn't know. > I guess it is mainly to avoid -z3. > Which rings a bell. We had some problem with that. Yes. I know that the first version didn't work, but I fixed that. And I think it _did_ run well some time. > Build #103 is not current. It is from Nov 8. > Before it, a bunch of success. Since it, a bunch of failure. > I had failed to look if the failures were all the same. > They are not. In fact the CVS failures seem to be all/mainly Nov 8. > > HOWEVER the later failures have been fixed in CVS. > Even though cvs upd isn't erroring, it also isn't working. > > I'm manually updating now, so the evidence will be lost. > But I'm sure it will either come back or is easily deliberately brought back. I'll have a look at the weekend, 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 Nov 18 12:38:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:38:12 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: scripts/regression/cvs.sh was in CVS It doesn't seem to work -- quotes are lost. cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, I put in place, we'll see. Would be nice to only quote if there are spaces though. Can we make Hudson use a date form without spaces? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:15:20 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Hm. Yes and no. I hadn't looked enough, but I think it is still broken. There is $HOME/bin/cvs. I didn't know. I guess it is mainly to avoid -z3. Which rings a bell. We had some problem with that. Build #103 is not current. It is from Nov 8. Before it, a bunch of success. Since it, a bunch of failure. I had failed to look if the failures were all the same. They are not. In fact the CVS failures seem to be all/mainly Nov 8. HOWEVER the later failures have been fixed in CVS. Even though cvs upd isn't erroring, it also isn't working. I'm manually updating now, so the evidence will be lost. But I'm sure it will either come back or is easily deliberately brought back. Thanks, - Jay > Date: Thu, 18 Nov 2010 09:16:39 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/103/console > > > > Started by user jkrell > > Building remotely on opencsw_current10x > > [cm3-current-m3cc-I386_SOLARIS-opencsw-current10x] $ cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D "Sunday, November 7, 2010 11:31:42 PM UTC" > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > /opt/csw/cvs-feature/bin/cvs -Q -z3 -d > > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > co -P -D Sunday, November 7, 2010 11:31:42 PM UTC > > cm3/m3-sys/m3cc/gcc cm3/m3-sys/m3cc/gcc-4.5 cm3/m3-sys/m3cc/src > > cm3/scripts > > cvs server: cannot find module `November' - ignored > > cvs server: cannot find module `7,' - ignored > > cvs server: cannot find module `2010' - ignored > > cvs server: cannot find module `11:31:42' - ignored > > cvs server: cannot find module `PM' - ignored > > cvs server: cannot find module `UTC' - ignored > > cvs [checkout aborted]: cannot expand modules > > FATAL: CVS failed. exit code=1 > > Archiving artifacts > > Recording fingerprints > > Finished: FAILURE > > > > Can we format the time in a way that doesn't have any spaces? > > I'm sure I already fixed that one months ago, though I don't > remember the details. > > Has somehow an old script been installed in bin/cvs? > > 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: From wagner at elegosoft.com Thu Nov 18 12:43:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Nov 2010 12:43:15 +0100 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, Message-ID: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Quoting Jay K : > scripts/regression/cvs.sh was in CVS > It doesn't seem to work -- quotes are lost. > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. Strange. > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > I put in place, we'll see. Would be nice to only quote if there are > spaces though. > > Can we make Hudson use a date form without spaces? I don't think so. Not without changing the CVS plugin source at least. 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 Nov 18 12:48:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:48:03 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> References: , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , <20101118123648.sd4mcru5us0w4g0o@mail.elegosoft.com> Message-ID: > And I think it _did_ run well some time. It ran without error, I can see that. But across a few days/builds, no changed. #97 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/97/console no changes detected Deleting old artifacts from #95 #96 http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/96/console $ no changes detected L?sche alte Artefakte von #94 Maybe I logged in around that time, and that caused something to change from German to English? But the date format is the same either way. - We'll see if my updated cvs helps? - Maybe if you merely login it'll change back and that's it?? (Great example of touching something and it breaks/fixes..but we don't know if that was it. It appears to pickup no changes for a while, even in German, and there is another language change if you keep going back... I went all the way back to the oldest retained build, it doesn't seem to have ever picked up any changes. We'll see with my updated cvs..I'd rather write these wrappers in Python, of course. Or Modula-3. Or quake if possible. :) ) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 18 12:53:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 11:53:43 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> References: , , , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com> Message-ID: Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Thu Nov 18 13:26:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Nov 2010 12:26:32 +0000 Subject: [M3devel] opencsw/cvs problem with spaces in time on command line In-Reply-To: References: ,,, , <20101118091639.fxnnqnztis8wkocc@mail.elegosoft.com>, , , , , , , <20101118124315.a6pfo213284c0sw4@mail.elegosoft.com>, Message-ID: Looking good. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/120/console - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Thu, 18 Nov 2010 11:53:43 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line Mine didn't work either. Now that I know a more, I'll take a crack at it. http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/119/console Started by user jkrell Building remotely on opencsw_current10x [gcc] $ cvs -q -z3 update -PdC -D "Thursday, November 18, 2010 11:48:24 AM UTC" /opt/csw/cvs-feature/bin/cvs "-q" "update" "-PdC" "-D" "Thursday, November 18, 2010 11:48:24 AM UTC" Unknown command: `"-q"' CVS commands are: add Add a new file/directory to the repository admin Administration front end for rcs annotate Show last revision where each line was modified checkout Checkout sources for editing commit Check files into the repository - Jay > Date: Thu, 18 Nov 2010 12:43:15 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] opencsw/cvs problem with spaces in time on command line > > Quoting Jay K : > > > scripts/regression/cvs.sh was in CVS > > It doesn't seem to work -- quotes are lost. > > cvs2.sh is what was on opencsw and doesn't seem to work -- quotes are lost. > Strange. > > > cvs3.sh is what I came up with based on cvs2.sh, seems maybe better, > > I put in place, we'll see. Would be nice to only quote if there are > > spaces though. > > > > Can we make Hudson use a date form without spaces? > > I don't think so. Not without changing the CVS plugin source at least. > > 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: From jay.krell at cornell.edu Fri Nov 19 10:12:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 09:12:16 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining Message-ID: parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 11:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 10:01:44 +0000 Subject: [M3devel] bind_segment vs. declare_segment? Message-ID: I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:39:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:39:00 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: Message-ID: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> This is a shame. 1. gcc supports nested functions. 2. gcc supports inlining. 3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong. Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote: > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 15:43:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 09:43:03 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: Message-ID: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled. Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote: > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 19 16:36:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Nov 2010 16:36:05 +0100 Subject: [M3devel] m3cc compilation errors Message-ID: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Currently I cannot compile m3cc on AMD64-FREEBSD: ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before '(' token ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token gmake: *** [m3cg/parse.o] Error 1 "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg 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 Nov 19 17:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:20:00 +0000 Subject: [M3devel] m3cc compilation errors In-Reply-To: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> References: <20101119163605.6k5v2rsd2c0wkkgk@mail.elegosoft.com> Message-ID: book2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c Connection closed by 88.198.39.217 [ I fell asleep] cvs [commit aborted]: end of file from server (consult above messages if any) [ I woke up[ jbook2:m3cg jay$ cvs -z3 commit -m "typos in previous" parse.c /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v <-- parse.c new revision: 1.458; previous revision: 1.457 - Jay > Date: Fri, 19 Nov 2010 16:36:05 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3cc compilation errors > > Currently I cannot compile m3cc on AMD64-FREEBSD: > > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: error: expected `)' before ';' token > ../../gcc-4.5/gcc/m3cg/parse.c:1119: warning: empty body in an if-statement > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1120: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1121: error: expected `;' before '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected identifier before > '(' token > ../../gcc-4.5/gcc/m3cg/parse.c:1122: error: expected `;' before '(' token > gmake: *** [m3cg/parse.o] Error 1 > "/d/home/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake > runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg > > 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: From jay.krell at cornell.edu Fri Nov 19 17:21:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:21:02 +0000 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: Good question. I can look into that. But notice that it will *definitely* be different. But maybe not in a critical way -- they use trampolines. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:39:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining This is a shame.1. gcc supports nested functions.2. gcc supports inlining.3. gcc should work with both nested functions and inlining. If gcc can handle all of this for C but not M3 then we must be doing something wrong.Can we see how similar code fragments behave when expressed in C? On Nov 19, 2010, at 4:12 AM, Jay K wrote:parse.c: /* don't inline anything, to fix: elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' */ I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. Oh, and a use of a static link. I wouldn't check for their intersection. Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. I tried selectively disabling inlining. No luck. I might try again, but don't plan on success there. OK? Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:24:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:24:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 17:41:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 16:41:24 +0000 Subject: [M3devel] incorrect copying in Hudson? Message-ID: http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_DARWIN/61/console t/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post /rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/ rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/rel-post/last-ok/ pkg/m3core/src/text: name too long (not copied) I had caused this before manually installing. But I'm not sure I did this time. I'll clean it up. We'll see if it comes bcak. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 19 18:08:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Nov 2010 17:08:14 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, Message-ID: Another option would be that every time we get an offset load against it, see if it is beyond the current size, in which case grow the size and relayout. That could end up relayout many times. Besides accessing beyond its size, the problem, for configure -enable-checking, is that we later completely replace the type, so returning its address from the module initializer ends up a different type than the actual data. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 16:24:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? ok, well I got it to work. Using the new ability to loop over the data multiple times easily in the backend. Though the frontend or middle end could make the transform, if all backends want the data in a better order. - Jay From: hosking at cs.purdue.edu Date: Fri, 19 Nov 2010 09:43:03 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] bind_segment vs. declare_segment? declare_segment doesn't have the size because it is unknown at the time of the declaration, which comes before the module is compiled.Only as the module is compiled does the size become known, with Bind_segment emitted at the end. On Nov 19, 2010, at 5:01 AM, Jay K wrote:I'm not looking at m3front. I should. Why does declare_segment not have the size? I'm going to just live with whatever the frontend does for now. Make an extra pass to find the bind_segments, so that when I do things "for real", declare_segment can set the size correctly. Later I'll do better -- making the segment contain fields. So that globals become debuggable, in stock gdb (as big records). But first I want configure enable-checking to work. (with one exception, the static link stuff..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Nov 19 19:51:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 19 Nov 2010 13:51:49 -0500 Subject: [M3devel] nested functions vs. setjmp vs. inlining In-Reply-To: References: , <90C4F88B-9E7B-4D92-ABA3-19C12F27FF0D@cs.purdue.edu> Message-ID: <3586ABC8-1EE1-4E1D-8B81-67450C7E51BA@cs.purdue.edu> The trampoline is purely a method for constructing a closure that can be passed. So long as we are using the same mechanism to grab the static chain we should be working similarly. We just need to emulate the effect of the trampoline on the rest of gcc. On Nov 19, 2010, at 11:21 AM, Jay K wrote: > Good question. I can look into that. But notice that it will *definitely* be different. But maybe not > in a critical way -- they use trampolines. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:39:00 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining > > This is a shame. > 1. gcc supports nested functions. > 2. gcc supports inlining. > 3. gcc should work with both nested functions and inlining. > > If gcc can handle all of this for C but not M3 then we must be doing something wrong. > Can we see how similar code fragments behave when expressed in C? > > On Nov 19, 2010, at 4:12 AM, Jay K wrote: > > parse.c: > /* don't inline anything, to fix: > elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters': > elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork' > */ > > > I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork. > Oh, and a use of a static link. > I wouldn't check for their intersection. > Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use. > > I tried selectively disabling inlining. No luck. > I might try again, but don't plan on success there. > > > OK? > > > Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed. > (not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...) > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 09:43:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 08:43:56 +0000 Subject: [M3devel] LONGINT in frontend? Message-ID: How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 13:47:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 12:47:41 +0000 Subject: [M3devel] gmp dependency? Message-ID: I already eliminated the mpc and mpfr dependency. They are only used for "builtins", which we never use. And drastically reduced gmp use. These were a big part of building m3cc. The remaining use of gmp appears to only be in tree-ssa-loop-niter.c which determines/estimates the number of times a loop runs, I believe in order to possibly unroll it, or other loop optimizations. Considering removing this, in order to cut the gmp dependency? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 14:02:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 13:02:29 +0000 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? Message-ID: Olaf, I'm not sure Hudson works right in terms of using/copying the right prebuilt cm3cg at the right time. I see evidence of using out of date cm3cg. Given that we don't ever by default clean m3cc. And given that I adjusted stuff to use upgrade.sh and I believe install cm3cg and cm3 together at the right time. But given that I didn't look into or adjust how the pairs of tasks (m3cc and build) interace. Given that I think build works on its own. I request that we stop all the m3cc tasks and remove or at least disable the PREBUILD_CM3CG stuff. i.e. asking agreement/permission. I'm willing to do it. Alternately stated: I understand and can fix if needed upgrade.sh. Though I do use upgrade.py myself, all the time. We should consider it..but they are about the same. Anyway, my point is, I understand, like, "a single workspace" setup. Maybe Hudson should work that way? Now, I understand there is granularity. You want to see some Hudson tasks finish, before others run. So, in the interest of that, I'm very willing to leave m3cc first, and if that succeeds, have build build its own cm3cg. That is wasteful, but can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 15:11:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 14:11:26 +0000 Subject: [M3devel] enable-checking vs. static link Message-ID: So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Nov 20 17:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 20 Nov 2010 11:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: Message-ID: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Target.Int is appropriate here, not LONGINT. Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote: > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 21:55:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 20:55:10 +0000 Subject: [M3devel] enable-checking vs. static link In-Reply-To: References: Message-ID: Alas.. == package /Users/jay/dev2/cm3/m3-tools/m3tk == new source -> compiling StdFormat.m3 ../src/astdisplay/StdFormat.m3: In function 'StdFormat__Enumeration_type': ../src/astdisplay/StdFormat.m3:193:0: internal compiler error: Bus error Please submit a full bug report, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: enable-checking vs. static link Date: Sat, 20 Nov 2010 14:11:26 +0000 So, I had sprinkled in volatile for some reason, on static link loads. That seems to make the first check fail: if (gimple_call_chain (stmt) && !is_gimple_val (gimple_call_chain (stmt))) { #if 0 /* Modula-3 hack */ error ("invalid static chain in gimple call"); debug_generic_stmt (gimple_call_chain (stmt)); return true; #else return false; #endif } because is_gimple_val has something to do with if the value can be in a register, and volatile values cannot be. So I removed the volatile in parse.c However, then this next check fails: /* If there is a static chain argument, this should not be an indirect call, and the decl should have DECL_STATIC_CHAIN set. */ if (gimple_call_chain (stmt)) { if (TREE_CODE (fn) != ADDR_EXPR || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL) { #if 0 /* Modula-3 hack */ error ("static chain in indirect gimple call"); return true; #else return false; #endif } and I think this might just be a fundamental disagreement between gcc and Modula-3. ?? As well, even the first check still fails sometimes, just not as much. I have to look into that further. The second check fails around here RTExFrame.m3: PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY = (* we need to fool the compiler into generating a call to a nested procedure... *) BEGIN p (a); END CallProc; Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all function pointer calls go to a C helper? That might also reduce the patch to gcc? (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional) I don't know. I still don't know how this static link stuff really works. I do know that a closure is a -1 marker, a function pointer, a static link. I guess the function pointer could to be a function with any signature. So writing a portable C helper would be..difficult. Well, more later. I'm curious to see the affects of removing the volatile, somewhat independent of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem. That'll be nice to clear up. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 20 22:35:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Nov 2010 21:35:40 +0000 Subject: [M3devel] Hudson vs. ..? Message-ID: Hudson is great. and by ".." I don't mean Tinderbox or any alternative. I mean vs. my own ongoing development. Things are working for me. I build AMD64_DARWIN repeatly, using the built cm3, with -O3. It all works. Sometimes I boot1.py to other platforms, which exercises a fair amount. Yet Hudson is getting various internal compiler errors, on some platforms. e.g. Darwin, Solaris. But not all, I think e.g. FreeBSD, Linux. And it isn't using optimization realize. Possible but unlikely that -O3 is covering up problems. Usually optimization only ever hurts, doesn't help, in terms of getting a successful compilation. I strongly suspect this is due to cm3 vs. cm3cg mismatch. I believe upgrade.sh works. I believe the regression scripts work now, by using upgrade.sh. Except if you run "build" w/o "m3cc" and it picks up old cm3cg. Can we somehow easily "reset" everything? I have tried somewhat, but it was tedious and didn't clearly work. Going back to rel 5.8.6 and then upgrade.sh should work. I don't want to have to visit every node or do my own boot1.py + boot2.sh again. I did that fairly recently, when Hudson was definitely not upgrading cm3/cm3cg properly. I *think* it does now, but I think it got mixed up in some cases. e.g. maybe by building "build" w/o building "m3cc"? Maybe that guarantees it picks up an old mismatched cm3cg? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 01:02:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 01:02:20 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: Message-ID: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Quoting Jay K : > > Hudson is great. > and by ".." I don't mean Tinderbox or any alternative. > I mean vs. my own ongoing development. > > Things are working for me. > I build AMD64_DARWIN repeatly, using the built cm3, with -O3. > > It all works. > > Sometimes I boot1.py to other platforms, which exercises a fair amount. > > Yet Hudson is getting various internal compiler errors, on some platforms. > e.g. Darwin, Solaris. Yes, those are broken currently. > But not all, I think e.g. FreeBSD, Linux. > And it isn't using optimization realize. > Possible but unlikely that -O3 is covering up problems. Usually > optimization > only ever hurts, doesn't help, in terms of getting a successful > compilation. > > I strongly suspect this is due to cm3 vs. cm3cg mismatch. > I believe upgrade.sh works. > I believe the regression scripts work now, by using upgrade.sh. > Except if you run "build" w/o "m3cc" and it picks up old cm3cg. > > Can we somehow easily "reset" everything? > I have tried somewhat, but it was tedious and didn't clearly work. > > Going back to rel 5.8.6 and then upgrade.sh should work. I think we can insert that as a last fallback: build from the last-rel version (which should be 5.8.6). I'll have a look at it tomorrow. > I don't want to have to visit every node or do my own boot1.py + > boot2.sh again. > I did that fairly recently, when Hudson was definitely not upgrading > cm3/cm3cg properly. > I *think* it does now, but I think it got mixed up in some cases. > e.g. maybe by building "build" w/o building "m3cc"? Maybe that > guarantees it picks > up an old mismatched cm3cg? On your own systems (xdarwin) you could easily inject a working pair of cm3/cm3cg into the last-ok pool, that should fix mismatches. 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 Nov 21 01:15:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:15:37 +0000 Subject: [M3devel] Hudson vs. ..? In-Reply-To: <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: > On your own systems (xdarwin) you could easily inject a working pair > of cm3/cm3cg into the last-ok pool, that should fix mismatches. Yeah, I thought so, and tried, no luck. I can try again. Later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 01:26:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 00:26:49 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Nov 21 13:24:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 13:24:38 +0100 Subject: [M3devel] Hudson vs. ..? In-Reply-To: References: , <20101121010220.d1624tjqww8cgsg4@mail.elegosoft.com> Message-ID: <20101121132438.dlvido2jgggw8go8@mail.elegosoft.com> Quoting Jay K : > > > On your own systems (xdarwin) you could easily inject a working pair > > of cm3/cm3cg into the last-ok pool, that should fix mismatches. > > Yeah, I thought so, and tried, no luck. > I can try again. Later. I think I've found the reason for that. Let's see if it suffices to get everything into working condition again. 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 Nov 21 14:16:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Nov 2010 14:16:26 +0100 Subject: [M3devel] hudson tasks m3cc vs. build vs. prebuilt cm3cg? In-Reply-To: References: Message-ID: <20101121141626.tmgwxxzaos4ckso0@mail.elegosoft.com> Quoting Jay K : I didn't notice this mail before... see below > Olaf, I'm not sure Hudson works right in terms of using/copying the right > prebuilt cm3cg at the right time. > > I see evidence of using out of date cm3cg. > > Given that we don't ever by default clean m3cc. > And given that I adjusted stuff to use upgrade.sh and I believe > install cm3cg and cm3 together at the right time. > > But given that I didn't look into or adjust how the pairs of tasks > (m3cc and build) interace. > > Given that I think build works on its own. > > I request that we stop all the m3cc tasks and remove or at least > disable the PREBUILD_CM3CG stuff. > i.e. asking agreement/permission. I'm willing to do it. I'm not against disabling all the m3cc tasks and just build m3cc in the usual way in the build jobs. That was just a performance optimization making sense we built release candiate after release candidate again and again on many more platforms than now. I suggest something like this: % cvs diff -u scripts/regression/ Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. cvs diff: Diffing scripts/regression Index: scripts/regression/hudson_build_system.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/regression/hudson_build_system.sh,v retrieving revision 1.21 diff -u -u -r1.21 hudson_build_system.sh --- scripts/regression/hudson_build_system.sh 21 Nov 2010 13:00:38 -0000 1.21 +++ scripts/regression/hudson_build_system.sh 21 Nov 2010 13:14:07 -0000 @@ -37,7 +37,7 @@ ;; esac fi -if [ "$CLEAN" = "false" ]; then +if [ "$CLEAN" = "false" && "$USE_PREBUILT_CM3CG" = "true" ]; then if [ -x "${CM3CG}" ]; then echo "checking for working pre-built cm3cg in ${CM3CG}" cp -p "${CM3CG}" ${WS}/cm3cg > Alternately stated: > I understand and can fix if needed upgrade.sh. > Though I do use upgrade.py myself, all the time. We should > consider it..but they are about the same. > Anyway, my point is, I understand, like, "a single workspace" setup. > Maybe Hudson should work that way? > Now, I understand there is granularity. You want to see some > Hudson tasks finish, > before others run. So, in the interest of that, I'm very willing > to leave m3cc first, > and if that succeeds, have build build its own cm3cg. That is wasteful, but > can be helpful. I mainly want to remove/disable the "prebuilt_cm3cg" thing. Single build workspace setup should be OK now. Shall I disable all the m3cc jobs? We'll keep all the test jobs though... Olaf PS: The lastok and release installations on your Darwin machine are all empty, see http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_DARWIN/63/console. -- 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 Nov 21 16:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:44:40 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 16:48:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 10:48:00 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu> Message-ID: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote: > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:03:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:03:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , <70EDC567-BB31-40BB-ABEC-7E84738B7C13@cs.purdue.edu> Message-ID: > In general, it is OK for a cross-host to impose smaller restrictions than the target. I don't think I agree. To some extent it is unavoidable: e.g. compiling really really large files However, I ought to be able to do this? typedef struct { int a[1UL << 40]; } foo; foo* a; I can in C, from a 32host to a 64bit target. The way to allow it is reasonably easy, just tedious in Modula- w/o LONGINT or operator overloading. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:48:00 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? In general, it is OK for a cross-host to impose smaller restrictions than the target. A native compiler should always be bootstrapped from any cross-compiled compiler anyway, at which point it will acquire it's native restrictions. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:08:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:08:53 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:10:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:10:59 +0000 Subject: [M3devel] operator overloading? Message-ID: Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:33:31 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:33:31 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Some of us find operator overloading anathema because it obscures the actual underlying code. It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain situations. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 19:35:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 13:35:21 -0500 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , Message-ID: I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote: > Isn't it at least better than current situation of using INTEGER? > I understand in the future LONGINT might not suffice and Target.Int might be desired. > But today LONGINT suffices and lets more things work. > > > Granted you can no longer compile with older compilers. > > > Surely what we could at that time is introduce INTEGER128. > Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, > and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? > > > And perhaps by then have switched LONGINT to Target.Int? > Perhaps by then we'll have operator overloading in Modula-3? > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 10:44:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. > > On Nov 20, 2010, at 7:26 PM, Jay K wrote: > > Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. > Operators are nice. e.g. defining them for user defined types. > > > In some places, things are limited by an INTEGER number of bits. > In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: > > > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > > Possibly due to ArrayType.m3: > > IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN > Error.Msg ("CM3 restriction: array has too many elements"); > p.n_elts := 1; > END; > > or > > IF (p.n_elts > 0) AND (p.elt_pack > 0) > AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN > Error.Msg ("CM3 restriction: array type too large"); > full_size := 0; > p.total_size := 0; > > > or ArrayExpr.m3: > > > IF NOT TInt.ToInt (nn, n) THEN > Error.Msg ("array has too many elements"); > END; > > > Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. > You end up having to replace many instances of INTEGER, and then all the uses. > With LONGINT, perhaps, you can just change the types and not have to visit every single use. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Sat, 20 Nov 2010 11:35:21 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGINT in frontend? > > Target.Int is appropriate here, not LONGINT. > Where is the current 2Gbyte limit encoded? > > On Nov 20, 2010, at 3:43 AM, Jay K wrote: > > How about we use LONGINT a bunch in the frontend > instead of INTEGER? Either that, or Target.Int. > I do think 32bit frontend should be able to target > 64bit target, including declaring data structures > larger than 2GB. (besides that the current limit > is 2 billion bits, not bytes like it should be..) > > LONGINT is easier. > > I won't get to either for a little while, other stuff first. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:50:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:50:22 +0000 Subject: [M3devel] LONGINT in frontend? In-Reply-To: References: , , , <2C0B2C13-EC3C-4D22-9E95-3ECC4F03EEF7@cs.purdue.edu>, , , , , , Message-ID: I disagree there also. 32bit addresses/size_t and 64bit quantities can be mixed reasonably, and have been for a very long time in a *lot* of code. There are plenty of files and volumes over 2GB in size manipulated by 32 bit code. The 32-bit world will continue for a while -- phones, iPad, etc. But yet iPad is available with 64GB storage. Are the 53bits of precision in double for migration to a 53bit world? I agree the *name* LONGINT is a hack though, in the poor tradition of C's "long long". Again again again, 32bit host C compilers have been targeting 64bit targets for a very long time and continue to do so. And I would hope they don't have the same problem we have. I know gcc has this "HOST_WIDE_INT" for this reason -- long long for 32bit hosts targeting 64bit. Obviously a bit inefficient, but probably really ok and worth it. Also, again, I believe our limit is in number of bits, not bytes. So it is even too small for native builds. But I agree, maybe not easy to fix, if the problem is real (I think it is). Bit counts are convenient. I guess maybe this is a good reason to extend Target.Int another byte? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world. On Nov 21, 2010, at 1:08 PM, Jay K wrote:Isn't it at least better than current situation of using INTEGER? I understand in the future LONGINT might not suffice and Target.Int might be desired. But today LONGINT suffices and lets more things work. Granted you can no longer compile with older compilers. Surely what we could at that time is introduce INTEGER128. Bootstrap "with restrictions" first like today, extending Target.Int where it is already used, and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions? And perhaps by then have switched LONGINT to Target.Int? Perhaps by then we'll have operator overloading in Modula-3? - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 10:44:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT. There is no guarantee of this. Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT. On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail. Operators are nice. e.g. defining them for user defined types. In some places, things are limited by an INTEGER number of bits. In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64: (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); Possibly due to ArrayType.m3: IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN Error.Msg ("CM3 restriction: array has too many elements"); p.n_elts := 1; END; or IF (p.n_elts > 0) AND (p.elt_pack > 0) AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN Error.Msg ("CM3 restriction: array type too large"); full_size := 0; p.total_size := 0; or ArrayExpr.m3: IF NOT TInt.ToInt (nn, n) THEN Error.Msg ("array has too many elements"); END; Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone. You end up having to replace many instances of INTEGER, and then all the uses. With LONGINT, perhaps, you can just change the types and not have to visit every single use. - Jay From: hosking at cs.purdue.edu Date: Sat, 20 Nov 2010 11:35:21 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT in frontend? Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded? On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend instead of INTEGER? Either that, or Target.Int. I do think 32bit frontend should be able to target 64bit target, including declaring data structures larger than 2GB. (besides that the current limit is 2 billion bits, not bytes like it should be..) LONGINT is easier. I won't get to either for a little while, other stuff first. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 19:53:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 18:53:55 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: "Obscures the underlying code" is true of so many things. Exceptions. Garbage collection. Objects. Nested functions. Function calls! Default parameters. Generics. Pickles. RPC. It is a matter of degree, cost, value though, granted. The runtime cost of operating overloading is zero, at least. And the unobscured code is horrible to read and write actually (which is the reason for many features). This is case where "obscure" is clearly good, and not obscure. But it is a matter of degree. I should probably try implementing it before I ask for it too strongly. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 13:33:31 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? Some of us find operator overloading anathema because it obscures the actual underlying code.It certainly does not fit well with the design philosophy of Modula-3. On Nov 21, 2010, at 1:10 PM, Jay K wrote:Is it really so difficult to add operator overloading to the language? >From a user's point of view, I know it is very useful in certain situations. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:08:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking Message-ID: gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 20:24:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 19:24:53 +0000 Subject: [M3devel] configure -enable-checking In-Reply-To: References: Message-ID: (ps: we should also be using -O1/-O2/-O3 in some Hudson tasks; or maybe just one -- cm3 accepts -O and then passes down to cm3cg whatever is in the config file..I don't find this model adequate though and I always edit the config; probably better approach is a) environment variable + b) different build_dir; many systems work that way, you don't want too many variants/build_dirs, but 2 isn't unusual ("debug" and "retail" for example)) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 21 Nov 2010 19:08:40 +0000 Subject: [M3devel] configure -enable-checking gcc has this configure -enable-checking. It finds bugs in the compiler. Now, it isn't just a boolean. There is configure -enable-checking=yes which enables some cheap ones. configure -enable-checking=all which enables much more and is very noticably very slow configure -enable-checking=foo,bar,abc you can list specific ones. Now, configure -enable-checking=all is really really slow. I am getting very close to fixing "all" the problems it finds. I will likely have configure -enable-checking=a specific list I have be the one and only way, at least for now. However I'm also interested in - not making everyone pay even that cost - the even more expensive -enable-checking=all, at least on one target, if not all So I think we should setup some extra Hudson nodes and/or tasks for this. Really, it shouldn't need extra nodes. Tasks should do. I imagine, the Hudson task would/should be an environment variable and m3cc/src/m3makefile would check it. These tasks would not generate snapshots/releases, as their cm3cg would be unacceptably slow. (Really, I like extra checking, finding bugs, but it is really incredibly slow.) Unfortunately it is not a runtime option to cm3cg. That would help a lot -- as we could build releases/snapshots with the one cm3cg. But we can't. Someone is/was looking into making it a command line option. I know a slow down is unavoidable even then, but maybe ok. Anyway, we don't have it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Nov 21 20:27:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 21 Nov 2010 11:27:34 -0800 Subject: [M3devel] operator overloading? In-Reply-To: References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> Message-ID: <20101121192734.DB4761A208C@async.async.caltech.edu> I don't like changes in Modula-3, on principle. I have a lot of code that is over ten years old and that I never look at, and I never want to look at, despite the fact that things that I do depend on computers that execute probably billions of instructions in this code every day. Now I depend on such code that depends on being able to parse Modula-3 itself, so the language, I feel should stay both forward- and backward-compatible. (I really don't like LONGINT for that reason.) But that being said, operator overloading seems relatively harmless. It changes the meaning only of executable code, not interfaces, and unless you are writing a compiler, there isn't much reason to be processing the executable code. This is all assuming you do it right. And there must be some way of calling the overloaded operators using functional notation so that generated code can get at them. What has always bugged me about operator overloading in C++ is just what an unabashed hack it is. You can use the operators from C, but no others? And they have to have the same associativity and commutativity rules as in C? And they can be only unary or binary? Does anyone do this better? Is it even possible? I suppose the main thing is to specify a rule for converting a OP b to OP(a,b)... What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And then the associativity rules... is addition left- or right-associative? Who remembers that..? now *that* is obscure. And it won't work on RECORDs or ARRAYs or SETs, which don't have methods... Would it be possible to write a pre-processor using m3tk that would implement the entirety of operator overloading? I think that would be an elegant solution, but I've never used m3tk on implementations... The reason I am saying this is that judging from the syntax equations in the Green Book, it is possible that m3tk might accept a program using overloaded operators, and only semantic analysis on the parsed structure would uncover the overloaded operators and flag them as semantic errors (in standard Modula-3). But I might be wrong. And m3tk might have broken code in it. When we were designing async. hardware with Modula-3 we had a thing called "m3texthack" that would let you do special kinds of macros in Modula-3 code. Your source file would be Module.c3, which would be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 of course). In any case, an m3tk solution rather than a Modula-3 solution would easily allow you to specify different rules for different types, or even for different source files, rather than being tied to something nailed down in the language spec. Mika Jay K writes: >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >"Obscures the underlying code" is true of so many things. >Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >Default parameters. Generics. Pickles. RPC. >It is a matter of degree=2C cost=2C value though=2C granted. > The runtime cost of operating overloading is zero=2C at least. > And the unobscured code is horrible to read and write actually (which is = >the reason for many features). > This is case where "obscure" is clearly good=2C and not obscure. > But it is a matter of degree. I should probably try implementing it befor= >e I ask for it too strongly. > > > - Jay > >From: hosking at cs.purdue.edu >Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] operator overloading? > > > >Some of us find operator overloading anathema because it obscures the actua= >l underlying code.It certainly does not fit well with the design philosophy= > of Modula-3. > >On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > add operator overloading to the language? > >>From a user's point of view=2C I know it is very useful in certain situatio= >ns. > > > - Jay > > > > > > = > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >"Obscures the underlying code" is true of so many things.
Exceptions. Ga= >rbage collection. Objects. Nested functions. Function calls! Default parame= >ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >though=2C granted.
 =3B The runtime cost of operating overloading is= > zero=2C at least.
 =3B And the unobscured code is horrible to read = >and write actually (which is the reason for many features).
 =3B Thi= >s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >ut it is a matter of degree. I should probably try implementing it before I= > ask for it too strongly.


 =3B - Jay

elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >e: [M3devel] operator overloading?

>"> >Some of us find ope= >rator overloading anathema because it obscures the actual underlying code.<= >div>It certainly does not fit well with the design philosophy of Modula-3.<= >br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >
ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >a=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 font-size: med= >ium=3B">
: Tahoma=3B">Is it really so difficult to add operator overloading to the l= >anguage?

From a user's point of view=2C I know it is very useful in = >certain situations.


 =3B- Jay




n>

>= > >--_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From hosking at cs.purdue.edu Sun Nov 21 21:04:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:04:09 -0500 Subject: [M3devel] operator overloading? In-Reply-To: <20101121192734.DB4761A208C@async.async.caltech.edu> References: , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu> <20101121192734.DB4761A208C@async.async.caltech.edu> Message-ID: I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > I don't like changes in Modula-3, on principle. I have a lot of code > that is over ten years old and that I never look at, and I never want > to look at, despite the fact that things that I do depend on computers > that execute probably billions of instructions in this code every day. > > Now I depend on such code that depends on being able to parse > Modula-3 itself, so the language, I feel should stay both forward- > and backward-compatible. (I really don't like LONGINT for that > reason.) > > But that being said, operator overloading seems relatively harmless. > It changes the meaning only of executable code, not interfaces, and unless > you are writing a compiler, there isn't much reason to be processing > the executable code. This is all assuming you do it right. And there > must be some way of calling the overloaded operators using functional > notation so that generated code can get at them. > > What has always bugged me about operator overloading in C++ is just > what an unabashed hack it is. You can use the operators from C, > but no others? And they have to have the same associativity and > commutativity rules as in C? And they can be only unary or binary? > Does anyone do this better? Is it even possible? I suppose the main > thing is to specify a rule for converting > > a OP b > > to > > OP(a,b)... > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > then the associativity rules... is addition left- or right-associative? > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > or ARRAYs or SETs, which don't have methods... > > Would it be possible to write a pre-processor using m3tk that would > implement the entirety of operator overloading? I think that would > be an elegant solution, but I've never used m3tk on implementations... > The reason I am saying this is that judging from the syntax equations > in the Green Book, it is possible that m3tk might accept a program using > overloaded operators, and only semantic analysis on the parsed structure > would uncover the overloaded operators and flag them as semantic errors > (in standard Modula-3). But I might be wrong. And m3tk might have > broken code in it. > > When we were designing async. hardware with Modula-3 we had a thing > called "m3texthack" that would let you do special kinds of macros in > Modula-3 code. Your source file would be Module.c3, which would > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > of course). > > In any case, an m3tk solution rather than a Modula-3 solution would easily > allow you to specify different rules for different types, or even for > different source files, rather than being tied to something nailed down > in the language spec. > > Mika > > > > Jay K writes: >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> "Obscures the underlying code" is true of so many things. >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = >> Default parameters. Generics. Pickles. RPC. >> It is a matter of degree=2C cost=2C value though=2C granted. >> The runtime cost of operating overloading is zero=2C at least. >> And the unobscured code is horrible to read and write actually (which is = >> the reason for many features). >> This is case where "obscure" is clearly good=2C and not obscure. >> But it is a matter of degree. I should probably try implementing it befor= >> e I ask for it too strongly. >> >> >> - Jay >> >> From: hosking at cs.purdue.edu >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] operator overloading? >> >> >> >> Some of us find operator overloading anathema because it obscures the actua= >> l underlying code.It certainly does not fit well with the design philosophy= >> of Modula-3. >> >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= >> add operator overloading to the language? >> >>> From a user's point of view=2C I know it is very useful in certain situatio= >> ns. >> >> >> - Jay >> >> >> >> >> >> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= >> rbage collection. Objects. Nested functions. Function calls! Default parame= >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = >> though=2C granted.
 =3B The runtime cost of operating overloading is= >> zero=2C at least.
 =3B And the unobscured code is horrible to read = >> and write actually (which is the reason for many features).
 =3B Thi= >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= >> ut it is a matter of degree. I should probably try implementing it before I= >> ask for it too strongly.


 =3B - Jay

> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= >> e: [M3devel] operator overloading?

>> > "> >> Some of us find ope= >> rator overloading anathema because it obscures the actual underlying code.<= >> div>It certainly does not fit well with the design philosophy of Modula-3.<= >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= >>
> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= >> a=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 font-size: med= >> ium=3B">
> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= >> anguage?

From a user's point of view=2C I know it is very useful in = >> certain situations.


 =3B- Jay




> n>

>> = >> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- From rodney_bates at lcwb.coop Sun Nov 21 20:52:08 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 13:52:08 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: Message-ID: <4CE97868.3050804@lcwb.coop> I've been around that block too many times with Ada and C++. Programmer- defined overloading (either operator and/or function name) is a semantic disaster. It interacts with stuff all over the language, and the complexity just explodes. I have spent several years of my life having to learn every in and out and dark corner of overloading and all its fallout in Ada, both to implement it and to try to help working programmers cope with it. I can say with complete confidence that Ada would be half the size/complexity it is, without it. Moreover, hard as it is for a compiler writer or language lawyer to understand it, it is even worse for the everyday programmer. Again, I can testify that almost nobody (the above types excepted) comes anywhere close to understanding the rules. They don't even want to try. Their eyes glaze over, and they just want you to tell them how to code such-and-such so it will compile and call the function they want it to. For the future, all they want is restrictive but simple programming guidelines on things to avoid unconditionally, so they won't keep getting burned again and again. C++'s take on overloading is simpler in some respects, more complicated in others, but overall, quite a bit worse and, I dare say, much poorer-understood by working programmers. The upshot is that the (mis)feature of programmer-defined overloading is mostly used only in degenerate and trivial ways. This, of course, raises the question what good is it when: 1) it makes programming more difficult, 2) programmers avoid most of it anyway, and 3) even so, it results in lots of code that programmers just barely hope they understand the meaning of what they wrote. The latter is a *very* big deal in quality of released code. And I didn't even mention the added difficulty in implementing the language. I do realize that function call notation can be a lot harder to read (and write) than operator notation in a few situations. I've also been around that block more times than one, in fact quite recently. I have many times mused over whether it would be possible to add something that would give the most important benefits and not be a complete semantic train wreck. Sometimes I think it could be done a lot better than we have seen, but at best, it would be a significant semantic complication, even if restricted to operators only. In Modula-3, we have a language whose most distinctive characteristic is an exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other language that comes close by this criterion. We need to preserve that. Rodney Bates Jay K wrote: > Is it really so difficult to add operator overloading to the language? > > From a user's point of view, I know it is very useful in certain > situations. > > > - Jay > > > > From jay.krell at cornell.edu Sun Nov 21 21:11:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:11:46 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: > I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Nov 21 21:14:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Nov 2010 15:14:08 -0500 Subject: [M3devel] operator overloading? In-Reply-To: References: , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , <20101121192734.DB4761A208C@async.async.caltech.edu>, Message-ID: On Nov 21, 2010, at 3:11 PM, Jay K wrote: > > I'm now starting to wish that we had left LONGINT out, > > > Just now? :) > (This is another reason I'm somewhat open to tediously using Target.Int in frontend, > in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > > ARRAY [1..2] OF INTEGER .. same representation as C "long long" > > > These are potentially much different, e.g. when being returned from a function by value. > NT/x86 returns them in the register pair edx:eax. > Granted, it *might* also store small structs that way, but I'm not sure. > (you could bury the array in a struct then as well) > But I guess a small special case would do. > > > Why are sets in the language, with infix operators? > Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. > > > If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. > Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. > > > I have done a *little* bit of Scheme programming, so I at least was at some point > sympathetic to the view of having no infix operators whatsoever. > > > The story of the Dylan programming language is also interesting. > It was originally prefix only but caved and went infix for the sake of > programmer convenience. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 21 Nov 2010 15:04:09 -0500 > > To: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] operator overloading? > > > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > > that is over ten years old and that I never look at, and I never want > > > to look at, despite the fact that things that I do depend on computers > > > that execute probably billions of instructions in this code every day. > > > > > > Now I depend on such code that depends on being able to parse > > > Modula-3 itself, so the language, I feel should stay both forward- > > > and backward-compatible. (I really don't like LONGINT for that > > > reason.) > > > > > > But that being said, operator overloading seems relatively harmless. > > > It changes the meaning only of executable code, not interfaces, and unless > > > you are writing a compiler, there isn't much reason to be processing > > > the executable code. This is all assuming you do it right. And there > > > must be some way of calling the overloaded operators using functional > > > notation so that generated code can get at them. > > > > > > What has always bugged me about operator overloading in C++ is just > > > what an unabashed hack it is. You can use the operators from C, > > > but no others? And they have to have the same associativity and > > > commutativity rules as in C? And they can be only unary or binary? > > > Does anyone do this better? Is it even possible? I suppose the main > > > thing is to specify a rule for converting > > > > > > a OP b > > > > > > to > > > > > > OP(a,b)... > > > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > > then the associativity rules... is addition left- or right-associative? > > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > > or ARRAYs or SETs, which don't have methods... > > > > > > Would it be possible to write a pre-processor using m3tk that would > > > implement the entirety of operator overloading? I think that would > > > be an elegant solution, but I've never used m3tk on implementations... > > > The reason I am saying this is that judging from the syntax equations > > > in the Green Book, it is possible that m3tk might accept a program using > > > overloaded operators, and only semantic analysis on the parsed structure > > > would uncover the overloaded operators and flag them as semantic errors > > > (in standard Modula-3). But I might be wrong. And m3tk might have > > > broken code in it. > > > > > > When we were designing async. hardware with Modula-3 we had a thing > > > called "m3texthack" that would let you do special kinds of macros in > > > Modula-3 code. Your source file would be Module.c3, which would > > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > > of course). > > > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > > allow you to specify different rules for different types, or even for > > > different source files, rather than being tied to something nailed down > > > in the language spec. > > > > > > Mika > > > > > > > > > > > > Jay K writes: > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/plain; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> "Obscures the underlying code" is true of so many things. > > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > > >> Default parameters. Generics. Pickles. RPC. > > >> It is a matter of degree=2C cost=2C value though=2C granted. > > >> The runtime cost of operating overloading is zero=2C at least. > > >> And the unobscured code is horrible to read and write actually (which is = > > >> the reason for many features). > > >> This is case where "obscure" is clearly good=2C and not obscure. > > >> But it is a matter of degree. I should probably try implementing it befor= > > >> e I ask for it too strongly. > > >> > > >> > > >> - Jay > > >> > > >> From: hosking at cs.purdue.edu > > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] operator overloading? > > >> > > >> > > >> > > >> Some of us find operator overloading anathema because it obscures the actua= > > >> l underlying code.It certainly does not fit well with the design philosophy= > > >> of Modula-3. > > >> > > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > > >> add operator overloading to the language? > > >> > > >>> From a user's point of view=2C I know it is very useful in certain situatio= > > >> ns. > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> > > >> > > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > > >> Content-Type: text/html; charset="iso-8859-1" > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> > > >> > > >> > > >> > > >> > > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > > >> and write actually (which is the reason for many features).
 =3B Thi= > > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > > >> ut it is a matter of degree. I should probably try implementing it before I= > > >> ask for it too strongly.


 =3B - Jay

> >> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > > >> e: [M3devel] operator overloading?

> > >> > >> "> > > >> Some of us find ope= > > >> rator overloading anathema because it obscures the actual underlying code.<= > > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > > >>
> >> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > > >> a=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 font-size: med= > > >> ium=3B">
> >> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > > >> anguage?

From a user's point of view=2C I know it is very useful in = > > >> certain situations.


 =3B- Jay




> >> n>

> > >> = > > >> > > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:16:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:16:28 +0000 Subject: [M3devel] operator overloading? In-Reply-To: <4CE97868.3050804@lcwb.coop> References: , <4CE97868.3050804@lcwb.coop> Message-ID: Rodney, what if the signatures of overloaded operators is "fixed". That is + can only take two T's and return one T. < can only take two T's and return one boolean. No implicit conversions. (I do think some conversions are ok, integers to wider integers, but nobody else agrees.) Isn't that much simpler than any other language does it? Are the rules still hard to understand? (And I believe this is still fairly valuable.) Furthermore, something like, maybe, the operators may only be defined in the interface that declares T? Or maybe, the operators are always available on all types, but you get a link error if they weren't defined? And of course, you can't define them for builtin types. They are already defined. And, I realize, there is a question of errors. + can fail. The interface would have to that they raise exceptions. You could have something like FPU.i3 custom per type to control it. The compiler wouldn't know about this (except maybe for builtin LONGINT). - Jay > Date: Sun, 21 Nov 2010 13:52:08 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] operator overloading? > > I've been around that block too many times with Ada and C++. Programmer- > defined overloading (either operator and/or function name) is a semantic > disaster. It interacts with stuff all over the language, and the complexity > just explodes. I have spent several years of my life having to learn every > in and out and dark corner of overloading and all its fallout in Ada, both > to implement it and to try to help working programmers cope with it. I can > say with complete confidence that Ada would be half the size/complexity > it is, without it. > > Moreover, hard as it is for a compiler writer or language lawyer to understand > it, it is even worse for the everyday programmer. Again, I can testify that > almost nobody (the above types excepted) comes anywhere close to understanding > the rules. They don't even want to try. Their eyes glaze over, and they just > want you to tell them how to code such-and-such so it will compile and call > the function they want it to. For the future, all they want is restrictive > but simple programming guidelines on things to avoid unconditionally, so they > won't keep getting burned again and again. > > C++'s take on overloading is simpler in some respects, more complicated in > others, but overall, quite a bit worse and, I dare say, much poorer-understood > by working programmers. > > The upshot is that the (mis)feature of programmer-defined overloading is mostly > used only in degenerate and trivial ways. This, of course, raises the question > what good is it when: 1) it makes programming more difficult, 2) programmers > avoid most of it anyway, and 3) even so, it results in lots of code that > programmers just barely hope they understand the meaning of what they wrote. > The latter is a *very* big deal in quality of released code. And I didn't even > mention the added difficulty in implementing the language. > > I do realize that function call notation can be a lot harder to read (and write) > than operator notation in a few situations. I've also been around that block more > times than one, in fact quite recently. > > I have many times mused over whether it would be possible to add something that > would give the most important benefits and not be a complete semantic train wreck. > Sometimes I think it could be done a lot better than we have seen, but at best, > it would be a significant semantic complication, even if restricted to operators > only. > > In Modula-3, we have a language whose most distinctive characteristic is an > exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other > language that comes close by this criterion. We need to preserve that. > > Rodney Bates > > > Jay K wrote: > > Is it really so difficult to add operator overloading to the language? > > > > From a user's point of view, I know it is very useful in certain > > situations. > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Nov 21 21:25:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Nov 2010 20:25:41 +0000 Subject: [M3devel] operator overloading? In-Reply-To: References: , , , <08B4C568-4EF9-40A5-9144-606D3A5CF1E0@cs.purdue.edu>, , , , <20101121192734.DB4761A208C@async.async.caltech.edu>, , , , Message-ID: > What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? I believe m3-libs/arithmetic/src/basictypes/biginteger. Though this arithmetic library is very large and I understand little of it. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Nov 2010 15:14:08 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] operator overloading? On Nov 21, 2010, at 3:11 PM, Jay K wrote:> I'm now starting to wish that we had left LONGINT out, Just now? :) (This is another reason I'm somewhat open to tediously using Target.Int in frontend, in case we do lose LONGINT.) What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already? > ARRAY [1..2] OF INTEGER .. same representation as C "long long" These are potentially much different, e.g. when being returned from a function by value. NT/x86 returns them in the register pair edx:eax. Granted, it *might* also store small structs that way, but I'm not sure. (you could bury the array in a struct then as well) But I guess a small special case would do. Why are sets in the language, with infix operators? Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls. If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue. Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc. I have done a *little* bit of Scheme programming, so I at least was at some point sympathetic to the view of having no infix operators whatsoever. The story of the Dylan programming language is also interesting. It was originally prefix only but caved and went infix for the sake of programmer convenience. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 21 Nov 2010 15:04:09 -0500 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] operator overloading? > > I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER. It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future. It would have had the advantage of leaving the core language untouched. > > On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote: > > > > > I don't like changes in Modula-3, on principle. I have a lot of code > > that is over ten years old and that I never look at, and I never want > > to look at, despite the fact that things that I do depend on computers > > that execute probably billions of instructions in this code every day. > > > > Now I depend on such code that depends on being able to parse > > Modula-3 itself, so the language, I feel should stay both forward- > > and backward-compatible. (I really don't like LONGINT for that > > reason.) > > > > But that being said, operator overloading seems relatively harmless. > > It changes the meaning only of executable code, not interfaces, and unless > > you are writing a compiler, there isn't much reason to be processing > > the executable code. This is all assuming you do it right. And there > > must be some way of calling the overloaded operators using functional > > notation so that generated code can get at them. > > > > What has always bugged me about operator overloading in C++ is just > > what an unabashed hack it is. You can use the operators from C, > > but no others? And they have to have the same associativity and > > commutativity rules as in C? And they can be only unary or binary? > > Does anyone do this better? Is it even possible? I suppose the main > > thing is to specify a rule for converting > > > > a OP b > > > > to > > > > OP(a,b)... > > > > What does C++ do? Make it a.OP(b)? The asymmetry is really ugly. And > > then the associativity rules... is addition left- or right-associative? > > Who remembers that..? now *that* is obscure. And it won't work on RECORDs > > or ARRAYs or SETs, which don't have methods... > > > > Would it be possible to write a pre-processor using m3tk that would > > implement the entirety of operator overloading? I think that would > > be an elegant solution, but I've never used m3tk on implementations... > > The reason I am saying this is that judging from the syntax equations > > in the Green Book, it is possible that m3tk might accept a program using > > overloaded operators, and only semantic analysis on the parsed structure > > would uncover the overloaded operators and flag them as semantic errors > > (in standard Modula-3). But I might be wrong. And m3tk might have > > broken code in it. > > > > When we were designing async. hardware with Modula-3 we had a thing > > called "m3texthack" that would let you do special kinds of macros in > > Modula-3 code. Your source file would be Module.c3, which would > > be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3 > > of course). > > > > In any case, an m3tk solution rather than a Modula-3 solution would easily > > allow you to specify different rules for different types, or even for > > different source files, rather than being tied to something nailed down > > in the language spec. > > > > Mika > > > > > > > > Jay K writes: > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> "Obscures the underlying code" is true of so many things. > >> Exceptions. Garbage collection. Objects. Nested functions. Function calls! = > >> Default parameters. Generics. Pickles. RPC. > >> It is a matter of degree=2C cost=2C value though=2C granted. > >> The runtime cost of operating overloading is zero=2C at least. > >> And the unobscured code is horrible to read and write actually (which is = > >> the reason for many features). > >> This is case where "obscure" is clearly good=2C and not obscure. > >> But it is a matter of degree. I should probably try implementing it befor= > >> e I ask for it too strongly. > >> > >> > >> - Jay > >> > >> From: hosking at cs.purdue.edu > >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] operator overloading? > >> > >> > >> > >> Some of us find operator overloading anathema because it obscures the actua= > >> l underlying code.It certainly does not fit well with the design philosophy= > >> of Modula-3. > >> > >> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to= > >> add operator overloading to the language? > >> > >>> From a user's point of view=2C I know it is very useful in certain situatio= > >> ns. > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >> > >> > >> "Obscures the underlying code" is true of so many things.
Exceptions. Ga= > >> rbage collection. Objects. Nested functions. Function calls! Default parame= > >> ters. Generics. Pickles. RPC.
It is a matter of degree=2C cost=2C value = > >> though=2C granted.
 =3B The runtime cost of operating overloading is= > >> zero=2C at least.
 =3B And the unobscured code is horrible to read = > >> and write actually (which is the reason for many features).
 =3B Thi= > >> s is case where "obscure" is clearly good=2C and not obscure.
 =3B B= > >> ut it is a matter of degree. I should probably try implementing it before I= > >> ask for it too strongly.


 =3B - Jay

>> elling">From: hosking at cs.purdue.edu
Date: Sun=2C 21 Nov 2010 13:33:31 -0= > >> 500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: R= > >> e: [M3devel] operator overloading?

> >> >> "> > >> Some of us find ope= > >> rator overloading anathema because it obscures the actual underlying code.<= > >> div>It certainly does not fit well with the design philosophy of Modula-3.<= > >> br>

On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:
= > >>
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic= > >> a=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 font-size: med= > >> ium=3B">
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l= > >> anguage?

From a user's point of view=2C I know it is very useful in = > >> certain situations.


 =3B- Jay




>> n>

> >> = > >> > >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Nov 21 21:56:56 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Nov 2010 14:56:56 -0600 Subject: [M3devel] operator overloading? In-Reply-To: References: , <4CE97868.3050804@lcwb.coop> Message-ID: <4CE98798.7060006@lcwb.coop> Jay K wrote: > Rodney, what if the signatures of overloaded operators is "fixed". > That is + can only take two T's and return one T. > < can only take two T's and return one boolean. > That is one of the ways that would greatly simplify the semantics. It would also make it more difficult for programmers to define operator meanings with no resemblance to traditional mathematical meanings of the operators, which I regard as really bad practice, but is encouraged by the overloading systems I know about. > > No implicit conversions. > (I do think some conversions are ok, integers to wider integers, but > nobody else agrees.) We already have something far better than implied conversions. We have assignability, which, simplified, says that in a lot of assignment-like contexts, what is needed is that the RHS _value_ must be a member of the LHS's _type_. The types are not necessarily disjoint, so there are lots of cases where this accomplishes something. Enforcing this requires a mix of static and runtime rules. Obviously, if the RHS type is disjoint with the LHS type, that is statically know to be illegal. When it's legally assignable, Modula-3 doesn't call it a type conversion. This is higher-level and more abstract. There may well be an implied _representation_ conversion, for example, different sizes of integers. Most (all?) other languages require that every different machine-level representation be a different type, and this creates a need for programmer-awareness of lots more type conversions, implicit or explicit, than the Modula-3 approach We didn't get assignability between INTEGER and LONGINT, but we have it between a base ordinal type and all its subranges and all their packed types (subject to value inclusion.) as well as several other cases. > Isn't that much simpler than any other language does it? I think it can be a lot simpler than any other language. There is still a _lot_ of unanticipated detail. > Are the rules still hard to understand? > (And I believe this is still fairly valuable.) > > > Furthermore, something like, maybe, the operators may only be defined in > the interface that declares T? > Or maybe, the operators are always available on all types, but you get a > link error if they weren't defined? > I can think of another visibility rule, but it derives from other things I would have to describe first. > > And of course, you can't define them for builtin types. They are already > defined. > Yes, I would strongly support that rule. (Did you know Ada does not?) > > And, I realize, there is a question of errors. > + can fail. > The interface would have to that they raise exceptions. > You could have something like FPU.i3 custom per type to control it. The > compiler > wouldn't know about this (except maybe for builtin LONGINT). > I think exception raising can be kept orthogonal to operator overloading by defining an operator expression (once resolved to a single function) as equivalent to an ordinary call. In fact, everything except determining what function is to be called can be defined by an equivalence to an ordinary call of that function. > > - Jay > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] operator overloading? > > > > I've been around that block too many times with Ada and C++. Programmer- > > defined overloading (either operator and/or function name) is a semantic > > disaster. It interacts with stuff all over the language, and the > complexity > > just explodes. I have spent several years of my life having to learn > every > > in and out and dark corner of overloading and all its fallout in Ada, > both > > to implement it and to try to help working programmers cope with it. > I can > > say with complete confidence that Ada would be half the size/complexity > > it is, without it. > > > > Moreover, hard as it is for a compiler writer or language lawyer to > understand > > it, it is even worse for the everyday programmer. Again, I can > testify that > > almost nobody (the above types excepted) comes anywhere close to > understanding > > the rules. They don't even want to try. Their eyes glaze over, and > they just > > want you to tell them how to code such-and-such so it will compile > and call > > the function they want it to. For the future, all they want is > restrictive > > but simple programming guidelines on things to avoid unconditionally, > so they > > won't keep getting burned again and again. > > > > C++'s take on overloading is simpler in some respects, more > complicated in > > others, but overall, quite a bit worse and, I dare say, much > poorer-understood > > by working programmers. > > > > The upshot is that the (mis)feature of programmer-defined overloading > is mostly > > used only in degenerate and trivial ways. This, of course, raises the > question > > what good is it when: 1) it makes programming more difficult, 2) > programmers > > avoid most of it anyway, and 3) even so, it results in lots of code that > > programmers just barely hope they understand the meaning of what they > wrote. > > The latter is a *very* big deal in quality of released code. And I > didn't even > > mention the added difficulty in implementing the language. > > > > I do realize that function call notation can be a lot harder to read > (and write) > > than operator notation in a few situations. I've also been around > that block more > > times than one, in fact quite recently. > > > > I have many times mused over whether it would be possible to add > something that > > would give the most important benefits and not be a complete semantic > train wreck. > > Sometimes I think it could be done a lot better than we have seen, > but at best, > > it would be a significant semantic complication, even if restricted > to operators > > only. > > > > In Modula-3, we have a language whose most distinctive characteristic > is an > > exceptionally high ratio of useful stuff to complexity. AFAIK, there > is no other > > language that comes close by this criterion. We need to preserve that. > > > > Rodney Bates > > > > > > Jay K wrote: > > > Is it really so difficult to add operator overloading to the language? > > > > > > From a user's point of view, I know it is very useful in certain > > > situations. > > > > > > > > > - Jay > > > > > > > > > > > > From dabenavidesd at yahoo.es Mon Nov 22 04:04:23 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 22 Nov 2010 03:04:23 +0000 (GMT) Subject: [M3devel] operator overloading? In-Reply-To: <4CE98798.7060006@lcwb.coop> Message-ID: <16723.97158.qm@web29716.mail.ird.yahoo.com> Hi all: perhaps in behalf of this issue, one remembers the rules for the type inference algorithms are of variable complexity depending on the semantics or what one calls meaning but also syntaic aids, not like syntatic sugared language constructs but syntax directed checking, and if you want to look an example please look at javascript type inference vs Obliq Modula-3 runtime type inference (which uses m3tk lib by the way), it tourns out that the semantics (object oriented dynamically typed based languages) are quite different in terms of type checking, i.e given Obliq algorithm may checks up to in O[n^5] order but could be less according to certain conditions but in terms of the javascript kernel considered in an research work is not that quick by now, but remains in general as an open issue, perhaps waiting for someone who gets a Turing Award for it ( see http://jiangxi.cs.uwm.edu/publication/js.pdf ) Please consider no just simplicity of our thoughts but of our algorithms, specially when someone has code that already dependends on parsing Modula-3 statements all the day long by many millions of instruction per second. Thanks in advance --- El dom, 21/11/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] operator overloading? > Para: "m3devel" > Fecha: domingo, 21 de noviembre, 2010 15:56 > > > Jay K wrote: > > Rodney, what if the signatures of overloaded operators > is "fixed". > > That is + can only take two T's and return one T. > > < can only take two T's and return one boolean. > > > > That is one of the ways that would greatly simplify the > semantics. > It would also make it more difficult for programmers to > define > operator meanings with no resemblance to traditional > mathematical > meanings of the operators, which I regard as really bad > practice, > but is encouraged by the overloading systems I know about. > > > > > No implicit conversions. > > (I do think some conversions are ok, > integers to wider integers, but nobody else agrees.) > > We already have something far better than implied > conversions. We have > assignability, which, simplified, says that in a lot of > assignment-like > contexts, what is needed is that the RHS _value_ must be a > member of the > LHS's _type_. The types are not necessarily disjoint, > so there are lots > of cases where this accomplishes something. Enforcing > this requires a > mix of static and runtime rules. Obviously, if the > RHS type is disjoint > with the LHS type, that is statically know to be illegal. > > When it's legally assignable, Modula-3 doesn't call it a > type conversion. > This is higher-level and more abstract. There may > well be an implied > _representation_ conversion, for example, different sizes > of integers. > Most (all?) other languages require that every different > machine-level > representation be a different type, and this creates a need > for > programmer-awareness of lots more type conversions, > implicit or explicit, > than the Modula-3 approach > > We didn't get assignability between INTEGER and LONGINT, > but we have > it between a base ordinal type and all its subranges and > all their > packed types (subject to value inclusion.) as well as > several other > cases. > > > Isn't that much simpler than any other language does > it? > > I think it can be a lot simpler than any other > language. There is > still a _lot_ of unanticipated detail. > > > Are the rules still hard to understand? > > (And I believe this is still fairly > valuable.) > > > > > > Furthermore, something like, maybe, the operators may > only be defined in the interface that declares T? > > Or maybe, the operators are always available on all > types, but you get a link error if they weren't defined? > > > > I can think of another visibility rule, but it derives from > other things > I would have to describe first. > > > > > And of course, you can't define them for builtin > types. They are already defined. > > > > Yes, I would strongly support that rule. (Did you > know Ada does not?) > > > > > And, I realize, there is a question of errors. > > + can fail. > > The interface would have to that they raise > exceptions. > > You could have something like FPU.i3 custom per type > to control it. The compiler > > wouldn't know about this (except maybe for builtin > LONGINT). > > > > I think exception raising can be kept orthogonal to > operator overloading by > defining an operator expression (once resolved to a single > function) as > equivalent to an ordinary call. In fact, everything > except determining > what function is to be called can be defined by an > equivalence to an > ordinary call of that function. > > > > > - Jay > > > > > > > Date: Sun, 21 Nov 2010 13:52:08 -0600 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] operator > overloading? > > > > > > I've been around that block too many times > with Ada and C++. Programmer- > > > defined overloading (either operator and/or > function name) is a semantic > > > disaster. It interacts with stuff all over > the language, and the complexity > > > just explodes. I have spent several years > of my life having to learn every > > > in and out and dark corner of overloading > and all its fallout in Ada, both > > > to implement it and to try to help working > programmers cope with it. I can > > > say with complete confidence that Ada would > be half the size/complexity > > > it is, without it. > > > > > > Moreover, hard as it is for a compiler > writer or language lawyer to understand > > > it, it is even worse for the everyday > programmer. Again, I can testify that > > > almost nobody (the above types excepted) > comes anywhere close to understanding > > > the rules. They don't even want to try. > Their eyes glaze over, and they just > > > want you to tell them how to code > such-and-such so it will compile and call > > > the function they want it to. For the > future, all they want is restrictive > > > but simple programming guidelines on things > to avoid unconditionally, so they > > > won't keep getting burned again and again. > > > > > > C++'s take on overloading is simpler in > some respects, more complicated in > > > others, but overall, quite a bit worse and, > I dare say, much poorer-understood > > > by working programmers. > > > > > > The upshot is that the (mis)feature of > programmer-defined overloading is mostly > > > used only in degenerate and trivial ways. > This, of course, raises the question > > > what good is it when: 1) it makes > programming more difficult, 2) programmers > > > avoid most of it anyway, and 3) even so, it > results in lots of code that > > > programmers just barely hope they > understand the meaning of what they wrote. > > > The latter is a *very* big deal in quality > of released code. And I didn't even > > > mention the added difficulty in > implementing the language. > > > > > > I do realize that function call notation > can be a lot harder to read (and write) > > > than operator notation in a few situations. > I've also been around that block more > > > times than one, in fact quite recently. > > > > > > I have many times mused over whether it > would be possible to add something that > > > would give the most important benefits and > not be a complete semantic train wreck. > > > Sometimes I think it could be done a lot > better than we have seen, but at best, > > > it would be a significant semantic > complication, even if restricted to operators > > > only. > > > > > > In Modula-3, we have a language whose most > distinctive characteristic is an > > > exceptionally high ratio of useful stuff to > complexity. AFAIK, there is no other > > > language that comes close by this > criterion. We need to preserve that. > > > > > > Rodney Bates > > > > > > > > > Jay K wrote: > > > > Is it really so difficult to add > operator overloading to the language? > > > > > > > > From a user's point of view, I know it > is very useful in certain > > > > situations. > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > From wagner at elegosoft.com Mon Nov 22 07:56:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Nov 2010 07:56:31 +0100 Subject: [M3devel] latest regressions Message-ID: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> out of memory on FreeBSD4: cc1plus: out of memory allocating 235058936 bytes gmake: *** [insn-recog.o] Error 1 "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console m3cc compilation failure on PPC_DARWIN: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console 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 Nov 22 08:20:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: [M3devel] latest regressions In-Reply-To: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com> Message-ID: Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 08:28:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 07:28:16 +0000 Subject: [M3devel] latest regressions In-Reply-To: References: <20101122075631.qlhv4w9usk0wkko0@mail.elegosoft.com>, Message-ID: I'll see if PPC_DARWIN error can be reproduced building a cross compiler. It should be. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 22 Nov 2010 07:20:32 +0000 Subject: Re: [M3devel] latest regressions Blech. I'll try ulimit -d unlimited in *.sh. As well I can turn off the checking on some targets. That is what probably uses more memory. - Jay > Date: Mon, 22 Nov 2010 07:56:31 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] latest regressions > > out of memory on FreeBSD4: > > cc1plus: out of memory allocating 235058936 bytes > gmake: *** [insn-recog.o] Error 1 > "/pub/users/hudson/workspace/cm3-current-build-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 276: quake runtime error: exit 2: cd . && cd gcc && gmake MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg > > http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/136/console > > m3cc compilation failure on PPC_DARWIN: > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/177/console > > 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: From jay.krell at cornell.edu Mon Nov 22 21:25:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Nov 2010 20:25:54 +0000 Subject: [M3devel] I386_DARWIN Message-ID: I386_DARWIN is still broken http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/84/console but probably just needs to restart with a known good cm3cg, I'll get to that later. (I'm hoping that the update of cm3/cm3cg in the "middle" of upgrade.sh doesn't go into last-ok/current until the end of the task, in case of a mistake.) - Jay From jay.krell at cornell.edu Tue Nov 23 01:23:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 00:23:03 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. I think. Right? So here it could do that just as well. Right? - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Fri, 19 Nov 2010 09:43:03 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > declare_segment doesn't have the size because it is unknown at the time > of the declaration, which comes before the module is compiled. > Only as the module is compiled does the size become known, with > Bind_segment emitted at the end. > > > On Nov 19, 2010, at 5:01 AM, Jay K wrote: > > I'm not looking at m3front. I should. > > Why does declare_segment not have the size? > > I'm going to just live with whatever the frontend does for now. > Make an extra pass to find the bind_segments, so that when > I do things "for real", declare_segment can set the size correctly. > > Later I'll do better -- making the segment contain fields. > So that globals become debuggable, in stock gdb (as big records). > > But first I want configure enable-checking to work. > (with one exception, the static link stuff..) > > - Jay > > > > > From hosking at cs.purdue.edu Tue Nov 23 02:17:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 20:17:54 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu> Message-ID: It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > I think. Right? > So here it could do that just as well. Right? > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Fri, 19 Nov 2010 09:43:03 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> declare_segment doesn't have the size because it is unknown at the time >> of the declaration, which comes before the module is compiled. >> Only as the module is compiled does the size become known, with >> Bind_segment emitted at the end. >> >> >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >> >> I'm not looking at m3front. I should. >> >> Why does declare_segment not have the size? >> >> I'm going to just live with whatever the frontend does for now. >> Make an extra pass to find the bind_segments, so that when >> I do things "for real", declare_segment can set the size correctly. >> >> Later I'll do better -- making the segment contain fields. >> So that globals become debuggable, in stock gdb (as big records). >> >> But first I want configure enable-checking to work. >> (with one exception, the static link stuff..) >> >> - Jay >> >> >> >> >> From jay.krell at cornell.edu Tue Nov 23 02:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 01:51:11 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. And, it could be "fixed" by adding an additional pass? And, you didn't say this, we very well could/should, if all the backends needed it? Or if it was cheap enough? You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. Or at least in the backend that could easily benefit from it. But actually there's probably another way. I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 20:17:54 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bind_segment vs. declare_segment? > > It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > > Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > > > > > Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > > I think. Right? > > So here it could do that just as well. Right? > > > > - Jay > > > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> declare_segment doesn't have the size because it is unknown at the time > >> of the declaration, which comes before the module is compiled. > >> Only as the module is compiled does the size become known, with > >> Bind_segment emitted at the end. > >> > >> > >> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >> > >> I'm not looking at m3front. I should. > >> > >> Why does declare_segment not have the size? > >> > >> I'm going to just live with whatever the frontend does for now. > >> Make an extra pass to find the bind_segments, so that when > >> I do things "for real", declare_segment can set the size correctly. > >> > >> Later I'll do better -- making the segment contain fields. > >> So that globals become debuggable, in stock gdb (as big records). > >> > >> But first I want configure enable-checking to work. > >> (with one exception, the static link stuff..) > >> > >> - Jay > >> > >> > >> > >> > >> > From hosking at cs.purdue.edu Tue Nov 23 03:59:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Nov 2010 21:59:29 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , Message-ID: On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > And, it could be "fixed" by adding an additional pass? No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > And, you didn't say this, we very well could/should, if all the backends needed it? > Or if it was cheap enough? > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > Or at least in the backend that could easily benefit from it. > But actually there's probably another way. > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). Yes, I think that would be better. > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 20:17:54 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >> >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >> >>> >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>> I think. Right? >>> So here it could do that just as well. Right? >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> declare_segment doesn't have the size because it is unknown at the time >>>> of the declaration, which comes before the module is compiled. >>>> Only as the module is compiled does the size become known, with >>>> Bind_segment emitted at the end. >>>> >>>> >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>> >>>> I'm not looking at m3front. I should. >>>> >>>> Why does declare_segment not have the size? >>>> >>>> I'm going to just live with whatever the frontend does for now. >>>> Make an extra pass to find the bind_segments, so that when >>>> I do things "for real", declare_segment can set the size correctly. >>>> >>>> Later I'll do better -- making the segment contain fields. >>>> So that globals become debuggable, in stock gdb (as big records). >>>> >>>> But first I want configure enable-checking to work. >>>> (with one exception, the static link stuff..) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> >> From jay.krell at cornell.edu Tue Nov 23 04:59:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 03:59:23 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: > It's inevitable that we have types referenced before defined because of recursion in the type definitions. "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. Er, but you said reference before defined, not referenced before forward declared. Is it inevitable, say, to have a pointer to a record before declaring that the record exists? Seems unlikely. Is there really recursion, or just..some graph? Again something the frontend maybe could resolve but doesn't? Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) A point here is, really, I'm still trying to get the better-typed trees. Even though I went out on a tangent getting configure -enable-checking to work. -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. - Jay ---------------------------------------- > Subject: Re: [M3devel] bind_segment vs. declare_segment? > From: hosking at cs.purdue.edu > Date: Mon, 22 Nov 2010 21:59:29 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On Nov 22, 2010, at 8:51 PM, Jay K wrote: > > > > > Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. > > And, it could be "fixed" by adding an additional pass? > > No, it wouldn't make sense to do that. Better to defer the type until it is *known*. > > > And, you didn't say this, we very well could/should, if all the backends needed it? > > Or if it was cheap enough? > > > > > > > > You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. > > Or at least in the backend that could easily benefit from it. > > But actually there's probably another way. > > I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). > > Yes, I think that would be better. > > > I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. > > (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 22 Nov 2010 20:17:54 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >> > >> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. > >> > >> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: > >> > >>> > >>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. > >>> I think. Right? > >>> So here it could do that just as well. Right? > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? > >>>> > >>>> declare_segment doesn't have the size because it is unknown at the time > >>>> of the declaration, which comes before the module is compiled. > >>>> Only as the module is compiled does the size become known, with > >>>> Bind_segment emitted at the end. > >>>> > >>>> > >>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: > >>>> > >>>> I'm not looking at m3front. I should. > >>>> > >>>> Why does declare_segment not have the size? > >>>> > >>>> I'm going to just live with whatever the frontend does for now. > >>>> Make an extra pass to find the bind_segments, so that when > >>>> I do things "for real", declare_segment can set the size correctly. > >>>> > >>>> Later I'll do better -- making the segment contain fields. > >>>> So that globals become debuggable, in stock gdb (as big records). > >>>> > >>>> But first I want configure enable-checking to work. > >>>> (with one exception, the static link stuff..) > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> > >>>> > >> > From jay.krell at cornell.edu Tue Nov 23 08:26:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:26:30 +0000 Subject: [M3devel] configure -enable-checking Message-ID: The ridiculous cross product tests I put in p240 actually do cover stuff not covered anywhere else in the tree, seemingly. ../AMD64_DARWIN/Divide.m3: In function 'Divide__Divide_var_C_C': ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5567 = D.5565 /[ex] D.5566; ../AMD64_DARWIN/Divide.m3:634:0: error: type mismatch in binary expression int_64 word_64 word_64 D.5573 = D.5571 /[ex] D.5572; ../AMD64_DARWIN/Divide.m3:634:0: internal compiler error: verify_stmts failed jbook2:p240 jay$ wc -l AMD64_DARWIN/*.m3 46913 total :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 08:57:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 07:57:56 +0000 Subject: [M3devel] cardinal vs. word, divide? Message-ID: So, here are two maybe interesting cases. At least to jog my brain and help make sense of the system. DIV vs. Word.Divide of CARDINAL. u is for unsigned, or word C is for Cardinal. Cardinal is [0..LAST(INTEGER)]. <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 (5582) div type:int_64 (5583) check_lo type:int_64 0 code:1 (5584) exit_proc type:word_64 (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 (5574) div type:word_64 (5575) exit_proc type:int_64 (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C Thoughts? Is it right for the load to convert from word to int? (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) I can see how makes sense. CARDINAL is just a subrange of INTEGER. So it is INTEGER. If/when we are clever, we can represent the subranges in the types in the backend, and the optimizer should notice, and these would generate identical code, if they don't already. But the return types of the divides vary as well. There do exist unsigned types at this level. Does that imply that a,b:CARDINAL Word.Or(a, 0) DIV Word.Or(b, 0) is different than a DIV b? I guess so. Different code at least. Given that cardinal is "half range", the results should always match. That is, really, other than added/missing range checks, CARDINAL will always act the same as INTEGER. So then the unsigned types..don't mean anything? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 09:33:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 08:33:00 +0000 Subject: [M3devel] bit field operations for insert/extract Message-ID: Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 11:44:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 10:44:01 +0000 Subject: [M3devel] optimizer vs. gc? Message-ID: so.."the literate" (actually posts to usenet by people who worked on Modula-3 compilers!) warns about the following sort of thing: void F1(char* a, char* b) { int c; for (c = 10; c < 20; ++c) { a[c] = b[c]; } } getting transformed into something like: void F1(char* a, char* b) { int c; a += 10; b += 10; for (c = 0; c < 10; ++c) { a[c] = a[c]; } } actually it warns about something trickier, but this is the best I can come up with that I understand, off the top of my head. => "interior pointers" => "no gc roots in registers or on stack" Should we be concerned? Does our GC handle this? Should we, like, mark all stores volatile but not all loads? And maybe all parameters??? And maybe copy them into non-volatile locals? The trickier warning is something where the difference of the array bases is what is in registers, not merely an interior pointer. I searched a while but couldn't find it. It is probably by David Chase. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:28:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:28:12 -0500 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <8570A188-D9CF-4AF3-AAF1-B6A1459F6495@cs.purdue.edu> I'd have to think a bit more about this. I'm still not sure what the issue is for you in the back end. On Nov 22, 2010, at 10:59 PM, Jay K wrote: > >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From hosking at cs.purdue.edu Tue Nov 23 15:35:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:35:05 -0500 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <72D18BD8-B615-4269-98F2-82CC25A05ECA@cs.purdue.edu> Word.Or(a, 0) always has type Word.T, which is currently defined to be INTEGER. Word.Divide takes two Word.T, treats them as unsigned, and performs unsigned division on them, returning the bits as Word.T. DIV takes two INTEGERs and performs signed division on them. What was the question again? On Nov 23, 2010, at 2:57 AM, Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:37:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:37:00 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: Message-ID: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote: > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 15:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 09:46:41 -0500 Subject: [M3devel] optimizer vs. gc? In-Reply-To: References: Message-ID: I assume you are referring to: @article{boeh92, author = "Hans-Juergen Boehm and David R. Chase", title = "A Proposal for Garbage-Collector-Safe {C} Compilation", journal = "Journal of C Language Translation", mon = dec, year = 1992, pages = "126--141", URL = {http://reality.sgi.com/employees/boehm_mti/papers/boecha.ps.gz} } So long as the stacks have a pointer to anywhere on the heap page on which the object lies then it will not get reclaimed by our collector. I'd be surprised if gcc performs optimizations that break our collector. On Nov 23, 2010, at 5:44 AM, Jay K wrote: > so.."the literate" (actually posts to usenet > by people who worked on Modula-3 compilers!) > warns about the following sort of thing: > > void F1(char* a, char* b) > { > int c; > for (c = 10; c < 20; ++c) > { > a[c] = b[c]; > } > } > > getting transformed into something like: > > void F1(char* a, char* b) > { > int c; > a += 10; > b += 10; > for (c = 0; c < 10; ++c) > { > a[c] = a[c]; > } > } > > > actually it warns about something trickier, but this > is the best I can come up with that I understand, > off the top of my head. > > > => "interior pointers" > => "no gc roots in registers or on stack" > > > Should we be concerned? > Does our GC handle this? > > > Should we, like, mark all stores volatile but not all loads? > And maybe all parameters??? > And maybe copy them into non-volatile locals? > > The trickier warning is something where > the difference of the array bases is what is in registers, not merely an interior pointer. > I searched a while but couldn't find it. > It is probably by David Chase. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Nov 23 17:52:37 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 10:52:37 -0600 Subject: [M3devel] cardinal vs. word, divide? In-Reply-To: References: Message-ID: <4CEBF155.3050703@lcwb.coop> Jay K wrote: > So, here are two maybe interesting cases. > At least to jog my brain and help make sense of the system. > > > DIV vs. Word.Divide of CARDINAL. > u is for unsigned, or word > C is for Cardinal. > Cardinal is [0..LAST(INTEGER)]. > > > <*NOWARN*>PROCEDURE > uDivide_param_C_C(a:CARDINAL;b:CARDINAL):Word.T=BEGIN RETURN > Word.Divide(a,b);END uDivide_param_C_C; > > <*NOWARN*>PROCEDURE > Divide_param_C_C(a:CARDINAL;b:CARDINAL):CARDINAL=BEGIN RETURN a DIV > b;END Divide_param_C_C; > > > (5579) begin_procedure procedure:0x178:Divide__Divide_param_C_C > Divide__Divide_param_C_C > (5580) load var:0x2E5:a offset:0 src_t:word_64 dst_t:int_64 > (5581) load var:0x2E6:b offset:0 src_t:word_64 dst_t:int_64 > (5582) div type:int_64 > (5583) check_lo type:int_64 0 code:1 > (5584) exit_proc type:word_64 > (5585) end_procedure procedure:0x178:Divide__Divide_param_C_C > > > (5571) begin_procedure procedure:0x177:Divide__uDivide_param_C_C > Divide__uDivide_param_C_C > (5572) load var:0x2E2:a offset:0 src_t:word_64 dst_t:int_64 > (5573) load var:0x2E3:b offset:0 src_t:word_64 dst_t:int_64 > (5574) div type:word_64 > (5575) exit_proc type:int_64 > (5576) end_procedure procedure:0x177:Divide__uDivide_param_C_C > > > Thoughts? > > > Is it right for the load to convert from word to int? > (I'll see about removing the address_token for unsigned/signed-only > conversions, if it is there.) > > > I can see how makes sense. > CARDINAL is just a subrange of INTEGER. So it is INTEGER. > > > If/when we are clever, we can represent the subranges in the types > in the backend, and the optimizer should notice, and these > would generate identical code, if they don't already. > > > But the return types of the divides vary as well. > There do exist unsigned types at this level. > > > Does that imply that > a,b:CARDINAL > > Word.Or(a, 0) DIV Word.Or(b, 0) > is different than > a DIV b? > > > I guess so. Different code at least. Same result value, for all a,b. The code should only differ if the compiler does not optimize away the noop Word.Or operations. At the language semantics level, applying a builtin operator like DIV or Word.Or to a subrange (CARDINAL) is like passing the subrange value to a procedure that takes an INTEGER formal parameter of VALUE mode. The actual must be 'assignable' to the formal, which is the case in all these examples, without runtime checks. There could be a representation change generated by the compiler (this is _not_ an implied type conversion), though that doesn't happen here, since surely CARDINAL will always be represented the same as INTEGER. If a were, say, [-128..127] or smaller, the compiler might well have represented/stored it in a (signed) byte, and would then have to do a representation conversion by expanding and sign-extending into a full word before applying the operator to it. > Given that cardinal is "half range", the results should always match. > That is, really, other than added/missing range checks, CARDINAL > will always act the same as INTEGER. > So then the unsigned types..don't mean anything? > I'd say yes, except when attached to the div operator. Most languages have different types for signed and unsigned. Then the same operator, applied to the different types does different things. These are (language-defined) overloaded operators. In the case of signed vs. unsigned, Modula-3 turns it around. There is only one type INTEGER=Word.T. Instead, there are different operators for the signed/unsigned operations: DIV vs. Word.Divide. They just apply different interpretations to the same bits. From these examples and some brief looks at M3x83.m3, it looks like the M3 backend system is designed to reflect the more common source language system of different types, with the front end having propagated a copy of the operand type to the operator too. I don't know how the gcc tree system works, but I'd bet it too uses different types. The way that I would match the Modula-3 semantics to the gcc system would be to keep everything in a signed type, except when an unsigned operator comes along. Then convert to unsigned, apply the unsigned operator, and convert back to signed. The conversions used would have to be LOOPHOLE-like in just reinterpreting the bits without changing them. No sign-check going to unsigned and no sign-extension coming back. So the only reason to need conversions at all is if gcc matches types of operands to types of operators and chokes on mismatch. I can see why the div operator needs separate types word_64 or int_64 attached to distinguish which operation is to be done. I can't see why the operand types need such a distinction at all, why the type is changed in the load, or why the source and destination types are what they are. The distinction might not actually mean much on the operands. > > - Jay > > > > From rodney_bates at lcwb.coop Tue Nov 23 18:21:04 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Nov 2010 11:21:04 -0600 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: References: , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , Message-ID: <4CEBF800.7050401@lcwb.coop> Jay K wrote: > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. > > > "Good". I mean, er, this is sort of what I thought, and sort of what the multi-pass in parse.c infrastructure is for. > Er, but you said reference before defined, not referenced before forward declared. > > > Is it inevitable, say, to have a pointer to a record before declaring that the record exists? > Seems unlikely. > It is inevitable that many programs will need to have types that refer to each other in recursive fashion. Just a simple linked list node needs a link pointer. The pointer's definition refers to the node's and vice-versa. with more than one node type, and links among them, it gets more complicated. Something has to come first, and it has to have a forward reference to something that comes later. There are various systems in various languages to support this. Most languages allow some way of splitting a type definition into two parts. One gives only partial information about the type, not enough to need the reference to the other type in the cycle. This could be the "declaring that the record exists" you mention. The other type can be declared next, referring to the incomplete type in some limited ways. Then the completion of the first type comes last. For example, it is usually possible to define a pointer to an incompletely-defined type. And this works OK for a compiler, which really only needs to know its size at this point, and all pointers are the same size. So we only need to know the referent is a type, but not what type, to define a pointer to it. Modula-3 is unusual in saying that all declarations in a single scope are made simultaneously. This is rather abstract talk for saying one declaration can make a forward reference to another declaration in the same scope. (Note that this changes the way redeclaring an identifier in an inner scope works.) Then there are separate rules limiting what kinds of recursion are legal in declarations. For example, records R1 and R2 can contain pointers to each other, but not imbedded instances of each other. (That would have infinite size.) A compiler can handle this in two passes, one to collect all the identifiers declared in the scope (and probably as much information about them as does not depend on any other referred-to declaration.) The second can then check the recursion rules and complete all attributes of the declared entities. > > Is there really recursion, or just..some graph? > > > Again something the frontend maybe could resolve but doesn't? > > > Basically, the question is, and you don't really have to answer it, I can figure it out, but does the backend need multiple passes to describe the types well? I thought I saw evidence of "yes", but I could be wrong. And it is probably fixable in the frontend if so. And then..the follow up question, depending on the various answers, is if you prefer to fix it in frontend or backend (not being sure yet there is a problem.....) > > > A point here is, really, I'm still trying to get the better-typed trees. > Even though I went out on a tangent getting configure -enable-checking to work. > -enable-checking still is a bit broken (static link) but maybe good enough for now, good enough to return to the type work. > > > - Jay > > > > > > ---------------------------------------- >> Subject: Re: [M3devel] bind_segment vs. declare_segment? >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Nov 2010 21:59:29 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> On Nov 22, 2010, at 8:51 PM, Jay K wrote: >> >>> Are you saying, like, the frontend has n passes, and one of them is codegen, and both of these actions happen within codegen. >>> And, it could be "fixed" by adding an additional pass? >> No, it wouldn't make sense to do that. Better to defer the type until it is *known*. >> >>> And, you didn't say this, we very well could/should, if all the backends needed it? >>> Or if it was cheap enough? >>> >>> >>> >>> You know, effectively, I've added the extra pass anyway, in the backend that "needs" it. >>> Or at least in the backend that could easily benefit from it. >>> But actually there's probably another way. >>> I could probably still do it one pass, just be sure to remember the type in declare and fill it in more in bind (instead of replacing it, after it has been used). >> Yes, I think that would be better. >> >>> I think I'll try that. I'm not going to throw out the multi-pass ability, and I think it will have other better motivated uses, but this one might not really be needed. >>> (Though it might yet be the multi-pass isn't needed. I thought I saw types referenced before defined. I'm pretty sure. It could be that the frontend could address that easily, or that it doesn't actually happen. Anyway, we'll see. >> It's inevitable that we have types referenced before defined because of recursion in the type definitions. >> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 22 Nov 2010 20:17:54 -0500 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>> >>>> It doesn't do multiple passes at code generation time. It simply declares the segment at beginning of code generation, and once it is done binds the size of the segment. >>>> >>>> Antony Hosking | Associate 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 Nov 22, 2010, at 7:23 PM, Jay K wrote: >>>> >>>>> Tony, What surprises me a bit here is that the frontend already makes multiple passes over everything. >>>>> I think. Right? >>>>> So here it could do that just as well. Right? >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Fri, 19 Nov 2010 09:43:03 -0500 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] bind_segment vs. declare_segment? >>>>>> >>>>>> declare_segment doesn't have the size because it is unknown at the time >>>>>> of the declaration, which comes before the module is compiled. >>>>>> Only as the module is compiled does the size become known, with >>>>>> Bind_segment emitted at the end. >>>>>> >>>>>> >>>>>> On Nov 19, 2010, at 5:01 AM, Jay K wrote: >>>>>> >>>>>> I'm not looking at m3front. I should. >>>>>> >>>>>> Why does declare_segment not have the size? >>>>>> >>>>>> I'm going to just live with whatever the frontend does for now. >>>>>> Make an extra pass to find the bind_segments, so that when >>>>>> I do things "for real", declare_segment can set the size correctly. >>>>>> >>>>>> Later I'll do better -- making the segment contain fields. >>>>>> So that globals become debuggable, in stock gdb (as big records). >>>>>> >>>>>> But first I want configure enable-checking to work. >>>>>> (with one exception, the static link stuff..) >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> From jay.krell at cornell.edu Tue Nov 23 19:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 18:46:06 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. The change would be to remove those. - Jay Subject: Re: [M3devel] bit field operations for insert/extract From: hosking at cs.purdue.edu Date: Tue, 23 Nov 2010 09:37:00 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Refresh my memory. What m3front change did you make? On Nov 23, 2010, at 3:33 AM, Jay K wrote:Tony, I'm going to try again to use bitfield operations for extract_mn. And insert_mn. I think I know what went wrong before for extract_mn: just remove the endian check in m3front. But I'm going to be sure test p240 covers it well. The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. Insert_mn is less obvious. I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. I guess it's more like, that, but with a temp that starts with the full value of x: create temp modify(temp, x) modify(bitfield_ref(temp, count, offset), y); m3_load(temp) ? I'll try something like that. It seems unfortunate. Maybe we can know if x is already a value and not a variable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 20:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 19:51:57 +0000 Subject: [M3devel] bind_segment vs. declare_segment? In-Reply-To: <4CEBF800.7050401@lcwb.coop> References: , , , <7501130E-7DA5-4B41-ADB9-BBAF3083721A@cs.purdue.edu>, , , , , , , , <4CEBF800.7050401@lcwb.coop> Message-ID: > > > It's inevitable that we have types referenced before defined because of recursion in the type definitions. As long as it is a pointer, I think that is easy and I understand. But granted, I think it is messed up in m3 today. I think m3front always says: record with n fields immediately followed by n fields And there is no forward declaration mechanism. We could probably use forward declare record That just gives the typeid. I have to look in more detail. I'm just speaking from memory here, and not all of the details have ever been, let alone remain, in my memory. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Nov 23 22:34:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 16:34:25 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> Message-ID: Are they wrong? Seems strange that they worked previously! On Nov 23, 2010, at 1:46 PM, Jay K wrote: > None yet. But notice the endian checks around the insert_mn or extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 23 22:46:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 21:46:02 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: Let me clarify. Remember when you used bit field operations for extract_mn? And they didn't work on any big endian system? And I had to undo it? With your approval. I believe the way to go: the change you did in parse.c; it was correct, highly likely removing those endian checks in m3front, which you didn't do at the time Removing the endian checks will only affect big endian. The code reads something like: if little_endian extract_mn(offset, count) else extract_mn(size - offset, size - count) So just change it to: extract_mn(offset, count) And I strongly suspect it will affect it "in the right way". But I'm going to try diffing assembly before/after to be sure. And then watch the sparc and ppc hudson builds. :) (and fix PPC_DARWIN beforehand as well) This is perhaps an interface change in m3cg, but there are no other big endian backends and there are no other uses of extract_mn in the frontend, I think. i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. Anyway, still speculation at this point. But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; perhaps it is best to just leave everything asis...?) and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) - Jay ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 16:34:25 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Are they wrong? Seems strange that they worked previously! > > On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > None yet. But notice the endian checks around the insert_mn or > extract_mn uses in cg.m3. > The change would be to remove those. > > - Jay > > > ________________________________ > Subject: Re: [M3devel] bit field operations for insert/extract > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 09:37:00 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Refresh my memory. What m3front change did you make? > > > On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > Tony, I'm going to try again to use bitfield operations for extract_mn. > And insert_mn. > I think I know what went wrong before for extract_mn: just remove the > endian check in m3front. > But I'm going to be sure test p240 covers it well. > > The easy part, duh, your original extract_mn was correct I think, just, > again, missing the m3front change. > > Insert_mn is less obvious. > I started writing it... bitfield_ref..modify_expr...uh, seems > suspicious, to be modifying an existing value. > > I guess it's more like, that, but with a temp that starts with the full > value of x: > create temp > modify(temp, x) > modify(bitfield_ref(temp, count, offset), y); > m3_load(temp) > > ? > > I'll try something like that. > It seems unfortunate. > Maybe we can know if x is already a value and not a variable? > > > - Jay > > > From hosking at cs.purdue.edu Tue Nov 23 23:46:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Nov 2010 17:46:06 -0500 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu> , Message-ID: If that's the case then I would argue for adjusting the offset accordingly in parse.c. extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > Let me clarify. > Remember when you used bit field operations for extract_mn? > And they didn't work on any big endian system? > And I had to undo it? With your approval. > > > I believe the way to go: > the change you did in parse.c; it was correct, highly likely > removing those endian checks in m3front, which you didn't do at the time > > > Removing the endian checks will only affect big endian. > The code reads something like: > if little_endian extract_mn(offset, count) > else extract_mn(size - offset, size - count) > > > So just change it to: > extract_mn(offset, count) > > > And I strongly suspect it will affect it "in the right way". > But I'm going to try diffing assembly before/after to be sure. > And then watch the sparc and ppc hudson builds. :) > (and fix PPC_DARWIN beforehand as well) > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > and there are no other uses of extract_mn in the frontend, I think. > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > Anyway, still speculation at this point. > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > perhaps it is best to just leave everything asis...?) > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > - Jay > > > ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 16:34:25 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Are they wrong? Seems strange that they worked previously! >> >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: >> >> None yet. But notice the endian checks around the insert_mn or >> extract_mn uses in cg.m3. >> The change would be to remove those. >> >> - Jay >> >> >> ________________________________ >> Subject: Re: [M3devel] bit field operations for insert/extract >> From: hosking at cs.purdue.edu >> Date: Tue, 23 Nov 2010 09:37:00 -0500 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Refresh my memory. What m3front change did you make? >> >> >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: >> >> Tony, I'm going to try again to use bitfield operations for extract_mn. >> And insert_mn. >> I think I know what went wrong before for extract_mn: just remove the >> endian check in m3front. >> But I'm going to be sure test p240 covers it well. >> >> The easy part, duh, your original extract_mn was correct I think, just, >> again, missing the m3front change. >> >> Insert_mn is less obvious. >> I started writing it... bitfield_ref..modify_expr...uh, seems >> suspicious, to be modifying an existing value. >> >> I guess it's more like, that, but with a temp that starts with the full >> value of x: >> create temp >> modify(temp, x) >> modify(bitfield_ref(temp, count, offset), y); >> m3_load(temp) >> >> ? >> >> I'll try something like that. >> It seems unfortunate. >> Maybe we can know if x is already a value and not a variable? >> >> >> - Jay >> >> >> From jay.krell at cornell.edu Tue Nov 23 23:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Nov 2010 22:53:25 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , Message-ID: Fair enough, easy enough. I'd want to double check that the existing use is wanting that interpretation. Obviously for that matter, we can leave the code asis for big endian. And just take your code as it was, but under if (target_is_little_endian). Big endian is the minority anyway. :) (no, I won't do that) It would be cool if the frontend never checked target endianness. It does it very little as it is. But ok either way. (I want to move the Target.m3 stuff to the config files -- endianness, setjmp name, jmpbuf size/align, etc., though that's about all that is left) - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 17:46:06 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] bit field operations for insert/extract > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > Let me clarify. > > Remember when you used bit field operations for extract_mn? > > And they didn't work on any big endian system? > > And I had to undo it? With your approval. > > > > > > I believe the way to go: > > the change you did in parse.c; it was correct, highly likely > > removing those endian checks in m3front, which you didn't do at the time > > > > > > Removing the endian checks will only affect big endian. > > The code reads something like: > > if little_endian extract_mn(offset, count) > > else extract_mn(size - offset, size - count) > > > > > > So just change it to: > > extract_mn(offset, count) > > > > > > And I strongly suspect it will affect it "in the right way". > > But I'm going to try diffing assembly before/after to be sure. > > And then watch the sparc and ppc hudson builds. :) > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > and there are no other uses of extract_mn in the frontend, I think. > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > Anyway, still speculation at this point. > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > perhaps it is best to just leave everything asis...?) > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > - Jay > > > > > > ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Are they wrong? Seems strange that they worked previously! > >> > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > >> > >> None yet. But notice the endian checks around the insert_mn or > >> extract_mn uses in cg.m3. > >> The change would be to remove those. > >> > >> - Jay > >> > >> > >> ________________________________ > >> Subject: Re: [M3devel] bit field operations for insert/extract > >> From: hosking at cs.purdue.edu > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Refresh my memory. What m3front change did you make? > >> > >> > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > >> > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > >> And insert_mn. > >> I think I know what went wrong before for extract_mn: just remove the > >> endian check in m3front. > >> But I'm going to be sure test p240 covers it well. > >> > >> The easy part, duh, your original extract_mn was correct I think, just, > >> again, missing the m3front change. > >> > >> Insert_mn is less obvious. > >> I started writing it... bitfield_ref..modify_expr...uh, seems > >> suspicious, to be modifying an existing value. > >> > >> I guess it's more like, that, but with a temp that starts with the full > >> value of x: > >> create temp > >> modify(temp, x) > >> modify(bitfield_ref(temp, count, offset), y); > >> m3_load(temp) > >> > >> ? > >> > >> I'll try something like that. > >> It seems unfortunate. > >> Maybe we can know if x is already a value and not a variable? > >> > >> > >> - Jay > >> > >> > >> > From jay.krell at cornell.edu Thu Nov 25 11:52:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 10:52:56 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: <4CB2D03D.8080608@wickensonline.co.uk> References: , <1286270642.3514.3.camel@boromir.m3w.org>, , <4CB1F4CD.4020101@wickensonline.co.uk>, , <4CB2C557.70704@wickensonline.co.uk> , <4CB2D03D.8080608@wickensonline.co.uk> Message-ID: [again, sorry] Another chance on some items, people here will get big discounts. working SGI Fuel good fast SGI workstation runs Irix and should run OpenBSD http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651922577 AlphaServer 800 5/400, doesn't seem to work http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651918789 HPPA machine that can run Linux and HP-UX; works; loud; no video out, need to use serial console (over which I was able to install both Linux and HP-UX) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651902023 Anyone here can negotiate me way way way down, esp. if you provide me ssh access. AlphaServer would go for just half shipping for example. The rest probably $50-$100 + shipping. Or just half shipping if you give me occasional ssh access. I'm pretty sure the HP machine is worth over $100 and the SGI over $200. More coming, probably next week. Happy Thanksgiving, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 25 12:08:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Nov 2010 11:08:25 +0000 Subject: [M3devel] hardware clearance (again) In-Reply-To: References: , , <1286270642.3514.3.camel@boromir.m3w.org>, , , , <4CB1F4CD.4020101@wickensonline.co.uk>, , , , , <4CB2C557.70704@wickensonline.co.uk>, , , <4CB2D03D.8080608@wickensonline.co.uk>, Message-ID: another, including the Linux/sparc Hudson node: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120651928303 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 27 01:14:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:14:24 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>, , , , , , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, Message-ID: I don't know what the strong/weak casts are, but here is the problem seemingly: gcc-4.5 fold-const.c fold_binary_loc(code = FLOOR_DIV_EXPR, ??????????????? op0, op1, type all int_64 arg0, arg1 become word_64 (not op0, op1, but arg0, arg1) and then we end up here: ????? if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) ??? ? && multiple_of_p (type, arg0, arg1)) ??? return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); and then, configure -enable-checking=fold,...: error: type mismatch in binary expression int_64 word_64 word_64 D.1003 = D.1001 /[ex] D.1002; I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 23 Nov 2010 22:50:02 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > Aha. I had no idea and should investigate further. > Notice though that I've been applying the same sorts of casts > everywhere and they generally help. But perhaps they are > weak, and weak is usually strong enough, or some such. > Almost anything is possible. :) > > > - Jay > > > > ---------------------------------------- > > Subject: Re: [M3commit] CVS Update: cm3 > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > CC: m3commit at elegosoft.com > > To: jay.krell at cornell.edu > > > > There are weak and strong casts in gcc. > > I forget the precise details, but I believe they will make a difference. > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > Presumably fold is removing the cast somewhere. > > > Maybe a gcc bug??? > > > I can dig deeper if you really want. > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > but different in signedness, I want to try *not* taking the address. > > > Probably also for pointer<=>integer of pointer size. > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> That should be handled by placing an appropriate cast in the gcc tree. > > >> > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > >> > > >> Try building m3-sys/m3tests/p2/p240. > > >> There is an error in the configure enable-checking about the types > > >> being mismatched. > > >> > > >> - Jay > > >> > > >> > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> Go with the obvious less heavy handed fix of only avoiding > > >>>> fold for integer division. > > >>> > > >>> I don't understand what the issue is with folding on integer > > >> division. Please explain. > > >>> > > >>>> This is enough for test p240 and the unoptimized code is definitely > > >> better. > > >>>> NOT fully tested, but really probably works. > > >>>> It is probably worth digging into the frontend to see if there is a > > >> difference > > >>>> in the types. It is probably also worth digging in the backend, like, > > >>>> we do put in the casts consistently, why are they only not effective > > >>>> for divide? I realize that a little bit of analysis goes a long way > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > >>>> On the other hand, it isn't worth too much effort. > > >>>> Divide is the slowest least used integer operation. > > >>> > > >> > > From jay.krell at cornell.edu Sat Nov 27 01:38:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Nov 2010 00:38:40 +0000 Subject: [M3devel] fold_build(divide) vs. build(divide) In-Reply-To: References: <20101123094957.146F72474003@birch.elegosoft.com>,,, , , ,,, , , <40DB8AE9-6A52-4C50-9D91-4C755919C7B6@cs.purdue.edu>, , , , , <26E4073F-6195-4157-9C3A-136E57B26C10@cs.purdue.edu>, , , Message-ID: The reason it gets there is that multiple_of_p is true, because I'm dividing something by itself, in the test case. The answer would be 1, unless the value is 0. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Nov 2010 00:14:24 +0000 > CC: m3devel at elegosoft.com > Subject: [M3devel] fold_build(divide) vs. build(divide) > > > I don't know what the strong/weak casts are, but here is the problem seemingly: > > gcc-4.5 > fold-const.c > > fold_binary_loc(code = FLOOR_DIV_EXPR, > op0, op1, type all int_64 > > arg0, arg1 become word_64 > (not op0, op1, but arg0, arg1) > > and then we end up here: > > if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) > && multiple_of_p (type, arg0, arg1)) > return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); > > and then, configure -enable-checking=fold,...: > > error: type mismatch in binary expression > int_64 > > word_64 > > word_64 > > D.1003 = D.1001 /[ex] D.1002; > > I'll maybe see if newer gcc is different or open a bug or discuss on gcc at . > > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 22:50:02 +0000 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Aha. I had no idea and should investigate further. > > Notice though that I've been applying the same sorts of casts > > everywhere and they generally help. But perhaps they are > > weak, and weak is usually strong enough, or some such. > > Almost anything is possible. :) > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > Subject: Re: [M3commit] CVS Update: cm3 > > > From: hosking at cs.purdue.edu > > > Date: Tue, 23 Nov 2010 17:47:16 -0500 > > > CC: m3commit at elegosoft.com > > > To: jay.krell at cornell.edu > > > > > > There are weak and strong casts in gcc. > > > I forget the precise details, but I believe they will make a difference. > > > > > > > > > Antony Hosking | Associate 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 Nov 23, 2010, at 4:51 PM, Jay K wrote: > > > > > > > > > > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide. > > > > Presumably fold is removing the cast somewhere. > > > > Maybe a gcc bug??? > > > > I can dig deeper if you really want. > > > > > > > > > > > > Or maybe they didn't make a difference and I put them in wrong and divide is the only > > > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty.. > > > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide). > > > > > > > > > > > > I actually find it odd that build_fold is even a public heavily used function. > > > > It seems to me it should be, like, done at the next level down. > > > > > > > > > > > > Which reminds me, in load/store, if the two types are both integers and the same size > > > > but different in signedness, I want to try *not* taking the address. > > > > Probably also for pointer<=>integer of pointer size. > > > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off.. > > > > > > > > > > > > - Jay > > > > > > > > > > > > ________________________________ > > > >> From: hosking at cs.purdue.edu > > > >> Date: Tue, 23 Nov 2010 16:38:39 -0500 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3commit at elegosoft.com > > > >> Subject: Re: [M3commit] CVS Update: cm3 > > > >> > > > >> That should be handled by placing an appropriate cast in the gcc tree. > > > >> > > > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote: > > > >> > > > >> Try building m3-sys/m3tests/p2/p240. > > > >> There is an error in the configure enable-checking about the types > > > >> being mismatched. > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> > > > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> Go with the obvious less heavy handed fix of only avoiding > > > >>>> fold for integer division. > > > >>> > > > >>> I don't understand what the issue is with folding on integer > > > >> division. Please explain. > > > >>> > > > >>>> This is enough for test p240 and the unoptimized code is definitely > > > >> better. > > > >>>> NOT fully tested, but really probably works. > > > >>>> It is probably worth digging into the frontend to see if there is a > > > >> difference > > > >>>> in the types. It is probably also worth digging in the backend, like, > > > >>>> we do put in the casts consistently, why are they only not effective > > > >>>> for divide? I realize that a little bit of analysis goes a long way > > > >>>> on many divide cases: "divide tends to produce small results", sort of. > > > >>>> On the other hand, it isn't worth too much effort. > > > >>>> Divide is the slowest least used integer operation. > > > >>> > > > >> > > > > From rcolebur at SCIRES.COM Mon Nov 29 03:01:51 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 Message-ID: I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Nov 29 08:52:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 07:52:20 +0000 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Good catch. Please try with recent small update, thanks. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Nov 29 16:58:39 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 29 Nov 2010 10:58:39 -0500 Subject: [M3devel] build problem on Win2000 In-Reply-To: References: Message-ID: Jay: Your update seems to have fixed the problem. THANKS. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, November 29, 2010 2:52 AM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] build problem on Win2000 Good catch. Please try with recent small update, thanks. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 28 Nov 2010 21:01:51 -0500 Subject: [M3devel] build problem on Win2000 I am getting the following error when trying to build m3core on Windows 2000: RTDebugC.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent referenced in function _RTDebug__IsDebuggerPresent I am using Microsoft Visual Studio 2005 for the C compiler/linker. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcdurocher at gmail.com Mon Nov 29 18:14:56 2010 From: kcdurocher at gmail.com (Ken Durocher) Date: Mon, 29 Nov 2010 11:14:56 -0600 Subject: [M3devel] Enumeration or subrange value out of range Message-ID: I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I ran into a problem. The code compiles fine, but I get a runtime error. I'm running 5.8.6 RELEASE on AMD64. P.S. Is there already an unsigned int32 type? Is there a better way to create one? Here's the code: INTERFACE Tea; TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); END Tea. *** MODULE Tea; FROM Word IMPORT Xor, LeftShift, RightShift; VAR delta := 16_9e3779b9; PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 0; BEGIN FOR i := 0 TO 31 DO sum := sum + delta; v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1))); v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3))); END; v[0] := v0; v[1] := v1; END Encrypt; PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = VAR v0 := v[0]; v1 := v[1]; k0 := k[0]; k1 := k[1]; k2 := k[2]; k3 := k[3]; sum: UInt32 := 16_c6ef3720; BEGIN FOR i := 0 TO 32 DO v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), RightShift(v0, 5) + k3)); v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), RightShift(v1, 5) + k1)); sum := sum - delta; END; v[0] := v0; v[1] := v0; END Decrypt; BEGIN END Tea. *** MODULE Main; IMPORT IO, Fmt, Tea; VAR v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; BEGIN Tea.Encrypt(v,k); IO.Put(Fmt.Unsigned(v[0])); IO.Put(" - "); IO.Put(Fmt.Unsigned(v[1])); IO.Put("\n"); END Main. And the error: *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../Tea.m3", line 18 *** Aborted -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Nov 29 20:24:22 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 29 Nov 2010 14:24:22 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <20101129192421.GA31379@topoi.pooq.com> On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > ran into a problem. The code compiles fine, but I get a runtime error. I'm > running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? There's a signed int32, and an unsigned int31, which is designed to fit into a signed 32. The closes you can come to unsigned int32 is probably WORD. Look up Word.T. Unless you're using a 64-bit machine, in which case you get int64 and unsigned int63 for free, I suppose. -- hendrik From jay.krell at cornell.edu Mon Nov 29 21:22:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 20:22:17 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101129192421.GA31379@topoi.pooq.com> References: , <20101129192421.GA31379@topoi.pooq.com> Message-ID: Signed int32 probably works for you, for storage. (Cstdint.int32_t or such). For the operations, well, Word will do most of what you want. Just be sure to and with 16_FFFFFFFF before each assignment? We could flesh out /dev2/cm3/m3-libs/m3core/src/types to contain the Word operations. HOWEVER we'd want/need to provide version with exceptions or silence for overflow. - Jay > Date: Mon, 29 Nov 2010 14:24:22 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > On Mon, Nov 29, 2010 at 11:14:56AM -0600, Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, but I > > ran into a problem. The code compiles fine, but I get a runtime error. I'm > > running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > There's a signed int32, and an unsigned int31, which is designed to fit > into a signed 32. The closes you can come to unsigned int32 is probably > WORD. Look up Word.T. > > Unless you're using a 64-bit machine, in which case you get int64 and > unsigned int63 for free, I suppose. > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Nov 29 23:36:30 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 29 Nov 2010 16:36:30 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: Message-ID: <4CF42AEE.3000807@lcwb.coop> The packed subrange type with an all-positive range doesn't do what I suspect you think it does. The subrange only affects what values can be legally stored in a variable, and the packed size only affects memory allocation when it is used as an element of an array or field of a record or object. None of this changes the semantics of the arithmetic operators +, -, Word.Xor, etc. when applied to values of this type. In Modula-3, all intermediate arithmetic is done in the native word size, in this case 64 bits. And the builtin operators +, etc. apply signed interpretation to the bit values. Only when you assign to a variable (or do any of a number of equivalent things, e.g., pass to a VALUE parameter) is a range check done. There is no trimming of intermediate results to 32 bits, despite the application of your arithmetic operators to variables of your UInt32 subrange type. So, without vetting the algorithm or knowing sample input, I can pretty well guess that things like LeftShift are shifting bits into the upper half of the word. Then when you try to assign to a UInt32 variable, you have a value outside its range. One way to do this would be to always And to 16_FFFFFFFF in your expression, before you store the result. This would ensure values within range, and, I suspect, the values you really want. Note that Modula-3 handles unsigned rather differently than many languages. You can use a subrange type, as you did, but it has to be a true subrange of INTEGER, so you can't get the normally-negative part of the range of INTEGER to be interpreted as positive, above the normal positive half of INTEGER. Should you really need full native-word-sized unsigned arithmetic, you use the type Word.T. But this is actually the same type as INTEGER, so naming it Word.T is just a programmer readability courtesy. The builtin operators +, -, etc. apply signed interpretation to the bits in a word. The operators from Word (Word.Plus, etc.) operate on values of the same type (INTEGER=Word.T), but apply unsigned interpretation to the entire word range. It would no doubt be good to replace your + operators with Word.Plus, to emphasize unsigned arithmetic. For + and -, in the absence of overflow checks, the signed and unsigned arithmetic are the same, of course, but it would be another readability courtesy. And if we ever get a compiler with overflow checking, it would still work right. I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while still And-ing results to 16_FFFFFFFF. I think this would make your code portable between 32-bit and 64-bit machines. All your arithmetic would just be applying unsigned interpretation to the bits, and the signed subrange would work like INTEGER on a 32-bit machine and as you have coded on 64 bits. All bit combinations (with no bits set in the upper half of a 64-bit word) would be in range. Of course, this all interacts with your client code and they type they use. Or maybe you could just dispense with trying to use the type system to enforce your ranges and use Word.T. If you always And your results to 16_FFFFFFFF, it will ensure they are within the desired range. There are some client interface design issues here, which you test program is not involved enough to expose. On another subject, it looks like your algorithms will either crash or won't work meaningfully unless v has exactly two elements and k has exactly 4. So using fixed array types instead of open might be a sensible way to use the type system to help here. P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The compiler is free to represent them in any way that can hold the range, and it may well give them 64 bits on a 64-bit machine. In any case, even if it gave them only 32, it would, by the semantics of the language, have to expand them to 64 before doing any arithmetic on them. HTH. Rodney Bates Ken Durocher wrote: > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > but I ran into a problem. The code compiles fine, but I get a runtime > error. I'm running 5.8.6 RELEASE on AMD64. > > P.S. Is there already an unsigned int32 type? Is there a better way to > create one? > > Here's the code: > > INTERFACE Tea; > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > END Tea. > > *** > > MODULE Tea; > > FROM Word IMPORT Xor, LeftShift, RightShift; > > VAR > delta := 16_9e3779b9; > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 0; > > BEGIN > FOR i := 0 TO 31 DO > sum := sum + delta; > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1))); > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3))); > END; > v[0] := v0; v[1] := v1; > END Encrypt; > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > VAR > v0 := v[0]; v1 := v[1]; > k0 := k[0]; k1 := k[1]; > k2 := k[2]; k3 := k[3]; > sum: UInt32 := 16_c6ef3720; > BEGIN > FOR i := 0 TO 32 DO > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > RightShift(v0, 5) + k3)); > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > RightShift(v1, 5) + k1)); > sum := sum - delta; > END; > v[0] := v0; v[1] := v0; > END Decrypt; > > BEGIN > END Tea. > > *** > > MODULE Main; > > IMPORT IO, Fmt, Tea; > > VAR > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > BEGIN > Tea.Encrypt(v,k); > IO.Put(Fmt.Unsigned(v[0])); > IO.Put(" - "); > IO.Put(Fmt.Unsigned(v[1])); > IO.Put("\n"); > END Main. > > And the error: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../Tea.m3", line 18 > *** > > Aborted > > From jay.krell at cornell.edu Tue Nov 30 00:01:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 29 Nov 2010 23:01:47 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <4CF42AEE.3000807@lcwb.coop> References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. And *hopefully* a 64bit targeting compiler would "notice" and make some optimizations, such as only doing 32bit load/stores, but I could easily imagine it not doing that. Imho, it really would be nice to have the following types, with operator+, etc.: unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow 2 x 4 x 2 => 16 types C and C++ programmers the world over have 8 of these types (unspecified what signed overflow does, but overwhelmingly it is silent). The underlying backend exposes those 8 as well. - Jay ---------------------------------------- > Date: Mon, 29 Nov 2010 16:36:30 -0600 > From: rodney_bates at lcwb.coop > To: kcdurocher at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Enumeration or subrange value out of range > > The packed subrange type with an all-positive range doesn't do what > I suspect you think it does. The subrange only affects what values > can be legally stored in a variable, and the packed size only affects > memory allocation when it is used as an element of an array or field > of a record or object. None of this changes the semantics of the > arithmetic operators +, -, Word.Xor, etc. when applied to values > of this type. > > In Modula-3, all intermediate arithmetic is done in the native word > size, in this case 64 bits. And the builtin operators +, etc. apply signed > interpretation to the bit values. Only when you assign to a variable (or do > any of a number of equivalent things, e.g., pass to a VALUE parameter) > is a range check done. There is no trimming of intermediate results > to 32 bits, despite the application of your arithmetic operators to variables > of your UInt32 subrange type. > > So, without vetting the algorithm or knowing sample input, I can pretty > well guess that things like LeftShift are shifting bits into the upper > half of the word. Then when you try to assign to a UInt32 variable, > you have a value outside its range. > > One way to do this would be to always And to 16_FFFFFFFF in your expression, > before you store the result. This would ensure values within range, and, > I suspect, the values you really want. > > Note that Modula-3 handles unsigned rather differently than many languages. > You can use a subrange type, as you did, but it has to be a true subrange > of INTEGER, so you can't get the normally-negative part of the range of > INTEGER to be interpreted as positive, above the normal positive half of > INTEGER. > > Should you really need full native-word-sized unsigned arithmetic, you > use the type Word.T. But this is actually the same type as INTEGER, so > naming it Word.T is just a programmer readability courtesy. The builtin > operators +, -, etc. apply signed interpretation to the bits in a word. > The operators from Word (Word.Plus, etc.) operate on values of the same > type (INTEGER=Word.T), but apply unsigned interpretation to the entire > word range. > > It would no doubt be good to replace your + operators with Word.Plus, > to emphasize unsigned arithmetic. For + and -, in the absence of > overflow checks, the signed and unsigned arithmetic are the same, > of course, but it would be another readability courtesy. And if we > ever get a compiler with overflow checking, it would still work right. > > I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while > still And-ing results to 16_FFFFFFFF. I think this would make your code portable > between 32-bit and 64-bit machines. All your arithmetic would just be > applying unsigned interpretation to the bits, and the signed subrange would > work like INTEGER on a 32-bit machine and as you have coded on 64 bits. > All bit combinations (with no bits set in the upper half of a 64-bit word) > would be in range. Of course, this all interacts with your client code > and they type they use. > > Or maybe you could just dispense with trying to use the type system to > enforce your ranges and use Word.T. If you always And your results to > 16_FFFFFFFF, it will ensure they are within the desired range. There > are some client interface design issues here, which you test program > is not involved enough to expose. > > On another subject, it looks like your algorithms will either crash or > won't work meaningfully unless v has exactly two elements and k has exactly > 4. So using fixed array types instead of open might be a sensible way to > use the type system to help here. > > P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The > compiler is free to represent them in any way that can hold the range, and it > may well give them 64 bits on a 64-bit machine. In any case, even > if it gave them only 32, it would, by the semantics of the language, > have to expand them to 64 before doing any arithmetic on them. > > > HTH. Rodney Bates > > > Ken Durocher wrote: > > I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, > > but I ran into a problem. The code compiles fine, but I get a runtime > > error. I'm running 5.8.6 RELEASE on AMD64. > > > > P.S. Is there already an unsigned int32 type? Is there a better way to > > create one? > > > > Here's the code: > > > > INTERFACE Tea; > > > > TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); > > > > END Tea. > > > > *** > > > > MODULE Tea; > > > > FROM Word IMPORT Xor, LeftShift, RightShift; > > > > VAR > > delta := 16_9e3779b9; > > > > PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 0; > > > > BEGIN > > FOR i := 0 TO 31 DO > > sum := sum + delta; > > v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1))); > > v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3))); > > END; > > v[0] := v0; v[1] := v1; > > END Encrypt; > > > > PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = > > VAR > > v0 := v[0]; v1 := v[1]; > > k0 := k[0]; k1 := k[1]; > > k2 := k[2]; k3 := k[3]; > > sum: UInt32 := 16_c6ef3720; > > BEGIN > > FOR i := 0 TO 32 DO > > v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), > > RightShift(v0, 5) + k3)); > > v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), > > RightShift(v1, 5) + k1)); > > sum := sum - delta; > > END; > > v[0] := v0; v[1] := v0; > > END Decrypt; > > > > BEGIN > > END Tea. > > > > *** > > > > MODULE Main; > > > > IMPORT IO, Fmt, Tea; > > > > VAR > > v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; > > k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; > > > > BEGIN > > Tea.Encrypt(v,k); > > IO.Put(Fmt.Unsigned(v[0])); > > IO.Put(" - "); > > IO.Put(Fmt.Unsigned(v[1])); > > IO.Put("\n"); > > END Main. > > > > And the error: > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../Tea.m3", line 18 > > *** > > > > Aborted > > > > From hosking at cs.purdue.edu Tue Nov 30 04:13:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Nov 2010 22:13:32 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , <4CF42AEE.3000807@lcwb.coop> Message-ID: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Rodney, Thank-you for your (as-usual) incredibly lucid explanation. Jay, On Nov 29, 2010, at 6:01 PM, Jay K wrote: > > ps: anding with 16_FFFFFFFF should optimize to nothing on a 32 bit machine. > And *hopefully* a 64bit targeting compiler would "notice" and make some > optimizations, such as only doing 32bit load/stores, but I could easily > imagine it not doing that. > > > Imho, it really would be nice to have the following types, with operator+, etc.: > > > unsigned/signed 8/16/32/64bit integer with silent overflow/exception upon overflow > 2 x 4 x 2 => 16 types This would be a nightmare. (i.e., over many of our dead bodies...) > C and C++ programmers the world over have 8 of these types (unspecified > what signed overflow does, but overwhelmingly it is silent). Let them rot in C hell. > The underlying backend exposes those 8 as well. But only for the purpose of accessing stored values (as Rodney explained). All operations are performed at INTEGER/Word.T granularity. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 29 Nov 2010 16:36:30 -0600 >> From: rodney_bates at lcwb.coop >> To: kcdurocher at gmail.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Enumeration or subrange value out of range >> >> The packed subrange type with an all-positive range doesn't do what >> I suspect you think it does. The subrange only affects what values >> can be legally stored in a variable, and the packed size only affects >> memory allocation when it is used as an element of an array or field >> of a record or object. None of this changes the semantics of the >> arithmetic operators +, -, Word.Xor, etc. when applied to values >> of this type. >> >> In Modula-3, all intermediate arithmetic is done in the native word >> size, in this case 64 bits. And the builtin operators +, etc. apply signed >> interpretation to the bit values. Only when you assign to a variable (or do >> any of a number of equivalent things, e.g., pass to a VALUE parameter) >> is a range check done. There is no trimming of intermediate results >> to 32 bits, despite the application of your arithmetic operators to variables >> of your UInt32 subrange type. >> >> So, without vetting the algorithm or knowing sample input, I can pretty >> well guess that things like LeftShift are shifting bits into the upper >> half of the word. Then when you try to assign to a UInt32 variable, >> you have a value outside its range. >> >> One way to do this would be to always And to 16_FFFFFFFF in your expression, >> before you store the result. This would ensure values within range, and, >> I suspect, the values you really want. >> >> Note that Modula-3 handles unsigned rather differently than many languages. >> You can use a subrange type, as you did, but it has to be a true subrange >> of INTEGER, so you can't get the normally-negative part of the range of >> INTEGER to be interpreted as positive, above the normal positive half of >> INTEGER. >> >> Should you really need full native-word-sized unsigned arithmetic, you >> use the type Word.T. But this is actually the same type as INTEGER, so >> naming it Word.T is just a programmer readability courtesy. The builtin >> operators +, -, etc. apply signed interpretation to the bits in a word. >> The operators from Word (Word.Plus, etc.) operate on values of the same >> type (INTEGER=Word.T), but apply unsigned interpretation to the entire >> word range. >> >> It would no doubt be good to replace your + operators with Word.Plus, >> to emphasize unsigned arithmetic. For + and -, in the absence of >> overflow checks, the signed and unsigned arithmetic are the same, >> of course, but it would be another readability courtesy. And if we >> ever get a compiler with overflow checking, it would still work right. >> >> I would suggest using the signed subrange [-16_7FFFFFFF-1 .. 16_7FFFFFFF], while >> still And-ing results to 16_FFFFFFFF. I think this would make your code portable >> between 32-bit and 64-bit machines. All your arithmetic would just be >> applying unsigned interpretation to the bits, and the signed subrange would >> work like INTEGER on a 32-bit machine and as you have coded on 64 bits. >> All bit combinations (with no bits set in the upper half of a 64-bit word) >> would be in range. Of course, this all interacts with your client code >> and they type they use. >> >> Or maybe you could just dispense with trying to use the type system to >> enforce your ranges and use Word.T. If you always And your results to >> 16_FFFFFFFF, it will ensure they are within the desired range. There >> are some client interface design issues here, which you test program >> is not involved enough to expose. >> >> On another subject, it looks like your algorithms will either crash or >> won't work meaningfully unless v has exactly two elements and k has exactly >> 4. So using fixed array types instead of open might be a sensible way to >> use the type system to help here. >> >> P.S. BITS 32 FOR ... does nothing to autonomous variables v0, etc., The >> compiler is free to represent them in any way that can hold the range, and it >> may well give them 64 bits on a 64-bit machine. In any case, even >> if it gave them only 32, it would, by the semantics of the language, >> have to expand them to 64 before doing any arithmetic on them. >> >> >> HTH. Rodney Bates >> >> >> Ken Durocher wrote: >>> I am trying to write the Tiny Encryption Algorithm (TEA) in Modula-3, >>> but I ran into a problem. The code compiles fine, but I get a runtime >>> error. I'm running 5.8.6 RELEASE on AMD64. >>> >>> P.S. Is there already an unsigned int32 type? Is there a better way to >>> create one? >>> >>> Here's the code: >>> >>> INTERFACE Tea; >>> >>> TYPE UInt32 = BITS 32 FOR [0 .. 16_FFFFFFFF]; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32); >>> >>> END Tea. >>> >>> *** >>> >>> MODULE Tea; >>> >>> FROM Word IMPORT Xor, LeftShift, RightShift; >>> >>> VAR >>> delta := 16_9e3779b9; >>> >>> PROCEDURE Encrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 0; >>> >>> BEGIN >>> FOR i := 0 TO 31 DO >>> sum := sum + delta; >>> v0 := v0 + (Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1))); >>> v1 := v1 + (Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3))); >>> END; >>> v[0] := v0; v[1] := v1; >>> END Encrypt; >>> >>> PROCEDURE Decrypt(VAR v: ARRAY OF UInt32; VAR k: ARRAY OF UInt32) = >>> VAR >>> v0 := v[0]; v1 := v[1]; >>> k0 := k[0]; k1 := k[1]; >>> k2 := k[2]; k3 := k[3]; >>> sum: UInt32 := 16_c6ef3720; >>> BEGIN >>> FOR i := 0 TO 32 DO >>> v1 := v1 - Xor(LeftShift(v0, 4) + k2, Xor((sum + v0), >>> RightShift(v0, 5) + k3)); >>> v0 := v0 - Xor(LeftShift(v1, 4) + k0, Xor((sum + v1), >>> RightShift(v1, 5) + k1)); >>> sum := sum - delta; >>> END; >>> v[0] := v0; v[1] := v0; >>> END Decrypt; >>> >>> BEGIN >>> END Tea. >>> >>> *** >>> >>> MODULE Main; >>> >>> IMPORT IO, Fmt, Tea; >>> >>> VAR >>> v := ARRAY [0..1] OF Tea.UInt32 {16_48690000, 0}; >>> k := ARRAY [0..3] OF Tea.UInt32 {16_74657374, 0, 0, 0}; >>> >>> BEGIN >>> Tea.Encrypt(v,k); >>> IO.Put(Fmt.Unsigned(v[0])); >>> IO.Put(" - "); >>> IO.Put(Fmt.Unsigned(v[1])); >>> IO.Put("\n"); >>> END Main. >>> >>> And the error: >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../Tea.m3", line 18 >>> *** >>> >>> Aborted >>> >>> From jay.krell at cornell.edu Tue Nov 30 04:43:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 03:43:26 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: > Let them rot in C hell. It's really not a bad place. Modula-3 is good: optional safety, optional unsafety ie: optional garbage collection, restrictions on taking address of locals, range checks on arrays better interface/implementation separation, such as to allow much faster compilation single inheritance object-orientation is nice, but I'd prefer for the safety to be optional (untraced objects) and multiple-inheritance generics are good, but not as good as C++ templates sets are kind of nice optionally indexing arrays by enums is kind of nice open arrays are kind of nice (relates to safety) Very small language definition is good, but I'd still like e.g. operator overloading, at least with a "fixed" interface as I described T +(T,T), never T1 +(T2, T3) for example. But I don't see why not providing these types is so good. I can see that maybe it is partly/all library instead of language. As well, as so much code is C, C++, or even Java and C#, it is what the hardware supports well. i.e. 8 bit, 16 bit, 32 bit operations are efficient, and 64 bit are also sometimes - Jay From dragisha at m3w.org Tue Nov 30 08:49:01 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 08:49:01 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? No, it isn't ! :) I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. On Nov 30, 2010, at 4:43 AM, Jay K wrote: > generics are good, but not as good as C++ templates From jay.krell at cornell.edu Tue Nov 30 09:32:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 08:32:12 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? The error messages are better these days. It is true they were terrible for a long time. Don't Modula-3 generics have the same problem? At least in the C++ case: - the errors aren't in generated files - you don't have to explicitly instantiate everything "in the build system" - for function templates, you never have to instantiate anything The automatic deduction of function template parameters is very powerful. You have to try it. I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent feature "auto". It is also true that templates seem to be largely accidental in what they allow. It seems they were designed with two primary applications: std::vector std::min/max The compile-time Turing-completeness seems to have been an accident, and what people use this for is/was perhaps better implemented through special language constructs builtin to the compiler. It is both impressive and depressive. Impressive that it is doable, depressive what it looks like. When people do "meta programming" like "is_pod", "has_copy_constructor", etc. Consider this though, have you heard the ability to do this: matrix a,b,c,d; a = b + c + d; where there are no intermediate matrices? The results are written directly into a. The people do this is that operator+ doesn't return a matrix, but rather a type that represents the result matrix addition, which is assignable to a matrix, and can also be added to matrices or the results of matrix addition. So ultimately what is assigned to a is something representation the addition of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within the rules of matrix multiplication) etc. There is no special casing, no special purpose code to handle certain combinations. I don't believe any other language has this power. Simple string addition can benefit from this same technique. Instead, string concatenation gets very special treatment by compilers, including I believe in Modula-3, Java, and C#. That's not "fair". Why should string get all the power and syntactic sugar, but not any user-defined types? Look for articles by Todd Veldhuzien. Libraries such as Blitz++. http://www.cs.rpi.edu/~musser/design/blitz/meta-art.html http://www.oonumerics.org/blitz/ etc. If C++ is just a bit too gnarly and difficult to understand and implement, I suspect subset exists with about the same level of expressiveness. But I don't know. - Jay > Subject: Re: [M3devel] Enumeration or subrange value out of range > From: dragisha at m3w.org > Date: Tue, 30 Nov 2010 08:49:01 +0100 > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; kcdurocher at gmail.com > To: jay.krell at cornell.edu > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > No, it isn't ! :) > > I don't care much for generics, but templates are just one of C hells. Nice concept, surely, when everything goes well. But once it doesn't, you'll not solve it inspecting it - guessing is what you're doing. And peppering your code with "cerr <<". > > I understand you're doing C/C++ for ages... It is like climbing a hill on the way to your work. After some time, it becomes funny and you (almost) enjoy it. Except for part where you're comimg sweaty to that morning meeting, but well - one can't have everything. I knew people in Belgrade with just such a nice workplace :) - meteorologic observatory on a bit remote hill. > > On Nov 30, 2010, at 4:43 AM, Jay K wrote: > > > generics are good, but not as good as C++ templates > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Nov 30 10:19:37 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Nov 2010 10:19:37 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> , Message-ID: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > Recently I met these... Isn't it nice, to find your error happening somewhere in some .h file you never heard of? > > > The error messages are better these days. My experience is as recent as Snow Leopard, with 10.6.5 update. > It is true they were terrible for a long time. > Don't Modula-3 generics have the same problem? > At least in the C++ case: > - the errors aren't in generated files They are generated, but they are exact source you would "generate" for it. Aren't they? And you have them to step through with debugger. At least, I never hit a wall with them, like I did with that .h for vectors. > - you don't have to explicitly instantiate everything "in the build system" That would be a killing experience, to add even more complexity to Makefiles :). > - for function templates, you never have to instantiate anything > The automatic deduction of function template parameters is very powerful. > You have to try it. > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > feature "auto". A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. > It is also true that templates seem to be largely accidental in what they allow. > It seems they were designed with two primary applications: > std::vector > std::min/max There's folk saying here, it goes like: "To kill an ox for a kilo of meat." What you can do with these, and what you need to be done with these... It is mostly scope of some more dynamic environment, scripting comes to mind. To put them in compiled environment is just more of C++'s featurism (we can do it, why don't we...)... Your comparison to ML is right on spot. C++ is just mixed philosophy, mixed styles, mixed everything. Mixed results just follow suite. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Nov 30 15:45:01 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 09:45:01 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <20101130144501.GA11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 08:32:12AM +0000, Jay K wrote: > > > Consider this though, have you heard the ability to do this: > matrix a,b,c,d; > a = b + c + d; Does it work as well for a = b + a + d? > > > where there are no intermediate matrices? > The results are written directly into a. > > > The people do this is that operator+ doesn't return a matrix, but rather > a type that represents the result matrix addition, which is assignable > to a matrix, and can also be added to matrices or the results of matrix addition. > So ultimately what is assigned to a is something representation the addition > of b, c, d. You can add any number of matrices. Or subtract. Or multiply (within > the rules of matrix multiplication) etc. There is no special casing, no special > purpose code to handle certain combinations. I don't believe any other > language has this power. Or a = a * a * a? -- hendrik From hendrik at topoi.pooq.com Tue Nov 30 16:04:18 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 30 Nov 2010 10:04:18 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> Message-ID: <20101130150418.GB11084@topoi.pooq.com> On Tue, Nov 30, 2010 at 10:19:37AM +0100, Dragi?a Duri? wrote: > > On Nov 30, 2010, at 9:32 AM, Jay K wrote: > > > It is true they were terrible for a long time. > > Don't Modula-3 generics have the same problem? > > At least in the C++ case: > > - the errors aren't in generated files > > They are generated, but they are exact source you would "generate" for > it. Aren't they? And you have them to step through with debugger. At > least, I never hit a wall with them, like I did with that .h for > vectors. And you know what files they were gerenated from, and with what parameters. > > > - you don't have to explicitly instantiate everything "in the build system" > > That would be a killing experience, to add even more complexity to > Makefiles :). C++ managed to make linkers the world over vastly more ocmplex. It's the linker that discovers that some templates haven't been compiled yet and calls the compiler to compile them. I really don't think linkers should be all *that* language-dependent. > > > - for function templates, you never have to instantiate anything > > The automatic deduction of function template parameters is very powerful. > > You have to try it. Is finding the right template to instantiate with the right parameters always unambiguous? > > I *believe* it enables a style of programming similar to ML, esp. when combined with the more recent > > feature "auto". > > A style is something I'd happily trade for discipline. I like to find my place in 10 year old project in minutes, and I like to not think about releases and subreleases of language spec (!??!!?) happening during a lifetime of my project. I don't mind ML's style, except that programmers tend to leave out too many explicit types for readability. I do mind, in C++, having something "similar to" ML without ML's internal discipline. > > > It is also true that templates seem to be largely accidental in what they allow. > > It seems they were designed with two primary applications: > > std::vector > > std::min/max > > There's folk saying here, it goes like: "To kill an ox for a kilo of meat." That's the standard practice in C++. To introduce complicated mechanisms tso that the programmer, with sufficient effort, can mimic features that should better have been reliably built into the language in the first place. > > What you can do with these, and what you need to be done with these... > It is mostly scope of some more dynamic environment, scripting comes > to mind. To put them in compiled environment is just more of C++'s > featurism (we can do it, why don't we...)... Your comparison to ML is > right on spot. Except that ML is more rationally and consistently typed. >C++ is just mixed philosophy, mixed styles, mixed > everything. Mixed results just follow suite. > -- hendrik From jay.krell at cornell.edu Tue Nov 30 18:18:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 30 Nov 2010 17:18:10 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101130150418.GB11084@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com> Message-ID: > C++ managed to make linkers the world over vastly more ocmplex. It's > the linker that discovers that some templates haven't been compiled yet > and calls the compiler to compile them. I really don't think linkers > should be all *that* language-dependent. This is actually unfortunately false. C++ requires no or almost no linker support. Inline functions often use linker features that C didn't need. Templates do not. What really happens is templatized code is fully in headers. Which does have drawbacks -- large headers, slow compile. There was an implementation where the compiler looked at the linker errors. But I don't think any such implementation is in use today. > Is finding the right template to instantiate with the right > parameters always unambiguous? When it is ambiguous, there is an error. int i; long j; max(i,j); => error > That's the standard practice in C++. To introduce complicated > mechanisms tso that the programmer, with sufficient effort, can mimic > features that should better have been reliably built into the language > in the first place. In the case of templates leading to some meta programming, it was an accident. But in the case of operator overloading it seems just goodness. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: